AI models reason better, hold far more text in their context windows and can now read images. Yet most large companies still won’t let AI agents, the systems that carry out multistep tasks on a person’s behalf, act on their own in real business systems. The blocker is not intelligence but authorization: nobody can say with confidence what an agent may do at a given moment. A growing answer is runtime authorization: deciding whether each tool call is acceptable at the moment the agent makes it, based on whom the agent works for and what it was asked to do.

Why yesterday’s permission model breaks

Regulated companies such as banks put security, trust and business continuity first, and innovation ranks second, third or even fourth. Their systems are a patchwork of identity islands and authorization schemes stacked up over several generations of software, built for deterministic programs and predictable human operators. A large language model (LLM) that can respond differently to the same request does not fit that mold.

OAuth, the standard that lets one website act on a user’s behalf at another, shows the gap. A co-creator of OAuth explains that it was designed for static website-to-website delegation: apps register in advance, users get redirected through a browser, and the scopes, or permission bundles, are fixed ahead of time. An agent cannot know in advance which tools a task will need, because its path changes from one run to the next.

The permissions themselves are also too coarse. Salesforce historically offered a single broad API scope. The Notion server for the Model Context Protocol (MCP), the standard that connects AI models to outside tools and data, exposes a general page-fetching tool that cannot easily be limited to particular sub-databases. Hand an agent permissions that coarse, and a routine bug hunt in a staging environment could end with a wiped production database.

Authorize the transaction, not just the person

JPMorgan Chase’s global chief security architect compares agent permissions to onboarding a new developer. Nobody gets commit access to production on day one. Access widens as the person proves reliable, and agents should earn autonomy the same way.

Banks, he notes, made a similar shift decades ago, moving from simply confirming who a customer is to approving each transaction at runtime, in context. A paper check captures the idea. The memo line records the intent behind the payment, while the payee, amount and date set hard limits. Recording intent with every agent action does the same for security teams, who can then see why each step happened and debug failures faster.

That context has to come from objective signals rather than the agent vouching for itself: whether it runs inside a sandbox, an isolated environment cut off from other systems; where, when and from what device and client software the request comes; and whether the target server has unpatched, high-risk vulnerabilities. Adding these details and the agent’s declared intent to OpenTelemetry traces, the records that follow a request across many systems, speeds up diagnosis and makes it possible to grant short-lived, narrowly scoped access instead of broad, permanent entitlements.

Question Static permissions Runtime authorization
When is access decided? Once, ahead of time At every tool call
What is it based on? Identity and preset scopes Mission, intent and live context
How long does access last? Broad and standing Narrow and short-lived
How are actions traced? Isolated, disconnected decisions Linked by a shared mission ID

Missions give every action a shared purpose

AAuth, an open protocol led by that OAuth co-creator, starts from a simple rule: an agent always acts on behalf of a person, defined as either an individual or a legal organization. Agents cannot be held accountable, so responsibility stays with whoever authorized them.

The protocol’s central idea is the mission, the overall goal that the user and the agent agree on before work begins. A capable agent negotiates it, asking the user to clarify scope and parameters. Every later authorization decision is checked against the mission, and a persistent mission ID travels with every transaction and tool call, so security teams can later see exactly which decisions were made under which mission. Context also catches mistakes that look valid in isolation, such as the same payment going out twice five seconds apart.

Intent comes in layers. A company may buy Claude Code to raise developer productivity; that is business intent. An engineer asking it to fix one bug in staging expresses transactional intent. The safe operating space is where the two overlap. An agent session that suggests shopping items and one that triages a production bug need different permissions and different thresholds for calling a human back in.

Unlike classic identity and access management (IAM), which attaches fixed access to individual resources, an intent-based model evaluates each department’s intent separately at runtime. Missions can last for weeks, so authorization state has to persist that long. JPMorgan Chase’s security architect cautions that such mission tracking is still in its infancy at most companies.

Separate the worker from the supervisor

Suppose an employee tells an incident-response agent to read the CEO’s inbox. The OAuth co-creator argues that a well-built system rejects the request, and that the agent doing the work must never be the one enforcing its own limits. An independent supervising agent should decide what the worker may do. Deterministic rules can block clear-cut violations such as opening an executive’s mailbox, while gray-area requests, like forwarding internal executive messages to an outside domain, need the supervisor’s judgment. He also warns against letting the vendors who supply worker agents provide the guardrails too, since that creates a conflict of interest.

Asking humans to approve everything fails too: endless prompts cause consent fatigue, and tired people start rubber-stamping. A better design sets broad baseline rules for actions that must never happen and reserves human-in-the-loop review, where a person checks a step before it runs, for genuinely risky decisions. As agents take on more work, case-by-case human review seems unlikely to keep up.

Budgets work better than rate limits

