Agents Are Here. They Are Multiplying. The Enterprise Security Model Is Not Ready.

Part 1 of 4

Agents Are Here. They Are Multiplying. The Enterprise Security Model Is Not Ready.

Every CISO or security professional I speak with describes the same problem. “This new wave of agents operate with almost unbounded permissions,” one told me. “I can’t tell they are doing something wrong until after the fact,” said another. A third put it most plainly: “These agents act like employees, but they are not employees and are not bound by the same rules — and that is worrisome.” The anxiety is consistent. The incidents confirming it are multiplying.

Figure 1, Agents Running Wild

In February 2026, the Financial Times reported on a December 2025 AWS service interruption involving an AI coding agent that was allowed to make changes to AWS Cost Explorer and reportedly chose to delete and recreate an environment.[1] A valid tool, operating under valid access, reached a production environment with authority the task should not have carried.

Simon Willison, who coined the term prompt injection, identified the structural condition behind this pattern as the lethal trifecta: an agent with access to private data, exposure to untrusted content, and the ability to communicate externally.[3] Security researcher Johann Rehberger has documented the operational consequences repeatedly, including an agent that independently escalated its own permissions and installed command-and-control malware through valid tool calls.[6][7] In April 2026, the Cloud Security Alliance reported that 65% of organizations had experienced at least one AI agent-related security incident in the previous year. Among those incidents, 61% involved data exposure, 43% involved operational disruption, and 41% involved unintended actions in business processes.[4] The Financial Times reported that Amazon retail outages were linked in internal documents to GenAI-assisted changes.[2] Fortune separately reported that Replit’s AI coding agent deleted a live production database during an active code freeze.[5]

These are early warnings from agents operating near individual users and development environments. The larger risk appears when the same personal/coding-agent security model moves into business-process execution: invoice review, claims processing, legal preparation, system-of-record updates, payment triggers, and enterprise outputs. A model built around inherited user credentials and workspace-level access was never designed for that environment.

Enterprise agent security requires a different chain of control: identity -> task-scoped grant -> runtime enforcement. Identity establishes which agent is acting. A task-scoped grant defines what that agent may do for one specific execution. Runtime enforcement validates every skill request, tool call, route, and release decision against that grant. Each layer depends on the one before it: enforcement without a grant is guesswork, and a grant without stable identity cannot be attributed or audited. This article introduces the framework. The three articles that follow develop each layer in depth: agent identity, agent authorization, and agent execution.

Building the right security model starts with understanding where the current one fails.

Figure 2, A New Agent Security Architecture

Business-Process Agents Require a Different Security Model

Once agents enter enterprise workflows, the control question changes. It is no longer enough to know that the agent, user, or runtime has access to a system. The platform must know whether this specific action is allowed for this specific process instance, under the current task authority.

The mismatch appears when a valid credential and a valid tool call produce an invalid business action. An invoice agent may be allowed to read one invoice, validate one vendor, and create one exception case. The same inherited workspace or user credential may also reach payment records, vendor master data, customer files, or release channels that the task never required. If the credential is valid and the tool call succeeds, the platform still needs to know whether the action was authorized for that business process instance.

Agent Identity Is the Foundation

Every governed agent needs a stable, verifiable identity. The enterprise must know which agent acted, which version ran, who owns it, what lifecycle state it is in, and which classes of work it is eligible to perform. Identity supports registration, authentication, ownership, versioning, suspension, revocation, tenant binding, and audit.

Existing identity systems were built mostly for humans and services. Human identity assumes an accountable person behind the session. Service identity assumes a relatively stable workload with reviewed behavior. Agents sit between those categories: they are software actors with versions, owners, capabilities, task eligibility, lifecycle state, and deployment context. A governed agent identity has to carry structure that human and service identities usually do not: version, owner, lifecycle state, task eligibility, runtime binding, and deployment context.

Task-Scoped Grants Define the Authorization Boundary

Roles express broad eligibility; grants define execution authority. An agent may be eligible for invoice review, claims triage, or contract analysis, but each task still needs a short-lived grant that defines the permitted skills, tools, data domains, routes, actions, evidence requirements, and expiry for that specific run. Without task-scoped grants, authority defaults to whatever the ambient environment provides: the user’s credentials, the agent’s assigned role, the network’s trust level, or the runtime’s permissions -- each too broad and too durable for individual task execution. Task-scoped grants replace that ambient authority with boundaries drawn at the task level.

