Most of the serious writing about AI agent security comes from companies with a platform team. Anthropic's engineering group published a detailed account of how it contains Claude across its products: sandboxes, virtual machines, egress proxies, classifiers inspecting tool output before it reaches the model. It is worth your time. It also assumes an organization with people whose full-time job is building that infrastructure.
We build agentic delivery pipelines against client estates, most of them legacy systems that predate any of this, and the containment question comes up on every engagement. The version our clients face is not "how does a frontier lab do this." It is "what does blast-radius control look like when the whole engineering team is ten people and none of them is a security engineer."
Approval prompts are not a containment strategy
The tempting answer is supervision. The agent proposes, a human approves, and the approval dialog becomes the security model.
Two published results this year argue against leaning on that alone. Anthropic's telemetry showed users approving roughly 93 percent of permission prompts, which is another way of saying the prompts stop being read. And Wiz's GhostApproval research showed that six mainstream coding assistants could be steered by a planted symlink into writing files outside their workspace, in several cases while the approval dialog showed the user a harmless local filename. The pattern was category-wide, not one vendor's bug.
None of this means humans leave the loop. It means the loop is a probabilistic control, and probabilistic controls miss. What catches the miss is the boundary you set in the environment before the agent ran at all.
The environment layer is the part you can afford
Here is the encouraging part for a team without a platform group: environment-layer containment is mostly made of things a competent small team already knows how to do. It is access control and network hygiene applied to a new kind of user.
Give the agent its own identity. A scoped service account, never a developer's credentials. The grants match the task, nothing more. When something goes wrong, you revoke one account, and your audit log can tell you what the agent did as opposed to what a person did.
Staging credentials by default. The agent works against staging or a replica. Production access is a deliberate exception with a scope and an expiry, not a standing grant. The audit that precedes that exception is its own discipline, and we wrote it up in Before an Agent Touches Production Credentials.
Decide where traffic is allowed to go. The incidents worth studying share one shape: data leaves through a permitted path. An agent that can read sensitive files and reach arbitrary endpoints is an exfiltration route waiting on a bad instruction. An egress allowlist is not exotic infrastructure. It is a firewall rule set somebody has to sit down and write.
Assume the workspace gets damaged. Point the agent at something you can regenerate: a branch, a snapshot, a disposable environment. If losing the workspace would hurt, the workspace was too big.
The uncomfortable symmetry
The hard part is not any single control. It is that a legacy estate rarely supports the clean version of them. The system has one shared database login that everything uses. Staging drifted away from production years ago. The batch jobs run as domain admin because that was easier in 2014. Containment work on a legacy estate turns out to be remediation work wearing a different name, and it belongs in the same plan and the same budget.
That cuts the other way too. Every hour spent scoping accounts, separating credentials, and writing egress rules for the agent leaves the estate safer for the humans as well. The agent did not create the exposure. It made the exposure impossible to keep ignoring.
If an agent is headed anywhere near systems that matter, containment is part of the implementation, not an add-on at the end. Our AI implementation framework treats it that way from the first scoping conversation.