Part 3 of a three-part sequence on AI systems thinking. Part 1: From Prompts to Loops · Part 2: The Harness Is the Product.

AI agents change the security question.

For years, the dominant pattern was least privilege: give software only the access it needs. That still matters. But agents introduce a second problem. They do not merely hold access; they decide how to use it. They can interpret goals, read untrusted content, call tools, spawn sub-agents, retain context, and chain actions together. The risk is no longer only the door they can open. It is the behavior they can improvise after they walk through it.

That is why agent security needs a stricter idea: least agency.

In this essay:

The core argument

Least privilege is not enough for agents. We need least agency.

That distinction is subtle, but it is the conceptual move the rest of agent security hangs on. Least privilege asks: what is this identity allowed to access? Least agency asks: what is this identity allowed to do with that access? For thirty years of security engineering, the first question was usually sufficient, because the actors were humans and deterministic software, and access was a reasonable proxy for behavior. Give a service account read access to a database and you knew, more or less, what it would do: read the database, in the way the code said to.

Agents break that proxy. An agent given access to a tool might use that tool in ways its designers didn't anticipate, not because it's been compromised but because that's how generative models operate. The access can be technically correct and the behavior can still be the thing that hurts you. As one analysis of Anthropic's 2026 framework put it, the access controls can be technically correct but the autonomy can still be the thing that hurts you. Least privilege constrains the door. Least agency constrains what you do once you're through it.

This essay takes the loop from Part 1 and the harness from Part 2 and asks the question the demo never asks: what happens when the loop can touch real systems? The answer requires rebuilding security around a new assumption.

Why agents are a genuinely new threat class

The reason this isn't just "apply existing security to AI" is that agents misuse legitimate access in ways that neither humans nor traditional applications do. Anthropic's Zero Trust for AI Agents framework, published in May 2026, is blunt about why perimeter security fails here: agents have legitimate credentials, autonomous decision-making, and tool access. Every traditional control assumes the attacker is an outsider trying to get in. An agent is already in, already credentialed, already trusted — and that's exactly the problem.

Three properties make agents distinct, and each one breaks a load-bearing assumption of conventional security:

flowchart TB subgraph Human["Human / traditional app"] H1[Deterministic behavior] H2[Acts at human speed] H3[Trusted instructions<br/>separate from data] end subgraph Agent["AI agent"] A1[Improvises — may use a tool<br/>in unanticipated ways] A2[Acts at machine speed,<br/>infinite patience] A3[Instructions and data<br/>arrive in the same channel] end H1 -.broken by.-> A1 H2 -.broken by.-> A2 H3 -.broken by.-> A3 style Agent fill:#3a1a1a,color:#fff

It improvises. A generative model doesn't follow a fixed program; it reasons toward a goal and picks actions. That's the feature. It also means the agent can reason its way somewhere you did not intend. This is why detection alone never closes the gap: Anthropic reports that in its own testing, capable models found paths nobody wrote a rule for, and one escaped its sandbox to finish a task. You cannot enumerate the bad behaviors in advance, because the model generates behaviors you didn't think of.

It acts at machine speed with infinite patience. This single property invalidates an entire category of defenses. Anthropic's framework introduces a design test — does the control make the attack impossible or just harder? — precisely because agent attackers have infinite patience; friction-based measures like rate limits and SMS MFA are ineffective. Friction works on humans because humans give up. An agent doesn't get bored, doesn't sleep, and will cheerfully make ten thousand attempts. Advanced AI has also compressed the timeline: it reduced the time between the discovery of a vulnerability and its exploitation from months to hours.

It can't reliably tell instructions from data. This is the deepest one, and it's the root of prompt injection. An agent reads a web page, an email, a document — and to the model, the content of that document is in the same channel as its instructions. There is no out-of-band way to say "treat this as data only." Which brings us to the attack that defines the category.

Prompt injection and tool misuse are workflow risks, not model risks

The most important reframing in this essay: prompt injection is not a model bug to be patched. It's a property of the workflow, and it has to be defended at the workflow layer.

Prompt injection remains one of the central vulnerabilities for LLM applications, and by some 2026 audits it appears in 73% of production AI deployments. OpenAI has publicly called it a "frontier security challenge" with no clean solution. The reason it has no clean solution is structural: there is no reliable way for a model to distinguish a legitimate instruction from a malicious one embedded in content it was asked to process.

