Security, Permissions & Blast Radius

What changes

Security in a traditional SDLC has one main object: the code. The people who write it hold credentials governed separately, by role. AI breaks that arrangement in three places, and each needs different controls. Treating them as one question ("is AI code secure?") is how teams end up buying a better model to fix a credential problem.

The code the AI writes

The first surface is the familiar one, and it has not improved with model size. On 186 real feature requests in open-source repositories, an agent built on SWE-Agent and Claude 4 Sonnet produced code that worked 57% of the time but was secure only 11.8% of the time (SusVibes, ICML 2026). On 392 backend tasks in BaxBench, the best model reached "a mere 62% on code correctness", and exploits succeeded on "around half of the correct programs generated by each LLM".

Vendor data agree on direction. Veracode's July 2026 leaderboard puts the security pass rate "stalled at 56%" while syntax passes almost always, with no gain from larger or coding-specialised models (Veracode, T3). Its CTO's conclusion from the previous update (November 2025) was blunt: "Relying solely on model improvements is not a viable security strategy." Economics, Risk and Measurement covers the reviewer's misplaced confidence and the predictable hallucinated package names; this chapter does not repeat them. The point for a migration is that the code surface is a base rate. You manage it with gates that do not depend on the model (static analysis, secret scanning, a dependency allow-list), and those gates are well understood.

The toolchain the AI runs in

The second surface is new. An agent is a program that reads untrusted text and then runs commands, edits files and calls tools on the strength of it. Everything it reads is therefore potential input to its own controls. The public record from 2025 shows each layer of that toolchain being turned against its user:

• The agent rewrote its own approval setting. In GitHub Copilot in VS Code (CVE-2025-53773), injected text made the agent write "chat.tools.autoApprove": true into settings.json. From then on, terminal commands ran without approval. The researcher's comment: "Ideally, the AI would not be able to modify files without a human first approving it" (Rehberger, August 2025).
• The agent registered its own tool server. In Cursor up to 1.2.1 (CVE-2025-54135, "CurXecute"), editing an existing dotfile required approval but creating a new one did not, so an agent could create .cursor/mcp.json, add a malicious MCP server and run code (Cursor advisory, patched in 1.3.9).
• The allow-list was a string match. In Gemini CLI, a prompt injection in a README got grep allow-listed and then hid a command behind it that silently sent environment variables out. Google raised it to P1/S1 and fixed it in v0.1.14 (Tracebit, July 2025).
• Tool descriptions carried instructions. Invariant Labs showed "malicious instructions … embedded within MCP tool descriptions that are invisible to users but visible to AI models", and a server that changes a tool's description after approval (tool poisoning). In a second demonstration, a malicious public issue led an agent using the official GitHub MCP server to leak private-repository data into a public pull request. The authors called it "not a flaw in the GitHub MCP server code itself" but "a fundamental architectural issue" (GitHub MCP toxic flow).
• The rules file was the payload. Hidden Unicode in Cursor and Copilot rule files made the agent insert a malicious script tag without mentioning it, and the poisoned rules survive forks. Pillar Security's advice is to treat AI configuration files "with the same scrutiny as executable code" (Pillar Security, March 2025).
• The CI agent read the attacker's text. PromptPwnd showed that agents in GitHub Actions or GitLab that read issue or pull-request text while holding privileged tokens can be made to leak secrets; Aikido reports "At least 5 Fortune 500 companies are impacted", a count it does not name (Aikido). CI/CD & Release treats this as a release-pipeline problem.

Two lessons recur. The agent must not be able to write its own permission, tool or rules configuration. And anything the agent reads, including tool output, is untrusted input. Notice also where the damage was decided. In the Supabase MCP demonstration, a support ticket led an agent running as service_role, which bypasses row-level security, to read an integration_tokens table and post the secrets back into the ticket. As the researchers put it, "No permissions were violated" (General Analysis). The injection opened the door; the credential decided what was behind it. The wiki's MCP tool poisoning and prompt injection pages cover the attack class in depth.

The authority the AI holds