One AI agent trying to book a restaurant table made 200 API calls in an hour, and the user’s Resy account was banned as a result. In ordinary software, 200 rapid-fire requests would be an obvious bug that a developer fixes in code. An agent pursues its goal and, unless something constrains it, keeps retrying until it succeeds; from its point of view, that persistence is not abuse but the best path to success.

AAuth’s answer is a budget. The agent receives access tokens, the credentials it presents to a service, which expire after a set time or once a set quota is used up. When the budget runs out, control returns to a supervisor, which decides whether to grant more. A standard HTTP rate limit simply cuts the agent off without saying why or how to adjust. Feeding the remaining budget back into the model’s context teaches the agent that resources are scarce, so it can pace its calls the way a person would.

A small robot sends envelopes through a tube one at a time beside a large hourglass that is running down

▲ Pacing agent calls to a remaining budget

Keep the brain away from the hands

A related pattern splits an agent into a brain and hands. The brain is the LLM and its reasoning. The hands are tools confined to a sandbox with no direct internet access and no standing API credentials. Every outbound request passes through an egress proxy, a gateway outside the sandbox where protocols such as AAuth apply fine-grained policy. In one known incident, an agent found raw keys stored on disk and tried to use them for unapproved actions. Major labs, including Anthropic and OpenAI, are converging on this two-tier approach, which pairs deterministic outside guardrails with the model’s probabilistic reasoning.

The split also eases context bloat, a common MCP problem in which descriptions of too many tools crowd the context window. Showing the model only the tools it needs for the current subtask saves tokens, the units models use to process text, and reduces hallucinations. It also defuses toxic combinations, where two harmless tools become dangerous together. While an agent drafts an email, for example, web search and outbound channels stay off, and the send tool returns only after the draft is reviewed.

Fewer privileges also mean a smaller attack surface, fewer errors and faster work, according to JPMorgan Chase’s security architect.

A glowing brain and robotic arms sit in a sealed glass box whose cables leave through one guarded gate

▲ An agent sandbox with a single guarded exit

Keep the audit trail out of the agent’s reach

Audit logs and enforcement points must sit outside the agent’s runtime, where it cannot evade or tamper with them. At one AI platform, a flawed internal proxy setup and gaps in monitoring left outbound connections open and unwatched. Centralized logs should record which person or organization authorized each agent action, and for what purpose.

The CEO of a company working on authorization for AI agents argues that running agents is ultimately a question of legal liability, not prompt engineering. In his view, existing tort and commercial law already decides who is responsible when a deployed agent causes damage, so sweeping new agent rules are unnecessary. That makes tamper-proof logs the evidence of who authorized, delegated or carried out an action. An IBM manual from 1979 made the underlying point: computers cannot be held accountable, so they must never make management decisions. When intent travels unchanged through the system, investigators can quickly tell whether a failure came from human error, the agent or a software defect, and contain the blast radius. Payment networks already have rules for fixing a transfer of the wrong amount; AI agents have no comparable standard yet.

The web cannot tell a helpful agent from a bot

The web was built for people. When a logged-out visitor bids $50 on a pair of socks on eBay, the merchant cannot easily tell a shopper’s personal agent from a malicious bot without forcing a login. CAPTCHAs, the puzzles meant to separate humans from machines, no longer stop modern LLM agents, and blocking by IP address causes collateral damage. Two to three years ago, Spain blocked Vercel nationwide because an illegal soccer streaming site shared cloud IP addresses with legitimate sites. Without a reliable way to recognize trusted agents, benign agent traffic risks the same fate.

For agent-driven commerce, JPMorgan Chase’s security architect proposes extending Know Your Customer (KYC) rules to Know Your Agent (KYA). Merchants and banks would verify the user, the agent, the company operating it and the party processing the transaction, linking them into one verifiable chain. Shoppers would know their agent buys only within the limits they set, and merchants would learn the purpose behind each order.

The OAuth co-creator calls for vendor-neutral open standards that let companies mix components from different providers. Just as OpenID Connect and Transport Layer Security (TLS) once opened up web commerce, the agent web now faces a choice between federated protocols and walled gardens run by a few large companies.

What to do before you hand an agent the keys

The gap between capable models and trusted agents is an authorization problem, and design choices available today can narrow it. If your team is preparing to deploy agents, start here:

  1. Grant access gradually, as you would for a new hire, and widen it as the agent proves reliable.
  2. Define a mission for each task and attach its ID to every tool call and log entry.
  3. Block forbidden actions with deterministic rules, and save human approval for high-risk steps.
  4. Keep supervising agents separate from worker agents and independent of the worker’s vendor.
  5. Replace blunt rate limits with expiring budgets, and tell the agent how much remains.
  6. Run tools in a sandbox without standing credentials, and route outbound traffic through an egress proxy.
  7. Expose only the tools the current step needs, and switch off risky combinations.
  8. Keep audit logs and enforcement points outside anything the agent can touch.