Over the past year, most of our conversations with security leaders about AI agents started with discovery. Teams wanted to know which agents were operating in their environment, which MCP servers those agents connected to, which models they called, and which had been approved. That work is still under way at many organizations, and it is more complex than it first appears. Identity counts pulled from identity providers, cloud platforms, and security tools often don't reconcile, in part because each tool defines a non-human identity differently.
Once agents are embedded in business workflows, discovery is no longer the hardest question. One customer told us that when a user engages with an AI tool the company built internally, the security team wants an end-to-end trace from that user into the tool and through the models, services, and other agents behind it, with every human identity mapped to every non-human identity along the way. Once that trace exists, the next question is which access controls to enforce across it.
Two years ago, much of the conversation about agent access centered on on-behalf-of (OBO) tokens. An agent acting for a user would be scoped down to what that user is permitted to do, so two people using the same agent no longer inherited the same access. That was progress, but an OBO token carries delegated scopes consented up front, provisioned for the agent's full range of functions rather than the task at hand, and the agent holds those scopes at every step. OWASP traces excessive agency to three root causes, which are excessive functionality, excessive permissions, and excessive autonomy, and OBO tokens leave excessive permissions in place. Goal-oriented agents raise the stakes. As we explored in how task-oriented and goal-oriented agents carry different security risks, these agents receive an objective and determine their own path toward it, so their autonomy is high by design. That makes the permissions they hold the most direct control point for limiting their actions, and eliminating standing permissions is the first step.
Standing Privileges Expand the Blast Radius of Every Agent Mistake
Most of those agents hold a long-lived API key or OAuth token provisioned for every function the agent might perform, issued once and rarely reviewed. A coding agent that needs read access to one repository ends up with write access to the organization, and a support agent that needs to look up one ticket holds a token that can close, reassign, and export every ticket. When prompt injection, MCP tool poisoning, or a reasoning error turns that agent against its task, the blast radius extends to everything the credential allows rather than the single step in progress. OWASP's Top 10 for Agentic Applications names this risk identity and privilege abuse (ASI03). Goal-oriented agents compound the problem, because their execution path isn't predetermined and the identity they operate under can shift across the workflow.
An Agent's Identity Changes at Every Step of a Goal-Oriented Workflow
The path a goal-oriented agent chooses rarely stays within one system. A single workflow can access an identity provider, several SaaS APIs, MCP servers, models, and sub-agents that carry credentials of their own. Each hop presents its own credential, and because no single system sees the workflow end to end, none of them can evaluate whether a given hop is consistent with the workflow as a whole. As the agent adapts, it can assume other identities across that chain, obtaining a credential in one context and presenting it in another. That is what happened in the PocketOS incident in April, when a coding agent on a routine staging task hit a credential mismatch, found an API token in a file unrelated to its task, and used that token's authority across the infrastructure provider's entire API to delete the volume holding the production database and its backups. The provider's API saw only a valid credential.
Permissions granted at the start of a workflow are therefore an unreliable indicator of the access an agent will hold several steps later. Because a model determines the agent's actions at runtime, any privilege granted just in case will eventually be used, whether by accident or under adversarial input, and narrowing standing privileges reduces exposure without eliminating it. These workflows call for access that is granted only when a specific step requires it, tied to the user who initiated the workflow and bound to a single transaction from the initial request until the agent completes its goal.
Just-in-Time Authorization Starts Every Agent with Zero Standing Privileges
Just-in-time (JIT) authorization is built on that principle. An agent begins with an identity and zero standing privileges. When it needs to act, it requests a specific scope on a named resource along with its own reasoning for why the workflow requires it, such as write access to one ticket to post a resolution the user approved. An approved request returns a short-lived credential limited to that resource and that action, the authorization decision is recorded against the workflow, and access expires when the task completes or the credential's time-to-live (TTL) elapses.
Each credential is limited to a single resource, such as one repository, ticket, or mailbox rather than a whole tenant, to the specific action the task requires rather than every operation the API supports, and to a TTL sized to the task. Elevation means issuing a new credential rather than expanding an existing one, and revocation happens at the gateway, independent of how each target system handles tokens. Because an agent that needs additional access must request it again, every request is evaluated against policy, but JIT alone doesn't determine on what basis a request should be granted.
Intent Decides Whether an Agent Receives the Access It Requests
Issuing short-lived tokens is the straightforward part. An approach that honors every request from an authenticated agent only shortens the life of the credential and leaves the authorization decision unexamined, and controls that inspect one prompt or one tool call at a time can't make that decision either, because the same request can be legitimate or harmful depending on the workflow it belongs to. Reading the customer list is routine inside a support workflow and an exfiltration step inside one that began as a marketing summary.
Proofpoint AI Security makes that decision by evaluating each authorization request against the whole workflow, including the user who delegated it, the agent making the request, the intent declared when the workflow began, every scope already granted, and the agent's behavior so far. Intent includes both the purpose the agent was built for and the purpose of the user invoking it, so an agent built as a financial advisor that requests write access to a code repository falls outside its purpose. A request whose stated reasoning doesn't match the agent's observed behavior in the workflow is itself an anomaly, and the same scope can be approved in one workflow and denied in another, because the decision follows intent rather than a static permission list.
This is where JIT authorization and Proofpoint's Intent-Based Access Control (IBAC) work together. IBAC evaluates each action against the scope of the originating user request at runtime, and JIT applies the same judgment to the permissions the agent holds. An indirect prompt injection that instructs an agent to export every customer record shows the difference. The injection is how the attack begins, and semantic privilege escalation is the violation it aims for, in which the agent uses authorized permissions to act outside what the user intended. Under JIT, the permission the attack needs doesn't exist until intent justifies it, so the attack fails at the authorization request and the injected reasoning becomes evidence. For that model to scale across an enterprise, though, it has to operate transparently to the users agents act on behalf of.
Open Standards Let JIT Authorization Work without Interrupting Users
An agent that stops to ask its user to sign in again every time it needs a narrower scope will be bypassed or abandoned, so JIT depends on a way to obtain scoped access through the enterprise identity provider without user interaction. Over the past year, the industry has consolidated around one approach. The Identity Assertion JWT Authorization Grant (ID-JAG), an IETF OAuth working group draft, lets a client exchange the user's SSO identity assertion at the IdP for a signed authorization grant, and then present that grant to the target application's authorization server in exchange for an access token. Okta's Cross App Access (XAA) builds on ID-JAG, and in June 2026 the same flow became an official authorization extension for the Model Context Protocol, called Enterprise-Managed Authorization.
The Proofpoint AI Security Gateway obtains the ID-JAG from the IdP on the agent's behalf, with the scope limited to what the policy engine approved, so the IdP and the target application both see a least-privilege request instead of a standing one. The enterprise IdP remains the authoritative source for access policy, target applications need no Proofpoint-specific logic, and MCP servers behind the gateway receive per-workflow, per-user tokens in place of shared API keys stored in MCP configurations. For systems with no OAuth authorization server, such as legacy APIs, databases, cloud IAM, and SSH, the gateway brokers short-lived credentials through connectors. The standards define how a scoped authorization grant moves from the IdP to the target application, but nothing in them evaluates whether a request fits the intent of the workflow it came from. That decision stays with the gateway.
Every Authorization Decision Becomes Part of the Audit Trail
Because every authorization decision passes through the gateway, each decision is tied to a user, an agent, a stated reason, and a workflow. That adds the full authorization history to the end-to-end trace customers have been asking for. Questions such as which resources an agent could access on a given date have a definitive answer, and investigators can follow a workflow from the user's request through every scope requested, granted, and denied to the point where an agent's reasoning diverged from its task. It also changes agent onboarding, which no longer requires reviewing a permission list, because no permissions exist until a workflow requires them.
Goal-Oriented Agents Need Controls That Decide at Every Step
A year of discovery has given many security teams an inventory of their agents, and end-to-end tracing gives them visibility into agent activity across each workflow. The remaining challenge is authorization, meaning which access each agent should hold at each step. A goal-oriented agent determines its own path, so the controls that secure it have to verify at every step that the path still serves the user's intent. IBAC evaluates each action the agent takes, and JIT authorization determines whether the agent holds the permission to take it at all, starting from zero standing privileges and granting access scoped to the task and limited to its duration.
Learn more about Proofpoint's approach: https://www.proofpoint.com/us/products/agentic-ai-security