Why Today's Agent Infrastructure Isn't Enough For The Agentic Enterprise

This article is for technical leaders deploying agents. It shows where today's infrastructure gaps show up.

The plumbing for agent access has come together remarkably fast. OAuth 2.1 handles delegated access: a user grants an application permission to act on their behalf without sharing a password. OpenID Connect handles who the user is. The Model Context Protocol gives agents a standard way to discover and call tools, and it builds its authorization on OAuth. Every major SaaS platform now ships an agent connector on this stack.

This is real progress, and none of it should be replaced. These standards were designed carefully by people who understood the failure modes of the systems that came before them, and they work.

But do they give an enterprise the fine grain control it needs? They ask, "Does this agent have access to this system and which tools?" The enterprise wants "is this specific action, at this moment, in the current context within this agent's authority?"

That last question is the one Stage 3 enterprises need answered. This article is about that gap: where it shows up in products shipping today, why the existing stack doesn't close it, and what has to sit on top of that stack for agents to operate with real autonomy and real accountability.

Context: What is Stage 3?

In our previous article, we described three stages of agentic maturity. Stage 1 is about getting agents into production. Stage 2 is about scaling them safely with basic access controls: OAuth, API tokens, connector-level scopes, and role-based frameworks.

Stage 3 isn't just about controlling which systems agents can access. It's about controlling what specific transactions agents are authorized to perform, under what conditions, with what approval chains, and what happens when an agent acts outside its authority.

An agent in Stage 3 might be authorized to approve purchase orders under $10,000 but require human sign-off above that threshold. It might be allowed to query customer data but not modify it. It might execute a workflow, but given changing parameters in real time, it may require escalation to a human.

This is where existing access-control tools reach their architectural limits. For many enterprises, Stage 3 is becoming the next step in agent deployment. It's not a niche problem. The companies we're working with are already grappling with these exact requirements. This isn't aspirational. It's their present operational reality.

The Core Problem: Transaction-Level and Context-Aware Authorization

Three control points, and the one that's missing

Today, an enterprise deploying an agent against a SaaS system gets three control points.

The platform decides what scopes exist. Google decides whether "read mail" can be narrower than the whole inbox. Intuit decides whether "manage sales" can be narrower than every invoice.

The connector decides which tools are exposed. The vendor decides that delete_invoice ships in the same bundle as get_invoices, and the enterprise takes the bundle or leaves it.

The agent host decides when to pause and ask. The chat product or orchestration framework chooses which actions get a confirmation prompt, based on a list the vendor wrote.

What no layer offers is a policy the enterprise writes, evaluated at the moment the action executes, expressed in the vocabulary of the business: amounts, counterparties, velocity, segregation of duties, time of day, cumulative exposure. That is transaction-level authorization, and it is the thing Stage 3 requires.

Two examples from shipping products

Google's Gmail MCP server lets an agent read, search, and act on mail. But the grant is Gmail's mailbox-wide OAuth scope: there is no way to authorize "order confirmations only," "messages from amazon.com," or "everything except emails from my family." A shopping agent that needs receipts gets the whole inbox. The user's intent is narrow; the grant is total. That's the platform-scope layer.

Intuit's QuickBooks connector for Claude exposes create, update, send, and delete for invoices and estimates in a single all-or-nothing authorization, alongside payment links, transaction import, and company-profile changes. Intuit sensibly requires the user to confirm destructive actions before QuickBooks makes a change. But that confirmation lives inside the agent, not in front of QuickBooks. The token that deletes an invoice is the same token that lists one, and the ledger cannot tell a confirmed delete from an unconfirmed one. If the agent is misled by a prompt injection in a document it just read, or a sub-agent is handed the same session, the control isn't there. That's the agent-host layer.

Neither platform is doing anything wrong. They're doing what today's stack allows. The layer that's missing isn't theirs to build.

What the business actually asks

Consider a procurement agent with legitimate access to create vendor entries and make payments. Scopes can express "read-only," "write to this resource," or "call this API." What the procurement team wants to know is different:

• Can it approve a purchase order for $500? Yes.
• Can it approve a purchase order for $50,000? Maybe, but only with human review.
• Can it approve purchase orders on behalf of Vendor A? Yes, but with constraints.
• Can it create a new vendor and then make payments to that new vendor? No. That's a fraud vector.
• Can it approve 100 different purchase orders to Vendor A in a single day? No. That looks like abuse.

