Request trace
The trace follows one prompt: list a folder, use a skill, search the web, query a connector and create a file.
Which deployments this describes. The egress proxy (Envoy) and its model route exist only with Sandbox Workload Identity on, or with Sandbox Egress Proxy (domain allowlist) on; both are off by default. The trace shows a deployment with Sandbox Workload Identity on. On a default install, steps 5, 6 and 16 go from the harness to the model gateway directly with the gateway key the sandbox holds, with no per-request decision by the application tier, and step 3 establishes no identity (see Credential handling).
The trace
A connector such as Snowflake is used as the connector example. The trace shows each point where a request is checked. The agent’s live output is relayed to the browser throughout by the streaming service (not shown).
sequenceDiagram autonumber participant U as Browser (user) participant A as Application tier participant W as Temporal worker participant H as Harness participant T as Tools (bash, CLIs) participant E as Egress proxy (Envoy) participant D as Drive gateway (Caddy) participant C as Connectors service participant X as Connector target participant G as Model gateway (LiteLLM) participant P as Parallel web search participant I as Public internet U->>A: submit prompt; write access to the task A->>W: signal the task run W->>H: claim sandbox, establish identity, start W->>H: deliver the prompt H->>E: model request; App decides, proxy adds key E->>G: forward; model replies with a tool call H->>T: tool policy, then run context-cli ls T->>D: list folder: App answers (no file bytes) T->>A: skill find T->>D: skill pull: rclone, bytes from Amazon S3 T->>A: web search request A->>P: search with the App's credential H->>A: connector tool call, checked per call A->>C: forward with a per-request token C->>X: query with the stored credential H->>E: further model requests (5 and 6) H->>T: write tool creates the summary file T->>D: rclone upload: bytes to Amazon S3 T->>I: any other outbound request: not checked * W->>H: run ends: revoke identity, delete sandbox| Step | From | To | What happens | Check |
|---|---|---|---|---|
| 1 | Browser | Application tier | Submit prompt; write access to the task | ◆ |
| 2 | Application tier | Temporal worker | Signal the task run | |
| 3 | Temporal worker | Harness | Claim sandbox, establish identity, start | |
| 4 | Temporal worker | Harness | Deliver the prompt | |
| 5 | Harness | Egress proxy | Model request; the App decides, the proxy adds the key | ◆ |
| 6 | Egress proxy | Model gateway | Forward; model replies with a tool call | |
| 7 | Harness | Tools | Tool policy, then run context-cli ls | ◇ |
| 8 | Tools | Drive gateway | List folder: the App answers (no file bytes) | ◆ |
| 9 | Tools | Application tier | Skill find | ◆ |
| 10 | Tools | Drive gateway | Skill pull: rclone, bytes from Amazon S3 | ◆ |
| 11 | Tools | Application tier | Web search request | ◆ |
| 12 | Application tier | Parallel | Search with the App’s credential | |
| 13 | Harness | Application tier | Connector tool call, checked per call | ◆ |
| 14 | Application tier | Connectors service | Forward with a per-request token | |
| 15 | Connectors service | Connector target | Query with the stored credential | |
| 16 | Harness | Egress proxy | Further model requests (5 and 6) | ◆ |
| 17 | Harness | Tools | Write tool creates the summary file | ◇ |
| 18 | Tools | Drive gateway | rclone upload: bytes to Amazon S3 | ◆ |
| 19 | Tools | Public internet | Any other outbound request: not checked * | ⊘ |
| 20 | Temporal worker | Harness | Run ends: revoke identity, delete sandbox |
What the trace shows
- The harness’s tools are bash, read, write and edit, terminal sessions, the MCP connector tool, drive search and agent-browser; context-cli, rclone and context-web-search run through bash.
- The in-sandbox tool policy (steps 7 and 17) decides whether the agent may call a tool. It runs in the same container and as the same user as code the agent writes, so code in the sandbox can bypass it. The security boundary is the set of checks made by the application tier (steps 1, 5, 8, 9, 10, 11, 13, 16 and 18).
- Folder listings (step 8) are answered by the application tier through the drive gateway; file bytes move between the drive gateway and Amazon S3 only after the application tier authorizes each request (steps 10 and 18).
- Connector calls (steps 13 to 15) go from the harness to the application tier’s connectors gateway, which checks each call and forwards it to the connectors service with a token issued for that call. The connectors service runs the query with the credential stored for that connection; the sandbox never holds it. Under the “connectors” preset, each connector call asks for approval.
- Approval decisions are signed by the application tier; the sandbox holds only the public key, so code in the sandbox cannot forge an approval. Only approvals that the application tier requires are a security boundary. New agents use the “full” preset by default, which asks for nothing (P-05; see Approvals).
- Web search requests are made by the application tier with its own credential (step 12).
- Step 19 shows the path that is open under the Open egress setting *: requests the agent’s code makes to other destinations are not checked.