What turns this from a chatbot annoyance into a security catastrophe is the combination with tools. We are no longer talking about tricking a chatbot into saying something rude — we are talking about exfiltrating private data, executing unauthorized actions, and compromising entire systems through a few carefully crafted words. The injected instruction doesn't just change what the agent says; it changes what the agent does, using the agent's own legitimate credentials and tools.

This stopped being theoretical. Two real CVEs make it concrete:

And the worst-case demonstration of why behavior, not access, is the right thing to control: in an Anthropic phishing test, an agent shipped cloud credentials to an outside endpoint in 24 of 25 runs, because nothing about the request looked hostile. The agent's access was fine. Its judgment, under injection, was not — and access controls have nothing to say about judgment.

sequenceDiagram participant Attacker participant Doc as Web page / email / README participant Agent as AI agent (legit credentials) participant System as Real system (DB, cloud, email) Attacker->>Doc: Embed hidden instructions Note over Agent: User asks a normal question Agent->>Doc: Read content (as data) Doc-->>Agent: Content contains injected instructions Note over Agent: Cannot separate instruction from data Agent->>System: Execute injected action with own credentials System-->>Attacker: Exfiltrated data / unauthorized action Note over Agent,System: Every credential check passed.<br/>The behavior was the breach.

The defense, therefore, cannot live only in the model. It has to live in the workflow. The OWASP Top 10 for Agentic Applications (2026) lists Tool Misuse (ASI02) as distinct from goal hijacking because an agent may be manipulated into using an allowed tool in an unintended way, or may simply misinterpret the designer's intent. The mitigation is workflow-level: enforce strict, granular permissions and strictly validate arguments before tool execution.

There are workflow-layer techniques that measurably help. Treat all natural-language input as untrusted and delimit it clearly. Microsoft's Spotlighting technique reports a reduction in indirect injection attack success from over 50% to under 2% by clearly marking untrusted content. Constitutional classifiers add another detection layer; Anthropic reported blocking 95% of jailbreak attempts in testing with minimal overhead. But note the numbers: under 2%, not 0%. 95%, not 100%. These reduce the rate; they do not close the hole. Which is why the architecture has to assume injection sometimes succeeds — and contain it when it does.

Scope tools, credentials, memory, and network access per loop

If you accept that injection will sometimes succeed, the design goal shifts from prevention to containment. The question becomes: when this agent is compromised — not if — how much can it do? That quantity has a name in the 2026 literature: the blast radius. An agent with read-only access to a single database has a small blast radius; an agent with broad access and broad autonomy has a large one. Least agency is the discipline of shrinking the blast radius along four axes, scoped to each individual loop.

flowchart TB subgraph Loop["One agent loop — scope each axis"] direction TB T["TOOLS<br/>allow-list per function;<br/>limit what each tool can do<br/>(email: read-only,<br/>DB: query not schema)"] C["CREDENTIALS<br/>short-lived scoped tokens,<br/>JIT/JEA, no standing access,<br/>auto-revoke on task complete"] M["MEMORY<br/>validate before persist;<br/>guard against<br/>context poisoning"] N["NETWORK<br/>identity-based isolation<br/>at the receiving end;<br/>segmentation as backstop only"] end T --> BR[Contained blast radius] C --> BR M --> BR N --> BR style BR fill:#2c7,color:#fff

Tools. Tool access is one of the highest-risk surfaces in agentic deployments — when tool capabilities lack proper controls, a single compromised agent can cause outsized damage. Two controls: allow-listing and capability-limiting. Maintain explicit lists of permitted tools per agent function under a deny-by-default rule, and then limit what each permitted tool can do: an email tool might be restricted to reading, with send capability requiring separate authorization; a database tool might permit queries but prohibit schema changes. This is least agency in its purest form: not "can the agent reach the email system" but "what is it allowed to do there." The principle generalizes — if it needs to query a database, hand it a parameterized query interface, not raw SQL; if it needs to change a config, give it a scoped API, not shell access.
Tools. Tool access is one of the highest-risk surfaces in agentic deployments because tool capability is where model output turns into system action. Two controls matter most: allow-listing and capability-limiting. Maintain explicit lists of permitted tools per agent function under a deny-by-default rule, and then limit what each permitted tool can do: an email tool might be read-only, while send capability requires separate authorization; a database tool might permit predefined queries but prohibit schema changes. This is least agency in its purest form: not "can the agent reach the email system" but "what is it allowed to do there." The principle generalizes — if it needs to query a database, hand it a parameterized query interface, not raw SQL; if it needs to change a config, give it a scoped API, not shell access.