None of the three control points above answers these. Scopes are too coarse. Tool lists are chosen by the vendor. Confirmation prompts are keyed to tool names, not to business rules. Once access is granted, nothing in the stack provides the transaction-level policy and decisioning needed to enforce Stage 3 rules, route exceptions to people, or prove afterward that a transaction fell within an agent's authority.

The Missing Decision Model

Today's stack makes a binary decision: "Does this agent have access? Yes or no."

Stage 3 requires a ternary decision model: "Should this transaction go through autonomously, be flagged for review, or be escalated for approval?"

That difference seems small. It's actually architectural.

The Approval Fatigue vs. Risk Balance

Here's the dilemma Stage 3 enterprises face: if every transaction requires human approval, you've eliminated the benefit of automation. Agents would be no faster than humans.

But if you give agents too much autonomy, you create risk, especially with probabilistic systems that can hallucinate or take shortcuts.

The solution is a three-lane transaction model:

Green Lane: Agent handles autonomously (routine transaction, within all limits, low risk). Transaction is logged for audit.

Yellow Lane: Agent handles but flags for human review (unusual pattern, approaching limits, or confidence below threshold). Transaction is logged and highlighted for audit review. Humans monitor but don't block.

Red Lane: Escalated to a human BEFORE execution (outside agent authority, high-value transaction, exception detected, or throttle limit reached). Human reviews, makes a decision, digitally signs off. Only then does the transaction execute.

The key is that these lanes are not fixed. Humans design the policies that determine which transactions go where. An experienced procurement manager might set up rules like:

• Agent can approve up to $10,000 to approved vendors: Green Lane
• Transactions $10,000 to $50,000 to approved vendors: Yellow Lane
• Transactions over $50,000, or to new vendors: Red Lane
• And also: no more than 3 payments under $10,000 to any single vendor per day, and no more than $400,000 total in approvals per day across all vendors. Exceed that, and it's Red Lane, needing human sign-off.

This dynamic routing lets agents operate at scale while keeping humans in control of what "safe" actually means for your business. The goal is intelligent escalation, not blanket approval fatigue.

Notice where today's confirmation prompts sit in this model: they are a Red Lane for a fixed list of tool names, chosen by the vendor, enforced inside the agent. The enterprise doesn't write the rule and can't move a transaction between lanes based on context.

Credentials Don't Carry Authority

OAuth commonly uses bearer tokens: credentials that convey authorization to access protected resources. Whoever possesses a bearer token can present it as proof of authorization. For agents operating autonomously with broad grants, this creates two specific problems.

As of September 2026, Claude and OpenAI do not support sender-constrained tokens like DPoP. All agents using these platforms currently operate with bearer tokens. This means the vulnerabilities described below are the current state of the art for agentic AI.

1. Token theft, and the Salesloft example

If an agent's token is compromised, anyone or anything that obtains it can act on the agent's behalf. This is more than identity theft - it's authority theft. The attacker inherits not just access, but every permission and capability the agent was granted.

In August 2025, attackers stole a cache of OAuth tokens from the Salesloft Drift AI chatbot integration. Those tokens gave them direct access to over 700 Salesforce customer environments, where they exfiltrated AWS keys, Snowflake tokens, and other sensitive credentials. Long-lived, broadly scoped tokens for a single integration became a supply-chain attack across hundreds of enterprises.

Modern OAuth has an answer for the theft itself: sender-constrained tokens such as Demonstration of Proof-of-Possession (DPoP) bind a token to the client's private key, so a stolen token cannot be used without the key. This is a significant improvement, and it is rarely deployed by SaaS connectors today. But even where it is, it doesn't solve the transaction-level problem. A token bound to an agent's key proves "this request comes from the legitimate agent." It does not prove "this specific transaction falls within the agent's authority."

2. Identity obfuscation

Agents often act on behalf of the human who initiated them. A human employee logs into a system, starts an agent workflow, and the agent takes over. Because both may be operating within the same OAuth context, it becomes difficult to distinguish whether the human did the work or the agent did. The OAuth Token Exchange standard defines an actor claim to record exactly this "acting on behalf of" relationship; connectors almost never use it. The result is an accountability gap: who actually made this decision?

