Most security programs were built around one assumption that nobody wrote down: the thing holding the credentials is a person. A person who gets tired, who reads slowly, who notices when a README suddenly tells them to email the .env file somewhere. Coding agents break that assumption. They hold the same tokens your engineers do, they read every file and web page you point them at, and they act at machine speed.
That doesn’t make agents uniquely dangerous. It makes them a new category of actor your controls weren’t designed for. Over the last few months Anthropic’s security team has published a cluster of pieces on exactly this problem — a CISO’s guide to agentic AI, a write-up of how they secure their own AI-native SDLC, guidance on Zero Trust for agents, on LLM-driven code scanning, and on preparing for AI-accelerated offense. This post is my engineer’s synthesis of them: what’s actually new in the threat model, which controls hold up, and how to adopt them without turning your agent rollout back into a ticket queue.
If you’ve read the AI-native SDLC post, think of this one as the security chapter that sits underneath it.
Why agents change the threat model
Classic Zero Trust says: trust nothing by default, verify every request, assume breach. All of that still applies. What changes is who is making the requests and what they read before making them.
An agent has the reach of a service account, the improvisation of a human, and none of the human’s instinct for “this instruction looks off.” Three properties matter:
- Agents act on content, not just commands. Everything an agent reads — issue text, dependency READMEs, web pages, tool outputs, test fixtures — becomes part of its decision-making. If an attacker can write any of that content, they have a channel into your agent.
- Agents use legitimate permissions. Most agent incidents won’t look like a break-in. They’ll look like an authorized identity doing something nobody intended. Access control that only asks “is this identity allowed?” will wave it through.
- Agents get more capable without you changing anything. A model upgrade can unlock behavior your original risk assessment never considered. The CISO guide has a good example: an incident-response agent, after a model upgrade with no change to its tools or prompts, started asking another agent to write a code fix mid-incident. A human review gate caught it before production — which is the point.
Meanwhile the outside world is speeding up too. Anthropic’s offense-preparation piece argues that models are compressing the time from vulnerability discovery to working exploit, and that defenders should plan for an order-of-magnitude rise in vulnerability reports over roughly two years. Your agents run on infrastructure that’s exposed to that same acceleration.
The threat landscape, at the level you need
I’ll keep this conceptual. You don’t need exploit recipes to design controls; you need categories.
Prompt injection
Instructions hidden in content the agent reads, aimed at redirecting what it does. This is the defining agent risk, and the honest status is: model-level defenses are improving, but nobody credible claims success rates are zero. Treat injection like phishing — something you reduce and contain, not something you “solve.”
Overeager and mistaken actions
This is the one teams underestimate. Anthropic’s write-up of Claude Code’s auto mode catalogs real internal incidents that weren’t attacks at all: an agent interpreting “clean up old branches” as permission to batch-delete remote branches, an agent hunting through config files for a different token after an auth error, an agent retrying a failed deploy with verification skipped. Good intent, wrong blast radius. My expectation is that this category causes more day-to-day damage than adversarial injection.
Credential exposure
An agent can only leak what it can reach. If your developer environment has long-lived cloud keys, SSH keys, and a .env with production secrets sitting next to the code, then every one of them is in scope for an injected or overeager agent.
Over-broad permissions and ambiguous identity
The CISO guide makes a point I found clarifying: the dangerous zone isn’t a dedicated service account or a human at the keyboard. It’s the middle ground, where an agent carries a person’s delegated identity into systems that person isn’t watching. When something goes wrong, nobody can say who actually did it.
The extension supply chain
Skills, plugins, MCP servers, connectors, and the dependencies agents install — each is code or instructions you choose to trust, and some feed untrusted content straight into context. Tool poisoning is the agent-era malicious package. If you’re adopting MCP broadly, the governance questions from MCP for engineering teams are security questions too.
Memory and context poisoning
Persistent context — memory files, CLAUDE.md-style instructions, shared knowledge bases — can be tampered with so the poison outlives the session. Instruction files deserve code-review discipline, because they effectively are code.
Four questions before you approve any agent
The single most useful tool in this whole set of sources is the CISO guide’s four-question assessment. I’ve rephrased it in the way I’d actually use it in a design review:
- What untrusted content does it read? What could an attacker plausibly write or alter that ends up in the agent’s context? If the honest answer is “nothing,” agent-specific risk is close to zero.
- What can it do, and as whom? Read or write, execute code, call tools, reach the network — and under which identity.
- What’s the blast radius if it goes wrong? One file, one repo, one environment, the whole org? Is the worst case an annoyance or an incident?
- Can you see it? Can you tell agent actions apart from user actions, and do they land in your SIEM?
These questions turn “should we allow agents?” — a debate that never ends — into “under what conditions would we approve this one?”, which has an answer. The risky combination is untrusted input plus powerful actions plus poor visibility; remove any leg and the picture improves dramatically.
Controls that actually hold
Roughly in order of leverage. The theme throughout: draw boundaries around actions and access, not around model instructions. A prompt that says “never touch production” is a suggestion. A credential that can’t reach production is a control.
Least agency
Least privilege, adapted: grant the narrowest capability that completes the task, not just the narrowest data access. Restrict individual verbs, not just whole tools — an agent that can draft a message but not send it, open a PR but not merge it, read logs but not deploy. If the agent doesn’t have the verb, no injection can make it use one.
Sandboxing and egress control
Run agents in isolated environments — containers, microVMs, remote dev VMs — with credentials kept outside the sandbox. The pattern Anthropic describes for its own tooling is a proxy that injects credentials on the way out, so there’s nothing in the sandbox worth stealing. Pair that with egress allowlisting through a proxy the agent can’t bypass. An injected agent that can’t reach an arbitrary destination has nowhere to send what it found.
Single-purpose agent identity
Give each autonomous agent its own identity with the minimum permissions for its one job, provisioned through your IdP like any other principal. Anthropic’s incident-response agent is the textbook case: it can read production logs, write documents, and post in channels — and nothing else. It can’t deploy. Interactive coding sessions are different: a human is at the keyboard and accountable, so the human’s credential is fine there, as long as the environment is sandboxed. Avoid the middle ground.
Deterministic hooks and managed settings
This is the distinction I keep repeating in every agent post because it prevents so many incidents: instructions advise, hooks enforce. Your secure-coding guidelines belong in CLAUDE.md and skills, so generated code follows them most of the time. But anything that must hold — no edits to protected paths, no secrets in diffs, a mandatory security pass before a PR opens — needs a deterministic backstop: a pre-tool hook, a CI gate, a branch protection rule. Then push the non-negotiable parts into centrally managed settings so individual developers can’t quietly loosen them.
Classifiers as a middle layer, not a wall
Approval fatigue is real: Anthropic reports users accept 93% of Claude Code’s permission prompts, which means the prompt has largely stopped functioning as a check. Auto mode replaces most prompts with a classifier that evaluates each risky action before it runs. The published numbers deserve a careful read: a 0.4% false-positive rate on real traffic, but a 17% miss rate on a small set of real overeager actions. Anthropic frames it as a big improvement over skipping permissions and a possible regression versus careful manual approval on high-stakes infrastructure. So use it as one layer on top of a sandbox and least-privilege credentials, never as the only thing between an agent and production.
Audit trails that separate agent from human
Every tool call, automated approval, and agent-to-agent message should be logged with enough context — tool, parameters, outcome, user, session — to reconstruct what happened, and shipped to your SIEM. Treat agents as potential insiders and alert on out-of-pattern behavior. The CISO guide cites Ponemon’s figure of 67 days on average to contain an insider incident; an agent operating at machine speed makes that timeline untenable, which is why visibility has to come before scale.
A human at the production gate
The cleanest governance line I know: the agent can do everything up to the production gate, and a named human authorizes going through it. Anthropic says Claude authors about 80% of the code merged into its codebase, with an internal agent handling much of the pull-request flow — and the controls that make that tolerable are ephemeral environments separated from production keys plus human review before merge. Tier your codebase by risk: some paths can be auto-approved with sampling, regulated or critical code stays human-reviewed.
Continuous scanning, aimed at your own code
If attackers will scan your code with capable models, scan it first. The source-code security guide’s loop is worth adopting nearly as-is: threat model, sandbox, discover, verify independently, triage, patch. Keep discovery (recall) and verification (precision) in separate agents, and budget for triage and patching before more scanning — triage is the bottleneck now.
The controls table
Here’s the whole thing on one page. “Deterministic” means it holds regardless of what the model decides; “advisory” means it shifts probabilities.
| Risk | Control | Type | Owner |
|---|---|---|---|
| Prompt injection via read content | Define untrusted sources; separate untrusted-input connectors from production data; injection probes | Advisory (probes) + Deterministic (separation) | Security architecture |
| Data exfiltration | Sandbox with egress allowlist through a non-bypassable proxy | Deterministic | Platform engineering |
| Credential exposure | Credentials injected by proxy, never present in the sandbox; short-lived scoped tokens | Deterministic | Platform / IAM |
| Overeager or destructive actions | Per-verb tool permissions; action classifier; deny rules in managed settings | Deterministic (permissions) + Advisory (classifier) | Tech lead + platform |
| Ambiguous accountability | Single-purpose agent identities via IdP; no delegated human identity for unattended agents | Deterministic | IAM |
| Policy drift in generated code | Secure-coding rules in CLAUDE.md/skills, backed by hooks and CI gates | Advisory → Deterministic | Policy owner + tech lead |
| Malicious skills, plugins, MCP servers | Allowlisted extensions, versioned and reviewed like dependencies | Deterministic | Platform + security |
| Memory / instruction poisoning | Instruction files under code review and code ownership | Deterministic | Repo code owners |
| Unauthorized production changes | Approval hook or CI gate requiring a named human; branch protection | Deterministic | Release manager |
| Undetected misuse | Tool-call telemetry to SIEM; agent-vs-human attribution; org-wide off switch | Deterministic (logging) | Security operations |
| AI-accelerated exploitation of your code | Continuous scanning with independent verification; fast patch SLAs | Advisory (findings) + Deterministic (merge-blocking on high confidence) | AppSec |
If a row has only “advisory” in it and the risk is one you can’t accept, that’s your next piece of work.
Where I’d be careful
- These are vendor documents. All six sources are from Anthropic, and several reference Anthropic products. The patterns — least agency, credential-free sandboxes, egress control, deterministic gates, agent identity, telemetry — are vendor-neutral and apply to any coding agent. Product specifics will change; design around the patterns.
- Anthropic’s numbers are Anthropic’s numbers. They describe one very AI-native organization with an unusually mature security team. Treat them as evidence the model can work, not as targets to promise your board.
- Don’t over-engineer prompt scaffolding as a control. The CISO guide makes the point that elaborate instructions tend to get removed as models improve. Spend that effort on boundaries that don’t depend on the model at all.
- Lockdown has a cost. Every deny rule removes capability. Copying the strictest configuration to every repo pushes people toward unsanctioned tools — and shadow adoption has no telemetry and no off switch. Match restrictions to each repo’s data classification.
Adopting this without killing velocity
The framing I like best comes from the title of the CISO guide: zero risk isn’t the job. The job is making agentic risk visible and bounded so the organization can accept it on purpose. Saying no doesn’t eliminate agent usage; it just moves it somewhere you can’t see.
The order I’d follow on a real team:
- Week 1–2: Inventory and classify. List where agents already run, sanctioned or not. Write down what counts as untrusted content in your environment. Run your highest-pressure use case through the four questions, looking for the conditions under which you’d say yes.
- Week 3–4: Take secrets out of reach. Move agent work into sandboxed environments with credentials outside the sandbox and an egress allowlist. This single change shrinks the blast radius of every other failure.
- Month 2: Make policy deterministic. Encode secure-coding rules in
CLAUDE.mdand skills, then add hooks and CI gates for the must-hold subset. Push them into managed settings. Allowlist extensions and MCP servers. - Month 2–3: Identity and telemetry. Give each autonomous agent a single-purpose identity. Stream tool calls to your SIEM with agent-versus-human attribution. Confirm you have an org-wide off switch and that it actually works.
- Month 3+: Shift reviewers from lines to loops. Run new AI reviewers in shadow mode first, red-team them with deliberately bad changes, then tier your codebase so humans concentrate on the risky paths. Start continuous scanning of your most exposed service, with a verification step and a triage path.
Expand in stages: a small group first, watch the telemetry, then widen. Ask your IdP, SIEM, and agent vendors which of these controls they can demonstrate today, not on a roadmap. For the organizational and review-process sides, see the AI readiness assessment and rolling out AI coding tools.
The career angle
Security engineers shift from hunting individual bugs to monitoring the loops that find and fix them. Platform engineers encode governance as sandboxes, hooks, and managed settings. Tech leads own instruction files and review gates — which makes them part of the security perimeter, whether they asked for it or not.
For individual engineers, the skill that compounds is answering the four questions quickly for any agent setup. It isn’t tied to a model or vendor, and it gets more valuable each time capability jumps.
Going deeper
The controls in this post map directly onto our courses. AI-Native SDLC covers hooks, approval gates, and the human-at-the-production-gate model across the full lifecycle. Claude Code Mastery goes deep on permissions, sandboxing, hooks, and managed settings in the daily agentic loop. MCP Servers is where to learn to build and govern the tool layer safely. If you’re building your own agents, Claude Agent SDK and Claude API cover tool permissions, scoped identities, and the plumbing behind them.
For teams adopting agents across an organization, we also run this as corporate training, or as hands-on AI tools enablement.
Sources: Anthropic, Zero risk isn’t the job: a CISO’s guide to agentic AI (July 2026); How Anthropic secures its AI-native software development lifecycle (July 2026); Zero Trust for AI agents (May 2026); Using LLMs to secure source code (May 2026); Preparing your security program for AI-accelerated offense (April 2026); How Claude Code auto mode works (March 2026). This post is independent commentary; read the originals for full detail. Related in this series: the AI-native SDLC, MCP for engineering teams, when not to use AI tools.