Grant construction becomes difficult once agents delegate work. A parent agent may split a task across extraction, validation, policy review, fraud scoring, and release preparation. Each child agent needs enough authority to complete its subtask, but not the full authority of the parent workflow. The authorization model has to decide whether authority is inherited, narrowed, renewed, supplemented, or reissued as a derived grant.

Runtime Enforcement Makes the Boundary Real

A grant has value only when services enforce it. The agent can reason about the task and request skills, tools, routes, or output release, but enterprise-controlled services must validate those requests before acting. Skill Services decide whether skill material can be served. Tool Services decide whether a requested action is allowed. Release controls decide what can leave the process, to whom, and through which channel. Audit evidence records the decisions that prove the execution stayed inside its approved boundary.

The difficult part is coverage. Enforcement works only where every capability the agent can reach is registered, mediated, and checked. A tool exposed outside the Tool Service, a route outside the approved message fabric, a skill file served from an unmanaged store, or a release path hidden in application code becomes a gap in the boundary. The enforcement layer has to cover everything the agent can reach, not only the capabilities the platform remembers to govern.

Each layer will be developed in a dedicated future article.

Agent Identity: The Foundation for Secure and Safe Agents (Part 1 of 3)

This article defines what agent identity requires structurally: registration, authentication, versioning, lifecycle state, ownership, and tenant binding. Most enterprises will try to map that onto existing service-account infrastructure. Service accounts authenticate a workload. They carry no lifecycle state, version awareness, task eligibility, owner accountability, or tenant binding. If identity is too coarse, every downstream control inherits the ambiguity.

Agent Trust: The Authorization Boundary (Part 2 of 3)

Persistent role-based authority is too broad for agent execution because roles cannot describe the conditions of one task instance. This article examines how task-scoped grants are constructed, what they must define, and how the grant becomes the authorization reference point for every subsequent enforcement decision.

Delegation is where the model is easiest to get wrong. A grant issued to an orchestrating agent does not automatically extend to the sub-agents it spawns. If enterprises allow grant inheritance across agent boundaries, the authorization model collapses at the point where agentic workflows become most useful: decomposition, specialization, retry, and review. The article develops the derived-grant model needed to keep authority narrower than the parent task while preserving audit lineage across the execution graph.

Agent Execution: The Enforcement Boundary (Part 3 of 3)

This article shows how enterprise-controlled services outside the agent validate each request and why the agent’s own reasoning cannot be the enforcement point. An agent that enforces its own boundaries is an agent that could reason its way past them.

If a tool wrapper, route handler, skill server, or release path trusts the agent’s own assertion that an action is allowed, the grant has become advisory. Enforcement services turn the grant into a runtime control. They also turn each decision into evidence: what was requested, what was allowed, what was denied, and why.

---

---

Looking for more?
👉 Discover the full O’Reilly Agentic Mesh book by Eric Broda and Davis Broda

🎧 Follow The Agentic Mesh Podcast on YouTube, Spotify, and Apple Podcasts. A new video every week!

---

Endnotes

[1]: Rafe Rosner-Uddin, Financial Times, “Amazon service was taken down by AI coding bot,” February 20, 2026, https://www.ft.com/content/00c282de-ed14-4acd-a948-bc8d6bdb339d

[2]: Financial Times, “Amazon holds engineering meeting following AI-related outages,” March 11, 2026, https://www.ft.com/content/7cab4ec7-4712-4137-b602-119a44f771de

[3]: Simon Willison, “The lethal trifecta for AI agents: private data, untrusted content, and external communication,” June 16, 2025, https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/.

[4]: Cloud Security Alliance, “New Cloud Security Alliance Survey Reveals 82% of Enterprises Have Unknown AI Agents in Their Environments,” April 21, 2026, https://cloudsecurityalliance.org/press-releases/2026/04/21/new-cloud-security-alliance-survey-reveals-82-of-enterprises-have-unknown-ai-agents-in-their-environments.

[5]: Fortune, “An AI-powered coding tool wiped out a software company’s database, then apologized for a ‘catastrophic failure on my part,’” July 23, 2025, https://fortune.com/2025/07/23/ai-coding-tool-replit-wiped-database-called-it-a-catastrophic-failure/.

[6]: Johann Rehberger, “I Spent $500 To Test Devin AI For Prompt Injection So That You Don’t Have To,” Embrace The Red, August 6, 2025, https://embracethered.com/blog/posts/2025/devin-i-spent-usd500-to-hack-devin/.

[7]: Johann Rehberger, “Agent Commander: Promptware-Powered Command and Control,” Embrace The Red, March 16, 2026, https://embracethered.com/blog/posts/2026/agent-commander-your-agent-works-for-me-now/.