The Accountability Chain Gap

None of the connectors above records an auditable chain of authority. The logs show "agent accessed system X." They don't show who authorized the agent to do this, under what conditions, or whether the action was within those conditions. That deeper chain is what enterprises need to establish accountability.

With humans, accountability is clear: a person can be held responsible. With agents, you need to trace back: Who created the agent? Who delegated authority to it? What were the terms of that delegation? Was this action within those terms?

Without this chain, you can't hold anyone accountable. You can only see that something happened.

What Today's Stack Gives You, and What It Doesn't

What the stack provides

• Delegated, scoped access (OAuth): an application or agent acts with permissions the user granted
• User authentication (OpenID Connect): who the user is
• Tool discovery and a standard connection handshake (MCP): how an agent finds and calls a platform's tools, with OAuth-based authorization to the server
• Per-tool confirmation for vendor-chosen actions (the agent host): a pause before certain named operations

The critical gaps

• No grant narrower than the platform's scopes. The user's intent may be "receipts only"; the grant is the mailbox.
• No enterprise-authored policy evaluated at execution. Amount thresholds, speed limits, segregation of duties, and cumulative exposure are not expressible anywhere on the agent path.
• Confirmation lives inside the agent, not in front of the resource. The system of record can't distinguish an approved action from an unapproved one.
• No recorded delegation chain. When one agent hands work to another, nothing records who authorized what, for which resources, within what limits.
• Audit shows the call, not the authority. Logs answer "who did this" but not "were they authorized to do this under these conditions."
• The standards that could help aren't wired in. Sender-constrained tokens, continuous access evaluation, step-up authentication, backchannel human approval, and rich per-transaction authorization all exist as published standards. Almost none of them are deployed on the agent path.

Concrete Examples: Where the Gap Shows Up

These examples are drawn from shipping products as of September 2026. The specific implementations may evolve, but the architectural constraints they illustrate are present across the agent ecosystem today.

Example 1: Purchase order approval with constraints (Finance)

Google's Gmail MCP server illustrates a scope problem common across many SaaS platforms. The agent gets a mailbox-wide OAuth scope: there is no way to authorize "order confirmations only," "messages from amazon.com," or "everything except emails from my family."

An agent has access to your procurement system. The connector says: "Yes, this agent can create POs and payments."

The real questions your procurement team cares about are far more nuanced:

• Can it approve a $500 PO? Yes.
• Can it approve a $50,000 PO? Only with human sign-off.
• Can it approve POs for Vendor A? Yes, but with constraints.
• Can it create a new vendor in the system and then make payments to that new vendor? No, and it may require one or more human approvals before any new vendor can be established and funded.
• How many POs can it approve to Vendor A in a day? No more than 3, and no more than $400,000 total.
• What if it tries to approve a 4th PO to Vendor A in the same day? Route to Red Lane. A human must review and digitally sign off before the transaction executes.
• What if total spend reaches $400,000? All further transactions that day go to Red Lane, stopping the agent from exceeding the daily limit without human intervention.

Policy engines can encode rules like these. But the enterprise still needs an authorization flow that can say "approve this transaction autonomously, flag that one for human review, and escalate this third one for approval before execution," and can prove afterward which lane each transaction went through and why.

This is why Stage 3 enterprises hit a wall.

Example 2: Agent-to-agent delegation (Supply Chain)

Intuit's QuickBooks connector for Claude shows a connector-bundling pattern seen across many platforms. It exposes create, update, send, and delete for invoices and estimates in a single all-or-nothing authorization, alongside payment links, transaction import, and company-profile changes.

Agent A is authorized to place orders with approved suppliers. To get the job done faster, Agent A hands its token to Agent B to handle supplier negotiations and order placement.

Now Agent B has all of Agent A's access and authority. It can do everything Agent A can do. But Agent B may not have been trained on the same rules. It doesn't know which vendors are approved. It doesn't understand the transaction limits. It just has a valid token, which means it has complete access.

This isn't necessarily malicious intent. Agents are designed to pursue a goal, and Agent A may give Agent B its token simply to move the task forward more efficiently. The standard for doing this properly exists: token exchange can issue Agent B a narrower token that records Agent A as the acting party. But this capability has not yet become common in agent frameworks. In practice, a sub-agent often gets either no access or broad inherited access.

