RFC: Deterministic execution guardrails for unattended sessions (secrets + shared App tokens in sandbox)

[grimdalltech]

The gap

The README's security model is refreshingly honest, but reading it against the automations feature, there's a gap I'd love maintainer thoughts on:

• Secrets are decrypted and injected as env vars at spawn (encrypted at rest, plaintext in-sandbox).
• The git credential helper brokers short-lived shared GitHub App installation tokens into the sandbox.
• Automations (webhooks, Sentry alerts, cron) start sessions with no human in the loop, and inbound payload content reaches the agent as prompt context.

So a malicious webhook/Sentry/Linear payload = indirect prompt injection into a sandbox holding (a) decrypted org secrets and (b) git credentials valid for every repo the App is installed on — with port tunnels and browser automation as exfil channels.

The single-tenant trust assumption covers users, but not content arriving at users' agents.

Proposal (optional, default-off)

A deterministic pre-execution policy layer in sandbox-runtime:

1. Secret denial — block command args/env reads targeting injected secrets + credential helper.
2. Egress allowlist — fail-closed, subdomain-aware; curl/wget/tunnels restricted to known infra domains.
3. Git remote allowlist — push/fetch only to configured SCM hosts.
4. Per-session spend cap — including child-session fan-out.
5. Signed block receipts — emitted to the session event stream for audit.

Shadow mode by default, hard blocks via flag. Zero behavior change when off.

Question for maintainers

Interest in this as an optional hardening layer? Happy to contribute the implementation (tests + docs included) if the direction is welcome — or open to pointers if you'd rather solve it at the sandbox-infra network level instead.

(Hardening proposal, not a vuln disclosure — anything sensitive routes via SECURITY.md.)

[Silentpartnercoding]

The threat boundary is real. One adjustment seems necessary if hard mode is intended to claim containment: item 1 cannot be a deterministic hard block inside sandbox-runtime for a provider that has already injected the secret into an unrestricted agent process. Direct os.environ access or a helper subprocess bypasses command inspection, so a signed block receipt would prove only the paths the wrapper observed.

Current main makes the distinction concrete. The README says secrets are injected as environment variables, and the credential helper deliberately scopes only by HTTPS host, not by the session repository. OpenComputer's secret-store integration is a useful seam toward a stronger model, although its store egress allowlist is currently [*] and unclassified secret names receive no per-host restriction. PR #1672 appears to take on the spend-cap portion, so I would keep this RFC's remaining design work focused on items 1–3 and receipt semantics.

For hard mode, I would define a provider capability contract: start unattended sessions without raw organization secrets; broker only named secret operations; have SCM credential issuance bind to the session's repository, with any sibling repositories explicitly authorized; and enforce egress outside the agent process, including resolved-IP/private-range and DNS-rebinding checks. If a provider cannot supply those boundaries, hard mode should fail closed rather than fall back to command filtering.

A useful negative matrix would read the environment through raw Python, request credentials for an installed sibling repository, and change DNS between admission and connection. Each hard-mode case should prove that the secret or token never entered the agent process and that no outbound connection occurred. Signed block events remain valuable evidence, but should not be used to claim containment of bypass paths they cannot observe.

[grimdalltech]

@Silentpartnercoding Correct — if the provider injects the secret into an unrestricted agent process, a wrapper inside sandbox-runtime can only observe the paths it controls. Direct os.environ or a helper subprocess bypasses command inspection, so receipts prove what the wrapper saw, not containment.

The provider capability contract you described is the right hard-mode model:

1. Start unattended sessions without raw org secrets.
2. Broker only named secret operations.
3. Bind SCM credential issuance to the session repository (explicit sibling authorization).
4. Enforce egress outside the agent process, including resolved-IP/private-range and DNS-rebinding checks.

I will revise the RFC so item 1 is gated on the provider contract (fail-closed otherwise, no command-filtering fallback), and keep the sandbox-runtime scope on egress + git remote allowlists and receipt semantics. The negative matrix — raw-Python env read, sibling-repo credential request, DNS flip between admission and connect — is the right test surface; I will add it.