Enterprise security was built around a human on the other end of a credential: bounded work at human speed, leaving a trail a reviewer can reconstruct. Autonomous agents violate every part of that. One identity fans out into thousands of actions a minute, the instructions steering it can arrive hidden inside a document it reads, and the logs record that an API was called without recording why. You cannot secure agents by pointing human-era controls at a faster user. Identity, intent, and audit each break differently. Treat every agent as a scoped, monitored identity with hard action limits.
Machine actors break human-era assumptions
Enterprise security was designed around a human on the other end of a credential. A person logs in, does a bounded amount of work at human speed, and leaves a trail a reviewer can reconstruct. Autonomous agents violate every part of that model. One agent identity can fan out into thousands of actions per minute across a dozen systems. The instruction that steers it can arrive not from an authenticated user but embedded in a document the agent reads. And the log, if there is one, records that an API was called without recording why the agent decided to call it. Our position is that you cannot secure agents by pointing human-era controls at a faster user. The three pillars, identity, intent, and audit, each fail in a distinct way, and each needs a distinct fix. Treating an agent as just a fast user is the category error that produces most agent security incidents, because it inherits controls that were calibrated for a human's speed, a human's blast radius, and a human's accountability, none of which describe a machine acting autonomously across your systems.
This is not a future problem to schedule. The moment an agent can read external content and take an action on your systems, prompt injection becomes a live attack surface: a malicious instruction hidden in a webpage, an email, or a support ticket can hijack the agent's next action. The old perimeter assumed the attacker had to get in. With agents, the attacker can send instructions to something you already trusted and that is already inside. This inverts a core assumption of perimeter security. The dangerous input is no longer a payload that breaks in; it is a plausible sentence in a document your agent was designed to read helpfully. The more capable and connected the agent, the larger the surface, which means capability and risk scale together unless the controls scale with them.
Three pillars, three new failure modes
The way to reason about agent security is to take each pillar of the human-era model and ask how it breaks when the actor is a machine, then design the control that closes that specific gap. Extending the human control unchanged is the mistake.
| Pillar | Human-era assumption | How it breaks with agents | The control that holds |
|---|---|---|---|
| Identity | One credential equals one person | One agent credential does the work of thousands of sessions across systems | Scoped, short-lived, per-task agent identities with least privilege |
| Intent | Instructions come from the authenticated user | Malicious instructions arrive as data the agent reads (prompt injection) | Treat all read content as untrusted; separate instructions from data |
| Audit | Logs capture who did what | Logs capture API calls but not the reasoning that triggered them | Record the decision trace, inputs, and prompt version, not just the action |
| Action scope | A user can do anything their role allows | An agent can chain actions to an outcome no one approved | Hard per-action limits and human approval on consequential moves |
| Blast radius | A compromised account is one account | A compromised agent acts at machine speed across every connected system | Rate limits, circuit breakers, and instant revocation of the identity |
A worked example of blast radius: a support agent was given a single service credential with broad read-write access so it could resolve tickets end to end. A customer submitted a ticket whose body contained a hidden instruction telling the agent to export account records. Because the agent trusted the ticket text as instruction and its credential had no action limits, it began exfiltrating data at machine speed. In a redesign, the same agent got a scoped identity limited to the ticket-resolution API, a rule that treated all ticket text as data rather than instruction, a hard cap of 50 record reads per session, and a human approval gate on any export. The identical attack now trips the cap, fails the injection check, and stops at the approval gate, with a decision trace showing exactly what it tried to do. The redesign did not make the agent less useful; it resolved tickets just as well. What changed was that a successful attack now produces a blocked attempt and a clean audit record instead of a data breach. That is the whole game with agent security: not preventing the agent from being targeted, which is impossible, but ensuring the worst outcome of a targeted agent is a logged, contained failure.
Secure the agent as a scoped, monitored identity
If identity, intent, and audit each fail differently, the security program has to address all three at once, because a strong control on one pillar does not compensate for a gap in another. Give every agent its own least-privilege, short-lived identity scoped to the exact task, so a compromise is contained rather than catastrophic. Assume everything an agent reads could be an attack: separate trusted instructions from untrusted data, and never let content the agent retrieves silently redirect its actions. Log the decision, not just the call, so an investigator can reconstruct why the agent acted, using the same provenance discipline you would demand of any consequential AI output. And put hard limits and human approval on the actions that matter, so the worst case is a blocked attempt with a clean audit trail rather than a machine-speed breach. The organizations that get this right will treat each agent as a governed actor with a name, a scope, and a leash, not as a convenient extension of a human's permissions.
The agent-security mistakes to avoid
- Reusing broad human or service credentials: handing an agent a wide standing credential turns any compromise into a machine-speed breach across every connected system.
- Trusting retrieved content as instruction: letting an agent act on text it reads without separating instructions from data leaves prompt injection wide open.
- Logging actions without reasons: recording the API call but not the decision trace makes post-incident investigation impossible and provenance a fiction.
- No action limits or approval gates: an agent that can chain steps to an unapproved outcome will eventually reach one, whether by attack or by error.
- No revocation path: if you cannot instantly kill an agent identity when it misbehaves, a compromised agent keeps acting while you scramble.
Harden your agents this quarter
- Issue every agent a scoped, short-lived, least-privilege identity tied to a single task.
- Treat all content an agent reads as untrusted data and separate it from instructions.
- Log the full decision trace, inputs, and prompt version, not just the action taken.
- Set hard per-session action caps and require human approval on consequential moves.
- Build an instant revocation and circuit-breaker path so a rogue agent can be stopped in seconds.