Security considerations
Trust boundary and isolation
Interpreter execution forms a multi‑layered security boundary:
- Courier Runner installation - Only trusted runners should be installed on nodes. Runners are responsible for authentication, authorization, and enforcing policies.
- Interpreter installation - Interpreters are separate binaries that MUST be installed explicitly. Untrusted interpreters must not be executed.
- Underlying application - If the interpreter shells out to other tools (for example,
pingorinspec), those tools must also be installed and trusted.
Interpreters execute under OS‑level isolation. This RFC doesn’t mandate containerization or the use of sandbox environments. Network access isn’t guaranteed or prohibited; interpreters MAY attempt network connections subject to node policies.
Command restrictions
Interpreters MAY implement allow‑lists or deny‑lists for commands or sub‑processes. These restrictions SHOULD be exposed through contract discovery (refer to the Interpreter discovery section for further details). Job definitions may also specify conditions or limits to prevent dangerous operations.
Secret handling and redaction
Interpreters aren’t forbidden from emitting sensitive data. However, the Runner is responsible for scrubbing secrets from logs and outputs. Enabling sensitivity in output rules redacts values before submitting them as outputs and before writing to local log files. Interpreters MAY implement additional redaction logic but aren’t required to do so.
Credential usage
If an interpreter requires credentials (for example, username, token, or licenseKey), those SHOULD be supplied through the command payload or context. Interpreters SHOULD avoid reading secrets from environment variables or files. Sensitive fields SHOULD be marked as such in contract discovery so that Runner redaction can occur.