Who authorized Agent B? Under what authority? For which suppliers? With what transaction limits? What happens if Agent B acts outside those bounds? Nothing in the deployed stack tracks this chain. If Agent B approves a multi-million-dollar order from an unapproved supplier, you're left scrambling to understand how it happened and who was responsible. Increasingly, enterprises deploying multi-agent workflows encounter this scenario.

These examples aren't permanent limitations. Platform companies are aware of these constraints. But solving them requires coordination across the identity layer (OAuth scopes), the connector layer (tool exposure), and the enterprise layer (policy enforcement) - exactly the kind of work that no single vendor can do alone. That's what the missing layer has to bridge.

The Real Problem: Probabilistic Agents Need Verifiable, Auditable Authority

Every layer of today's stack assumes the client will do what the user meant. OAuth grants an application permission; the application uses it. That assumption held well enough for deterministic software.

Agents are different. Even highly capable agents can produce incorrect outputs, take unintended paths, or act on incomplete or stale information. An agent that reads an email containing an embedded instruction may follow it. They operate at machine speed, making decisions without human oversight, in systems where mistakes compound quickly. This means the authorization decision can't be made once at token-issuance time. It has to be made continuously, at transaction-execution time, based on the current state of the system and the constraints of the delegated authority.

This difference matters profoundly. You can't just issue a token once and trust it. You need to verify at execution time: "Is this agent actually authorized for this action under these current conditions?"

And critically, because humans must remain accountable for what agents do on their behalf, you need to be able to prove that authorization. An audit trail showing "Agent X made this transaction" isn't enough. You need: "Agent X was authorized by Human Y to make this transaction under these conditions, and the transaction fell within those conditions. Here's the cryptographic proof."

That verifiable chain of authority is what enables accountability. It's how you hold humans responsible. It's also what lets you trace back through audit logs and understand exactly what happened, why it happened, and who authorized it to happen.

What's Actually Required

Stage 3 enterprises need a layer that sits on top of OAuth, OpenID Connect, and MCP, not in place of them, and provides:

• Transaction-level policy enforcement, authored by the enterprise, evaluated at execution, enforced in front of the resource rather than inside the agent
• Grants narrower than the platform's scopes, matching what the user or the business actually intended
• Verifiable delegation chains: proof that a specific human authorized a specific agent to take a specific action, including when agents delegate to other agents
• Dynamic, context-aware routing: Green, Yellow, and Red lanes driven by risk, limits, and cumulative exposure
• Proof-bound authorization: verifying not just that a credential is valid, but that this agent is authorized for this action, now
• Continuous verification, not once and forget
• Complete auditability: who authorized this, under what conditions, and can we prove it
• Human control points: humans set policy, humans make exceptions, humans remain in the authority chain
• Interoperability with the identity, access, and agent infrastructure enterprises already run

Pieces of this exist in standards: rich authorization requests, token exchange, sender-constrained tokens, backchannel approval flows, and the IETF's transaction-token work. What doesn't exist is an assembled, interoperable layer that connectors and agent hosts actually use. One way to build that layer is verifiable credentials combined with cryptographic accountability, which Article 3 explores in detail. It isn't the only way. The point is that the gap is real, it's present in the best products shipping today, and it isn't going to be closed by any single connector vendor.

Closing

A mailbox you can only share whole. A ledger where "delete" and "list" ride the same key, and the only brake is a prompt inside the agent. These aren't edge cases. They're the current state of the art from two of the most capable platform companies in the world, and they're exactly what Stage 3 enterprises are trying to build on.

The stack we have establishes delegated access. The agentic enterprise requires something deeper: verifiable, auditable proof that an agent was authorized to perform a specific transaction at a specific moment under specific conditions. That means keeping humans in the authority chain, not approving everything, but controlling the rules agents follow and retaining the ability to intervene when exceptions occur.

What would an architecture built for this actually look like? How do you maintain human accountability while letting agents operate autonomously at scale and speed?

In our next article, we'll explore that architecture: infrastructure built on verifiable credentials and cryptographic accountability. Article 3 will show how enterprises can establish, verify, and prove authorization at the moment an action is taken, while keeping humans accountable for what agents do on their behalf.