AI agent security is moving at two speeds: most teams need action-level runtime enforcement now, while Google’s Beyond Zero points to what comes next.
Last week I spoke with five security leaders - at a bank, a retailer, a manufacturer, a hospital network, and a consumer internet company - about how they are securing the AI agents running inside their businesses.
At the same time, I was reading Google’s new paper - Beyond Zero: Enterprise security for the AI era - which describes where enterprise access control could go next. They agreed on the direction, but were operating at very different altitudes.
Google describes a system that can make context-aware security decisions across an enterprise at machine speed. The teams I spoke with were trying to establish something more basic: visibility into their agents, consistent controls across applications, and a way to stop a bad action before it happens.
Agent security is developing at two speeds. Most organizations need the foundation long before they need the frontier. This is what Arcjet provides today (prompt injection detection, PII scanning, AI agent visibility), but the frontier is coming (and is what Arcjet is building for). What we’ve seen with the OpenAI + HuggingFace attack is targeting the most visible today, but that is only the beginning.
Google’s central argument is that application-level access is too coarse for agents:
Individual actions on individual resources are where authorization decisions are made, rather than provisioning access to a tool, application, or feature within an application.
The security leaders I spoke with described the same problem in practical terms. They were not only asking which applications an agent could access - they wanted to know what it was about to do inside those applications, with which data, under whose authority, and with what consequences.
Consider a manufacturer using an agent to read invoices and initiate payments through its ERP. Access to the ERP still matters. An agent that should never enter the system should be stopped at the door, but “ERP access” collapses several very different risks into one permission. Reading an invoice, looking up a supplier, changing bank details, and releasing a payment do not deserve the same treatment. The question is not simply whether the agent may use the ERP. It is whether this payment, for this amount, to this account, based on this invoice, should proceed now.
Application access is the first gate. The action is where the risk is.
The Google paper illustrates this with an internal sales agent that attempts to read a highly sensitive planning document. Both the agent and the employee behind it have valid identities and legitimate access to sales reports. A conventional identity check allows the request.
Beyond Zero considers more than identity. It looks at the employee’s current assignment, the sensitivity of the document, which teams normally use it, and recent access behavior. The credentials are valid, but the requested action does not fit the context.
That distinction came up repeatedly in my conversations. One security leader initially estimated that strong identity would solve most of his agent-security problems. A few minutes later, he made the qualification himself: once an agent has passed the permission check, permissions alone are not enough.
Another was concerned that agents had been given more authority than they needed, with little evidence showing which permissions they actually used. Identity tells you who is acting. Authorization tells you what that identity may do in general. Neither necessarily tells you whether the next action is appropriate.
Agents make this gap more dangerous because they operate faster, across more data and tools, with less human friction. They can also be manipulated while continuing to use valid credentials exactly as designed.
OIDC offers a useful pattern for identity: services accept verifiable claims from a trusted issuer instead of inventing authentication for every integration. Agent systems need the same standard way to carry agent and controlling-user identity to each enforcement point - but identity claims, even when combined with OAuth delegation, do not decide whether a payment or tool call is safe.
The usual answer is to have the agent act on behalf of a human. This is valuable - it preserves attribution, carries the user’s identity into downstream systems, and prevents the agent from becoming an anonymous superuser.
Well-designed delegation can also narrow the agent’s permissions. It does not have to reproduce every permission held by the user. But acting on behalf of someone establishes a chain of authority - it does not prove that the person intended this particular action.
Human permissions are normally provisioned for a range of tasks that someone may perform over months or years. The agent is completing one task now. If a malicious document, tool response, or prompt changes its behavior, it may use legitimate delegated authority for something the user never requested.
That is the confused-deputy problem in an agentic setting. The attacker does not need to steal a credential - they only need to influence a system that already holds one.
The human-delegation model becomes less useful for autonomous workflows. An invoice agent reading from a shared mailbox may not have a meaningful human principal for each message. It will often run under a service identity with standing permissions, bringing the same question back in a different form: does possession of that authority make this action safe?
Least privilege remains essential. Teams should restrict tools, resources, recipients, transaction values, and data access wherever they can.
For the payment workflow, static controls might limit the agent to approved vendors, cap payment amounts, prohibit bank-detail changes, or require a second approval. Those controls would prevent real failures and reduce the blast radius of anything they miss. The limitation is that many important facts only appear at runtime.
An email agent may be allowed to send messages, but the risk depends on the recipient and the data being attached. A payment agent may be allowed to release funds, but the decision depends on the recipient, amount, invoice, recent changes to the supplier record, and perhaps the sequence of actions that led there.
Traditional application roles often authorize the capability without evaluating those details. More granular static policies can do better, but they still need an enforcement point that sees the actual action and its arguments.
Identity and delegation establish who the agent is acting as. Least privilege defines the outer boundary of what it can do. Runtime governance decides whether a specific action should proceed inside that boundary.
Google divides its model into two layers. The floor is consistent baseline policy and enforcement. The ceiling adds dynamic decisions based on identity, resource sensitivity, recent behavior, and other enterprise context.
The five security leaders I spoke with were still building the floor.
They could not reliably identify every agent running in their environment. They could not verify that required controls had been implemented in every workflow. In one company, a red-team exercise found that product teams had independently built their own prompt-injection defenses, repeating many of the same mistakes while the security team lacked a common way to enforce a fix.
These are not yet enterprise-world-model problems. They are enforcement problems.
Before an organization can reason about an action in the context of everything that happened earlier, it needs to see the action, apply a policy to it, stop it when necessary, and record the decision. Before it can vary friction dynamically, it needs a dependable baseline that applies across teams.
The two speeds point in the same direction:
The mistake is not pursuing the ceiling. It is treating the ceiling as a substitute for the floor just because it's the one that sounds cool. Who doesn't want to build an enterprise world model?!
If you own this problem, choose one consequential workflow and make its security boundary explicit. Do not begin with an enterprise-wide reasoning system. Begin with the places where one agent can cause real damage.
This is what we are building at Arcjet: application-native runtime security at the point where an AI workflow is about to act. Today that means enforceable checks for prompt injection, sensitive data, tool access, and rate or spend controls, using context that exists inside the application and producing evidence for every decision.
Over time, those same enforcement points can incorporate richer session and sequence context, but the reasoning only matters if there is somewhere to enforce its decision. Google is describing the ceiling. Arcjet is making the floor deployable while building up from the foundations to reach the ceiling.
How Arcjet hosts AI security models using Python, Open Inference Protocol, Go, and Modal: the architecture behind prompt injection detection.
How we defend Arcjet’s MCP tool outputs from prompt injection by separating trusted guidance from untrusted evidence in structured responses.
How we built Arcjet’s production MCP server in Go: integrating with an existing API, reusing auth and middleware, designing agent tools, and supporting OAuth discovery.
Get the full posts by email every week.
