Sandboxes keep agents in. TAP proves what they did.
Every request your agent sends is decided under a policy only you can sign. Credentials stay out of the sandbox. Every decision is signed — inside a confidential VM — and checked on your own machine.
Agents act with your credentials, on someone else's machine
A sandbox isolates the agent from the host. It does not tell you what the agent sent where, it does not keep your tokens from it, and its logs belong to the platform.
Agents follow what they read
An issue, a web page or a tool result can steer an agent. Whatever it is told, it acts with your tokens.
Secrets live in the sandbox
To call an API, the agent usually holds the key. Anything that runs there — the agent, a dependency — can use it or leak it.
"Trust our logs"
Allowlists and audit trails are configured and kept by the platform. For regulated data, a promise is not evidence.
How TAP works
TAP sits on the way out of the sandbox and runs in a confidential VM. The agent does not change; the platform routes its egress through TAP.
Attest
Check the hardware report up to AMD's root, bound to TAP's keys.
Sign your policy
Hosts, methods, paths, limits. Only your key can change it.
Run the agent
Allowed requests go out, with credentials TAP adds. The rest get a 403.
Verify
Every request is in a signed hash chain. Recompute it yourself.
What you get
Small, auditable, and built so that you never have to take our word — or the platform's.
Your policy, signed
A P-256 key on your machine signs every policy. Versions only go up; a session sees only the policy it started with.
Credential custody
Sealed on your machine to TAP's attested key. Injected by TAP when it relays the request. Never in the sandbox.
Verifiable audit
Allowed and denied requests alike, hash-chained and signed per session. Bodies are hashed, never stored.
Hardware attestation
AMD SEV-SNP evidence, checked against AMD's pinned root certificates. No vendor service in the loop.
Fail closed
If TAP cannot be reached, nothing leaves the sandbox.
No agent changes
Works with any agent that speaks HTTP. The first adapter is one Outbound Worker for Cloudflare Sandboxes.
From a recorded session
An agent in a Cloudflare Sandbox triages GitHub issues; one issue links to an outside log host the policy does not allow. Excerpt, repository name changed.
| # | Decision | Request | Status |
|---|---|---|---|
| 1 | allow TAP sent · +workers-ai | POST api.cloudflare.com/…/ai/v1/chat/completions | 200 |
| 2 | allow TAP sent · +github | GET api.github.com/repos/acme/demo/issues | 200 |
| 5 | deny | GET paste.example-logs.dev/ci-run-4417 the policy does not allow this host | – |
| 11 | allow TAP sent · +github | POST api.github.com/repos/acme/demo/issues/1/comments | 201 |
Honest about the guarantees
TAP is a developer preview. Here is what holds today, and what does not yet.
Holds today
- Only your key can set the policy
- Credentials never enter the sandbox
- Every request TAP sees is in a signed, tamper-evident audit
- Attestation verified up to AMD's root
Not yet
- TAP's own code in the hardware measurement (measured images are next)
- Hiding the agent's data from the platform (needs the sandbox in a TEE too)
- Command and file access inside the sandbox
- Persistent state and multiple tenants
Open source
TAP asks you not to trust its operator, so you should be able to read every line. Apache-2.0.