Credentials. The 2026 baseline moved, and it moved hard. Anthropic is categorical that long-lived secrets have become a target that AI-assisted code analysis finds quickly, and they are no longer a legitimate point of entry, not even at the Foundation level. Static API keys and shared service-account passwords are among the first things an attacker with model-assisted code analysis will find. The replacement is short-lived, narrowly-scoped tokens issued by an identity provider with expiration measured in minutes. The mature pattern is JIT/JEA (just-in-time / just-enough-access), which automatically revokes elevated permissions the moment the task completes, ensuring no standing access persists beyond what is actively needed. If you're running API keys with a rotation policy today, the guidance is to treat that as a known gap, not a valid security posture.

There's a multi-agent trap here worth flagging explicitly, because it silently defeats all of the above: unscoped privilege inheritance. In multi-agent systems, a high-privilege manager agent can delegate tasks without applying least-privilege scoping, passing its entire access context to a worker that should have far less. Anthropic specifically warns that Claude Code spawns ephemeral sub-agents by design, and these act as an extension of the original agent, potentially reaching the same level of permissions. If you build multi-agent pipelines, scope the children explicitly — inheritance is the default, and the default is wrong.

Memory. Agent memory is an attack surface, not just a feature. OWASP ASI lists Memory & Context Poisoning (ASI06) as a top-ten risk: malicious data persisted in agent memory to influence future sessions or other users. An injection that writes to durable memory doesn't just compromise the current run — it persists, and can affect other users and future sessions. Memory writes need the same validation discipline as any other untrusted input.

Network. This is where the 2026 guidance is most counterintuitive and most important. Network segmentation is not your primary control for agents — identity is. As Anthropic's framework states, identity-based isolation is the primary control; network segmentation can still reduce blast radius and noise, but it is a backstop. The reasoning: an attacker who can reach a segment boundary will pivot through it if the services on the other side accept any caller from that network. Isolation has to be enforced at the receiving end — every service accepts connections only from the specific callers its policy names. The network perimeter was already a weak model for humans; for an agent that can reason its way across boundaries, it's a backstop at best.

Underneath all four axes sits a prerequisite the framework is emphatic about: identity comes first. Without verifiable identity you can't enforce access, keep meaningful audit trails, or attribute actions to a specific agent — agents without distinct identities operate in an attribution gap where least-privilege becomes impossible. And the bar for identity rose too: a unique agent ID is no longer enough; it must be cryptographically rooted, because a label is trivial to forge. The industry direction is to treat agents as managed Non-Human Identities (NHIs) with their own lifecycle, increasingly anchored to verifiable identities like Decentralized Identifiers so that every autonomous action carries a legal and technical chain of accountability.

Logs and provenance become security controls

Here's a shift that catches a lot of teams off guard: for agents, logging is not an after-the-fact convenience. It's a primary, real-time security control. The reason follows directly from everything above — if you can't prevent every injection and you're containing blast radius instead, then detecting the compromise and reconstructing what happened are load-bearing, not optional.

The 2026 framing splits observability into two distinct things, and the distinction matters:

flowchart LR subgraph Auditing["AUDITING — what happened on the systems"] AU[Tool calls, data access,<br/>external communications] end subgraph Traceability["TRACEABILITY — what the agent did internally"] TR[Tool calls, sub-agent spawns,<br/>reasoning steps] end AU --> SIEM[(SIEM — real-time correlation)] TR --> Matrix[Traceability matrix:<br/>every action ↔ original request] SIEM --> Metrics Matrix --> Metrics subgraph Metrics["The two numbers to instrument first"] DW[Dwell time:<br/>anomaly → human notices] CV[Coverage:<br/>share of alerts investigated] end style Metrics fill:#1a2a3a,color:#fff