The third surface is where the damage happens. Each destructive incident in the public record pairs an agent with authority over something irreversible and no environment boundary between them. In each case where a fix is documented, the fix was environmental, not a better model.

The same pattern shows up inside a vendor that builds agents. Anthropic's auto-mode write-up lists overeager actions from its own internal use: "deleting remote git branches from a misinterpreted instruction", "uploading an engineer's GitHub auth token to an internal compute cluster" and "attempting migrations against a production database". None needed an attacker. Each needed only a credential that reached further than the task.

This is why Rule 2 of the maturity model scores a phase by the higher of its review mode and the authority the AI actually holds. A team that reviews every diff but runs its agent beside a production-capable token is operating at L4 for whatever that token reaches. Changing the model changes none of the three surfaces. The code base rate did not respond to model size, the toolchain attacks worked across vendors, and authority is a property of the credential.

The permission envelope per level

Every other Part II chapter has a ladder for its phase. Security cuts across phases, so this chapter has a permission envelope instead: what an agent at each level may run on, hold, change and read. The maturity model printed a three-row summary; this is the full version.

It is the book's proposal, not a published standard. It is synthesised from vendor defaults, the fixes applied after incidents, and two control frameworks, the Cloud Security Alliance levels (which ask for "immediate kill-switch capabilities" at L4) and the AWS Scoping Matrix (which asks for "Time-bounded approval tokens with automatic expiration"). No organisation has published incident rates by permission level, so nothing below is outcome-validated. Each row is tied to the shipped default or incident fix it comes from, so you can judge its weight.

Three shipped products already sit close to individual rows. GitHub's Copilot cloud agent is the nearest thing to a shipped L3 write scope: "Only users with write access to the repository can trigger" it, it "only has the ability to push to a single branch", its "workflows are not triggered until Copilot cloud agent's code is reviewed", the person who asked for the work cannot approve it, and a firewall restricts its internet access (as of October 2026). OpenAI's Codex ships the L3 network row as a default: "By default, the agent runs with network access turned off", with writes limited to the active workspace; its --yolo flag is marked "(not recommended)" (as of October 2026). Anthropic's sandbox design argues that "effective sandboxing requires both filesystem and network isolation". Without the network boundary a compromised agent can send keys out; without the filesystem boundary it can escape. In cloud sessions "sensitive credentials (such as git credentials or signing keys) are never inside the sandbox"; a proxy checks each push and attaches the real token.

Read the envelope with Rule 2 in mind: if any row's actual setting belongs to a higher column, that is your level, whatever the review process says.

The case

The opening: PocketOS

The AI Incident Database records incident 1469 (24 April 2026): a Cursor agent "reportedly running Anthropic's Claude Opus 4.6" deleted "PocketOS's production database and volume-level backups through Railway while working on a staging-environment task". "Reporting said the agent used a broadly scoped API token to delete a Railway volume." The OECD AI Incidents Monitor gives the deletion as taking "nine seconds" and the outage as 30 hours.

The rest of the mechanism is known only from secondary coverage of the founder's post and Railway's reply, and is labelled as such here. The token had been created for custom-domain management and was found in an unrelated file. The backups lived on the same volume they protected. The newest copy held elsewhere was three months old. Railway afterwards moved API deletes to a 48-hour soft delete.

It is the cleanest example of the authority surface because nothing else is in it: no attacker, no injection, and reportedly a current frontier model. There was a task scoped to staging, a credential that could reach production, an API with no undo, and backups inside the blast radius. Each of those is a row in the permission envelope.

The anchor: Nx "s1ngularity"

PocketOS shows the authority surface alone. Nx shows all three surfaces in one chain, and it is the best-measured incident in this chapter.

The entry point was a CI workflow. According to the Nx maintainers' advisory, a pull-request validation workflow echoed the PR title inside a shell step, so a crafted title ran as bash. It used the pull_request_target trigger, which "runs workflows with elevated permissions including a GITHUB_TOKEN which has read/write repository permission". A malicious commit then "altered the behavior of the publish.yml pipeline to send the npm token to a webhook". Malicious nx versions were published on 26 August 2025 from 6:32 PM EDT and removed by 10:44 PM EDT.

