TinkerNothing run yet.the code runs in the sandbox · files: working copy writable, data read-only, keys hidden · network: allow-list through the proxy · secret: held by the proxy, outside the sandbox
Chapter 5 of 7
An allowed door still leaks
The allow-list from chapter 3 lets the agent reach Larkspur’s own API. That door is open on purpose. But an attack can use an open door too: it can hide stolen data inside a request to an allowed host.
This chapter: If the only host the agent can reach is Larkspur’s own, can an attack still get data out?
You will learn
- How an allow-listed host becomes a channel for exfiltration
- Why this is Guardrails’ lethal trifecta: private data, untrusted content, a way out
- That the fix is to remove one leg, and what that costs
Words you’ll meet (3)
- Allowed door
- A host the proxy lets the agent reach for a real reason, which an attack can also use.
- Lethal trifecta
- Allowing broad domains such as github.com can create paths for data exfiltration, because the proxy makes its allow decision from the client-supplied hostname without inspecting the encrypted connection's contents.
- Break a leg
- Removing one of the three legs of the trifecta, which is the only reliable fix.
The picture on the left is live. Each step below asks you to do one thing in it; the story continues here as you go.
Step 1 of 5
The sandbox is scoped, the egress is an allow-list (Larkspur’s API only), the secret is with the proxy. A note tells the agent to add a customer’s record to a routine “status ping” to that API. Run it.