2 min lesson
Running an agent against real privileged infra
Explain the practical point behind "He keeps a small helper script and tells the agent to call it."
Step 1 of 2
Running an agent against real privileged infrathe same instinct, from the operator's chair
The sandbox model isn't only for code Cursor runs at scale. It's also how a security engineer should drive an agent against their own cloud. Travis, who runs this workshop, is GitHub admin and AWS admin. He uses an agent to run elevated AWS commands every day and never hands it his credentials. The trick is a layer of indirection between the agent and the shell.
He keeps a small helper script and tells the agent to call it - he types something like creds prod. The script sets the credential environment variables in the shell. The agent drives that terminal through a tool, but it is not the terminal: it sees terminal output, not the shell's env properties. So the agent can run aws ... | jq against production while the credentials are never exposed to it. Every elevated command surfaces for his approval and he reads each one.
"That script sets environment variables of its shell that the agent itself never sees. So now it can run AWS commands that I will approve every single one, but it actually like never had the credentials exposed."
His approval policy is a threat model, not a blanket setting: he gates each action by how much damage it could do, because - in his words - his user has more permissions to systems than he's comfortable just handing to the agent.
Learn more
Full explanation
Travis's Approval Policy, by Blast Radius
Interactive diagram. Tab through its regions; each focused region shows its detail in the panel below.
The gate tracks the user's own permission reach, not the action's name. Threat models are personal.
Travis is candid that his policy is his, not a universal rule: "I honestly don't care if it runs rm -rf on my hard drive - it's not on my top list of 50 things I worried about," precisely because he's in a recoverable git workspace with no standing creds in the agent's reach. A local crypto-wallet developer would lock it down completely differently. Don't copy a policy; copy the method - map the gate to what your identity can reach.
Letting the agent deploy securely, toosecure-by-default IaC, reviewed before the PR opens
The same operator can use an agent to evaluate and stand up a third-party AI tool safely. Asked whether a coworker could run a locally-exposed tool, Travis aimed for safe-but-usable: don't put it on the internet. The tool's own docs recommended a Tailscale connector, so the service stays locked down and still reachable from a phone.
In Plan modeA mode that makes no edits: it researches the codebase and produces an editable plan you review before any code changes. Press Enter for the full definition. he has the agent write Terraform into an infra/ directory with "good defaults based on the docs" - explicitly not open to the internet, reasonable plugins, VPC flow logs explained inline. Then a security sub-agentA child agent a main agent spawns to work in parallel with its own context window, handing results back so the parent's context stays clean. Press Enter for the full definition. reviews the plan for risks before any PR opens.
"They're recommending Tailscale, which makes a lot of sense to me. So this is not on the internet. It's just locked down. You have a Tailscale connector and then you can put that on your phone."