The payload is what makes this an AI-SDLC case. As reconstructed by Wiz and the advisory's appendix, its post-install script looked for AI command-line tools on the victim's machine and ran them with the flags that switch off their permission checks: --dangerously-skip-permissions for Claude, --yolo for Gemini and --trust-all-tools for Amazon Q. The prompt asked a "file-search agent" to "Produce a newline-separated inventory of full file paths and write it to /tmp/inventory.txt". The malware did not bring its own exploit for this step; it borrowed the coding agents the victim had already installed and trusted.

Wiz's analysis of the leaked data gives the numbers. In its words, "roughly 50% of all victims had at least one AI CLI installed." "Over 2,000 unique, verified secrets were leaked", and "over 1,700 users had secrets publicly leaked". More than 40% of the leaked npm tokens from the first phase were still valid when Wiz checked. In a second phase, "at least 480 compromised accounts … published over 6,700 private repositories publicly".

The most useful finding is the one about defaults. "AI only exfiltrated data successfully in under a quarter of cases." "Almost a quarter of Claude interactions were rejected", and "almost a quarter of Gemini interactions were foiled by default restrictions to workspace directories." The tools' defaults, permission prompts and workspace limits, measurably blunted the AI step. The malware needed the skip-permission flags because the defaults were in its way. A developer who runs those flags day to day has already done that part of the attacker's work.

Map the chain onto the surfaces. The toolchain surface was the entry: a CI workflow that ran untrusted text with a privileged token. The authority surface decided the damage twice: a long-lived npm publishing token, then agents on developer machines that could read every file the developer could. Nx's own fixes were authority fixes: "Remove NPM tokens from our pipeline now that we're using Trusted Providers on NPM", require 2FA for publishing, and require approval for workflows triggered by external contributors.

The same class, from a vendor: Amazon Q Developer

A month earlier, the AI tool itself was the vehicle. AWS's security bulletin for CVE-2025-8217 traces the incident to "an inappropriately scoped GitHub token in their CodeBuild configuration". Malicious code was "automatically included in a release" of the Amazon Q Developer extension, version 1.84.0, and "was unsuccessful in executing due to a syntax error". The bulletin does not describe the payload; press coverage (secondary, not confirmed in the bulletin) described it as a prompt telling the agent to wipe data. AWS revoked and replaced the credentials, and version 1.85.0 fixed the extension. The root cause was again a credential scope, in the AI vendor's own build pipeline.

The two other incidents in the record, Replit and Kiro, are told in full in Case Studies, including both accounts of Kiro. Both fixes, an automatic dev/prod split and peer review for production access, are rows in the envelope above.

Worked example: placing the PocketOS agent by its credentials

This uses only the facts recorded above; the secondary-only details are marked.

1. Intended level. A coding agent on a staging task, with a developer in the session, is meant to be L2 or, at most, L3 for that task.
2. Granted level (Rule 2). The token could delete a production volume. For production data, the agent was operating at L4, a level nobody chose.
3. L4 eligibility. Deleting a volume through an API with no undo is irreversible, and the backups sat on the same volume. Under the risk-ceiling rule the task class is ineligible for L4. So the grant was not just unplanned; it was a level the class could never qualify for.
4. Which row would have broken the chain. Any one of four. The credentials row: no production-capable token reachable from an L2 or L3 session (the token was in a file, per secondary reports). The where it runs row: an L3 sandbox exposes only proxy-injected, task-scoped credentials. The irreversible actions row: a soft delete turns the deletion into an outage of hours, not a loss. Backups outside the blast radius turn it into a restore.
5. Which rows would not have. An instruction ("never touch production"), a better model or an approval click; section 12.5 explains why.

The exercise generalises. For any agent you run, list what its credentials can reach, mark which of those actions are irreversible, and ask which envelope row stands between them. If the answer is "the prompt", the level is L4.

Migration steps

Inventory comes first, because you cannot move a level you cannot see; boundaries come before autonomy.