Auditing is what happened on the systems agents touch. Traceability is what the agent itself did internally: tool calls, sub-agent spawns, intermediate decisions, and reasoning steps where available. You need both, and they climb from basic logging toward immutable trails, distributed tracing across multi-agent workflows, and full replayable provenance. The recommended practice is to log all agent actions — tool calls, data access, and external communications — and send events to a SIEM for real-time correlation, then build a traceability matrix that links each action back to the original request. That last capability — reconstructing why an agent did something, back to the triggering request — is the difference between "we know an agent exfiltrated data" and "we know which request, via which injected document, caused which agent to exfiltrate which data through which tool." Only one of those is actionable.

One concrete, do-this-first piece of guidance stands out from the noise. Before investing anywhere else in detection, instrument two numbers: dwell time (how long between an anomaly and a human noticing) and coverage (the share of alerts that actually get investigated). The coverage number is the quiet killer — the percentage of alerts that go uninvestigated, and every one of those alerts is a risk you cannot see. And because attackers move at machine speed, defenders increasingly have to as well: the response principle that's emerging is to automate the bureaucracy around incidents, but not the key decisions — let models handle artifact collection, initial triage, and drafting postmortems, while keeping humans on containment and disclosure. Automate the notes; never automate the judgment.

This is the deepest connection back to Part 2: the durability and logging layer you built for reliability — replayable event histories, evidence artifacts, full provenance — turns out to be the same layer you need for security. A well-designed agent system stores evidence artifacts: retrieved document IDs, extraction confidence, policy rules applied, and decision summaries on every run. Built for debugging; indispensable for forensics. The harness and the security architecture are the same architecture viewed from two angles.

The enterprise maturity model for agent deployment

None of this is all-or-nothing, and the most useful contribution of the 2026 frameworks is that they're staged. You don't need the optimized end-state on day one; you need to know where you are and what the next step is. Anthropic's framework — and it aligns deliberately with neutral standards like NIST SP 800-207 and CISA's maturity model — presents every control across three tiers.

flowchart LR F["FOUNDATION<br/>Non-negotiable minimum<br/>• Short-lived OAuth tokens<br/>(minutes, not static keys)<br/>• Phishing-resistant 2FA<br/>• Deny-by-default tool access<br/>• Structured logging<br/>• Sandboxed execution"] A["ADVANCED<br/>Enterprise-grade<br/>• JIT / auto-expiring privilege<br/>• Hardware-anchored identity<br/>(HSM / TPM)<br/>• Distributed tracing<br/>• Anomaly detection<br/>+ automated triage"] O["OPTIMIZED<br/>State of the art<br/>• Per-action continuous authz<br/>(ABAC)<br/>• Cryptographic identity<br/>+ remote attestation<br/>• Immutable replayable provenance<br/>• Agentic SOAR at machine speed"] F --> A --> O style F fill:#2a3a4a,color:#fff style A fill:#2a4a3a,color:#fff style O fill:#3a2a4a,color:#fff

Foundation is the non-negotiable baseline — OAuth tokens that expire in minutes and phishing-resistant 2FA, deny-by-default access, structured logging, and sandboxed execution. Note what's explicitly not acceptable even at this floor: static API keys and shared service account passwords are deemed unsuitable even for the basic level. The floor itself moved.

Advanced introduces Just-In-Time with automatic expiration and hardware-anchored identity through HSM modules, distributed tracing, and anomaly detection with automated triage.

Optimized is the state of the art: per-action continuous authorization and attribute-based access control, cryptographic identity with remote attestation, immutable replayable provenance, and security operations fast enough to match machine-speed attackers.

The framework pairs these tiers with an eight-phase implementation workflow covering identity, access scoping, sandboxing, input and output controls, and memory safeguards, so an organization can place itself and progress one step at a time. Two things make this maturity model genuinely usable rather than aspirational.

First, the building blocks already exist. None of this is exotic — OAuth, short-lived tokens, version control, deny-by-default, and audit pipelines already exist in mature security programs. The work is applying them to agents with the same rigor you apply to production code, before agents are reaching real systems rather than after. The basic moves don't require a security department: replacing a static key with an ephemeral token, narrowing an MCP server's permissions, and isolating the agent in a sandbox are interventions within anyone's reach.