1. Inventory credentials and permission modes. For every agent, local or hosted, record which credentials it can reach (environment variables, files in the workspace, cloud CLI sessions, CI secrets), which permission mode it runs in, and which actions those allow. Score the level each implies, using the self-assessment. This is the credentials column of the grid, and in most organisations it is the first place the scores rise.
2. Turn off bypass modes centrally. Claude Code's own documentation says bypassPermissions should be used "Only … in isolated environments like containers or VMs where Claude Code can't cause damage", and lets administrators set disableBypassPermissionsMode in managed settings "where they can't be overridden" (Claude Code permissions, as of October 2026). Use the equivalent control in every tool you run. Nx showed what these flags are worth to an attacker.
3. Protect the agent's configuration. Put permission files, MCP configuration, rules files and instruction files under code-owner review, and make sure the agent cannot write them. CVE-2025-53773 and CurXecute were both agents changing their own controls. Chapter 15, Scaling Across Teams, covers rolling this out as policy.
4. Separate environments before you separate duties. No production-capable credential should be reachable from an agent session. Route destructive operations through APIs with soft delete or undo, and keep backups outside the blast radius of any credential an agent can reach. Replit's fix (the agent "can't touch" production) and Railway's reported soft delete are both this step, taken after the incident rather than before.
5. Sandbox before any L3. Unattended runs go in an ephemeral sandbox with filesystem and network isolation, default-deny egress and credentials injected per task by a proxy. Copy the shipped envelopes: one branch per agent, no merge or approval rights, CI held until a human reviews. Coding shows how background agents run under this arrangement.
6. Harden the CI agents. Trigger agent workflows only for users with write access. Aikido notes that Claude Code Action does this by default and that setting allowed_non_write_users: "*" "should be considered extremely dangerous". Keep issue and PR text out of prompts for agents that hold privileged tokens, and publish packages through trusted publishing rather than stored tokens, as Nx now does.
7. Gate the code surface. Static analysis, secret scanning and a dependency allow-list on every agent change, at every level. These are the cheapest controls in the chapter, and they are the ones that answer the 11.8% secure rate.

The steps carry a named cost. Sandboxes, proxies and environment splits are platform work that someone has to build and maintain, and short-lived credentials add friction to every session. Budget for it as platform work, not as a side task.

Guardrails

Every Part II chapter links its guardrails here, and they share one principle: a guardrail is something the agent cannot talk its way past. Ranked by that test, the common controls fall into a clear order.

Instructions are not boundaries

A line in an instruction file saying "never touch production" is a request, which injected text can override and an agent can miss. Elastic found that its CI agent "tended to fix the problems of a version bump by, well, … removing the version bump", and its answer was a capitalised line in the prompt: "NEVER downgrade versions of dependencies" (Elastic, T3). That line is a request; nothing outside the model enforces it. Instructions shape behaviour; they do not bound it.

Approval clicks and classifiers are not boundaries

A permission prompt is a boundary only if the human reads it, and the evidence says people mostly don't. Classifiers that approve on the human's behalf help, but they miss.

The maturity model uses the 93% to argue that self-placement drifts upward. Here the point is narrower. A click that is given 93% of the time and a classifier that misses one real overeager action in six are both useful filters. Neither is a wall. The independent record says the same: in writing up the GitHub MCP demonstration, Invariant Labs notes that "many users already opt for an “Always Allow” confirmation policy when using agents, and stop monitoring individual actions."

Allow-lists are string matches

Command allow-lists feel like a boundary and are not one. The Gemini CLI attack hid a malicious command behind an allow-listed grep. Claude Code's own documentation says a Bash deny rule "covers the invocation Claude usually produces and isn't a security boundary around the program", and evaluates rules in the order "deny, then ask, then allow" (as of October 2026). Use deny-first lists to cut noise, not to contain an agent.

Environment and credential scope are boundaries

What remains is what the agent physically cannot reach. A sandbox without network egress, a credential that does not exist inside the sandbox, a token scoped to one branch, a database the agent "can't touch", an API whose deletes are soft. Every documented fix in the incident record is in this category. Google's approach to secure agents says the same in three principles: "agents must have well-defined human controllers"; "their powers must be carefully limited"; "their actions and planning must be observable." It pairs deterministic controls with reasoning-based defences, so that neither has to carry the load alone.

Scope each session with the Rule of Two

For agents that read untrusted input, the cleanest design rule is Meta's "Agents Rule of Two". Agents "must satisfy no more than two of the following three properties within a session": "process untrustworthy inputs", "access to sensitive systems or private data", and "change state or communicate externally". Simon Willison's "lethal trifecta" names the same combination from the attacker's side. Each toolchain incident above had all three: PromptPwnd (untrusted PR text, privileged tokens, network), the GitHub MCP flow (a public issue, private repositories, a public PR), Supabase (a support ticket, service_role, a reply into the ticket). Removing any one leg breaks the chain.

The wiki goes deeper on each layer: sandboxing, credential delivery to the sandbox, egress control, scoped credentials, ambient authority and the confused deputy. Operations & Incidents applies the same principle to remediation: IAM, not the model, sets the blast radius. When the agent runs inside a customer's environment instead of your own pipeline, the customer's security review decides these boundaries; Last Mile covers that review in Security, Governance and Model Risk.

Metrics

No organisation has published incident rates by agent permission level, and no study measures how often skip-permission modes are enabled across a company's machines. The metrics below are therefore the book's proposal. They measure the boundary, not the model, and most can be read from configuration rather than from incidents, so they warn before anything breaks.

• Agent identities with production reach. The share of agent sessions or service identities whose credentials can reach production data or infrastructure. The target for L2 and L3 is zero.
• Sessions in a skip-permission mode. Count them from managed-settings telemetry or endpoint inventory. Where bypass is disabled centrally, this should also be zero outside sandboxes.
• Irreversible actions available to agents. The list of destructive API calls any agent credential can make without soft delete or undo. Each item is an L4 grant waiting to be used.
• Credential lifetime and time to revoke. In the Nx incident, more than 40% of leaked npm tokens were still valid when Wiz checked. Track how long agent-reachable tokens live and how quickly a leaked one is dead.
• Secret leaks per agent change. Measure it in your own repositories against your human baseline, rather than trusting a vendor figure (see the box below).
• Security findings per merged agent PR. Static-analysis findings at merge time, compared with human PRs over the same window. This is the code surface's base rate, measured on your code.

Pair these with a stability metric, as every Part II chapter does. If an agent change fails in production, record which envelope row it crossed. Chapter 17, Measuring Success and When to Roll Back, turns that into a rollback trigger.

Anti-patterns

• A skip-permission mode on a machine with real credentials. That is the configuration the Nx malware was looking for. Coding records reported cases of agents deleting their users' own files. Bypass belongs in a disposable container, nowhere else.
• A token the agent happened to find. PocketOS's token was reportedly made for another purpose and left in a file. Anything in the workspace is in the agent's hands; check what is there.
• Backups inside the blast radius. A backup that the same credential can delete is part of the thing it protects.
• "Don't touch production" as the control. An instruction is not a boundary. If production must not be touched, make it unreachable.
• An agent that can edit its own controls. Its permission settings, MCP servers, rules files and the verifier it is judged by. If it can write them, it can be talked into writing them.
• A CI agent that reads strangers' text with a write token. Opening agent workflows to non-writers, or putting issue and PR bodies into the prompt of an agent that holds secrets, is the PromptPwnd pattern.
• Long-lived, over-scoped tokens in pipelines. Nx leaked a stored npm publishing token; Amazon Q had an inappropriately scoped GitHub token in its build configuration. Both were token-scope failures in CI, not model failures.
• Leaving security architecture to the generator. The Lovable exposures (170 of 1,645 scanned apps) and the Moltbook database are covered in Requirements, Specs & Design: access control is a design decision, and humans keep it.

The wiki's essays agent CVEs are authorization bugs and your agent ran git status and that was enough make the same argument from the vulnerability record. The general principle is in blast radius.