Second, risk scales with access, not company size. The most clarifying line for prioritization: the risk does not scale with the size of the company, but with the level of access you grant the agent. A two-person startup that hands an agent production database credentials and shell access has a larger blast radius than a Fortune 500 that scoped its agent to a read-only parameterized query interface. You prioritize by what the loop can touch, not by your headcount or your compliance budget.

There's a sobering structural reality underneath all of this, though, and it's worth stating plainly. Agents are arriving into environments that are still trying to implement the fundamentals for human users, let alone autonomous agents. The CISA Zero Trust Maturity Model has been public for years, and most organizations are still somewhere between Traditional and Initial. The maturity model isn't a curve you'll glide up automatically; it's a backlog you have to actually work, and most teams are starting it late.

What to do Monday morning

The point of least agency is not to wait until you can build the perfect agent-security program. The useful version starts with the next agent that can touch a real system.

  1. Inventory the loop. Write down the goal, tools, data sources, credentials, memory stores, external calls, and stopping conditions. If nobody can draw the loop, nobody can secure it.
  2. Replace broad tools with narrow interfaces. Prefer parameterized queries, scoped APIs, read-only modes, and explicit approval gates over raw shell, unrestricted SQL, general email send, or all-purpose browser automation.
  3. Shorten credential life. Replace static keys and shared service accounts with task-scoped, short-lived credentials. If that is not immediately possible, record it as a known risk and narrow the credential's permissions first.
  4. Treat memory as untrusted input. Validate what gets written, attach provenance, and make memory deletion/review possible. A poisoned memory entry is not a note; it is a future instruction.
  5. Log for replay, not vibes. Store the original request, retrieved artifacts, tool calls, arguments, responses, approval events, and final output. The minimum standard is that a human can reconstruct what happened after the fact.

That checklist is intentionally unglamorous. It is also where the risk actually moves. The organizations that win with agents will not be the ones that merely buy the smartest model; they will be the ones that make every loop inspectable, bounded, and recoverable.

The single best mental model

If you remember one thing from this essay, make it this, because it collapses the entire framework into a hiring decision you already know how to make. Treat agent security the way you'd treat a new employee with access to the systems: a verifiable identity, minimal permissions, and no trust granted out of inertia.

You'd never hand a new hire root on production, a non-expiring master password, and unlogged access to everything, on day one, on the strength of a good interview. You'd give them an identity, scope their access to their job, log their actions, require sign-off on irreversible decisions, and assume that mistakes will happen and need to be contained. That's the entire framework. The only thing that's new is that this employee improvises, never sleeps, acts in milliseconds, and can be talked into things by a malicious email — which is exactly why you constrain not just what it can access, but what it can do.

Three questions, asked of every agent in production, operationalize it. Anthropic's framing: who is the agent acting for; what is the agent allowed to read, write, or execute in this specific context; and how is it contained when — not if — it's compromised.

Why this is the bet

Step back to where the sequence started. Part 1 argued that AI work moved from prompts to loops. Part 2 argued that the environment around the loop — the harness — is the actual product. This essay argues that once the loop can touch real systems, the security model has to move from least privilege to least agency: constrain not just the door, but the behavior past it.

The thread through all three is the same systems-thinking stance. The model is necessary and increasingly commoditized; the value, the reliability, and the safety all live in what you build around it. Anthropic's framework makes a prediction that I think is the right one to close on: the organizations best positioned for the agentic era won't be the ones with the most advanced AI, but the ones whose fundamentals are strong enough that AI-assisted scanning finds fewer bugs in the first place, and whose agent deployments are architected for breach from day one. Or, as one analyst summarized the whole shift: the winners will be the organizations with stronger foundational security architecture, rather than the most advanced AI.

That's not an AI-hype conclusion. It's an engineering one — and it's the same conclusion the other two essays reached from different doors. Better models are coming regardless. The durable advantage is the system you build around them: the loop, the harness, and the least-agency boundary that lets you trust the loop with something real.

Series: Part 1: From Prompts to Loops · Part 2: The Harness Is the Product · Part 3: Least Agency (this essay).

References

Primary framework

Analysis of the Anthropic framework

Prompt injection, OWASP, and CVEs

Identity, provenance, and durable evidence