We Gave AI Agents the Keys Before Building the Locks

You ask your agent: “Pay the approved Northwind invoice, up to $500, before Friday.”

Illustrative scenario:

Valid credentials can outlive the authority for the task.

Nothing was hacked. IAM recognized the caller, the payment API permitted the write, and the agent acted on an earlier approval. But no system verified that the approval was still valid when the payment committed. That's delegated authority: not who has access, but whether this specific action, right now, still has permission to happen.

This article is about making that authority hold from delegation through commitment, not just at the start.

This is already happening

Recent incidents exposed different parts of this boundary problem:

• September: Amazon blocked Meta's Muse agent from its store.
  Also in September, Muse shoppers failed Walmart's human-verification checks — the agent isn't human.
• October 9: Anthropic disclosed that agents in its evaluations had exploited software flaws and taken unintended actions on real websites.
  It suspended live internet access for internal evaluations pending stronger monitoring and controls.
• September: The Australian government confirmed an OpenAI research agent accessed non-public files on the Medicare Statistics Reporting Service portal and wrote files to an internal server, in June — discovered three months later.

Other reports exposed unintended activity: researchers tracked a fleet of agents on Tencent Cloud making more than 2,600 attempts to pull data from Alibaba's Amap, and the UK AI Security Institute recorded 19 unsanctioned actions against real people and organizations in its own cyber-evaluations. Recognizing an acceptable agent and preventing an unintended action are different failures, and both matter when agents cross systems whose owners never agreed on their authority.

We are handing autonomous software our data, credentials, applications and payment systems faster than we're connecting the controls that govern what it does.

AI runs on GPU time. Security runs on standards time.

AI runs on GPU time: models improve and agents gain tools month after month. Security runs on standards time: protocols require review, coordination and adoption. The gap is delegation debt — authority granted beyond what an organization can discover, constrain, revoke and audit.

Adoption dashboards count users, tasks and automation. They rarely show which agents hold authority, how quickly it can be revoked, or which actions are irreversible. Strong adoption numbers can conceal growing delegation debt.

The AI security perimeter has moved again

In February I wrote Inference Firewall: The New Perimeter for the AI-First Enterprise: network and application security can't see instructions hidden in ordinary language, retrieved content and model context, so enterprises need a boundary around inference itself.

I still believe it. But personal agents expose the assumption underneath it: the inference is yours to control.

A customer's agent arrives at your store after reading their email and weighing offers on someone else's model. An employee's agent reaches into Slack, Gmail, calendars and internal systems on delegated credentials. The reasoning happened elsewhere, the context holds things you can't inspect, and the permissions started in another identity domain.

You receive the action. Rarely the intent.

The perimeter didn't just move from the network to inference. It now runs across organizations, model providers, agent runtimes and transactions — and no single party controls the full execution path.

For Northwind, the employee owns the instruction, procurement owns approval, the runtime plans and the payment system commits. Their views must stay connected as authority changes.

A permission is not a mandate

An agent holding payments.write can initiate payments within the access that permission grants. But the permission alone doesn't say which invoice, recipient, amount or deadline the human actually authorized.

A mandate does: "Pay approved Northwind invoice #4471, once, up to $500, before Friday." Even a signed mandate isn't sufficient — invoice approval must come from a trusted business system, the recipient from verified supplier records, and that authority must still be valid when the payment commits.

A signed mandate proves what was delegated. It does not prove that the conditions required to execute it are still true.

Untrusted documents, retrieved content and agent memory can inform a task. They cannot grant or expand its authority — including by inheritance to a subagent, which must never receive more authority than its parent can delegate.

Agentic commerce makes delegation cross organizational boundaries

Mastercard's agent probability score identifies likely agent transactions but doesn't prove authorization for a specific purchase; AP2 signs payment mandates, while UCP and ACP cover the surrounding commerce workflow. Across buyer agents, merchants and payment providers, each still needs verifiable delegation without seeing another agent's private reasoning.

The AI stack was built to reuse state, not preserve authority

Inference engines optimize throughput. Caches reuse computation. Agent memory preserves context. Routers minimize latency and cost. Every layer is doing its job.

But when an agent acts on someone else's behalf, another dimension matters: under whose authority was this work performed, and is that authority still valid? A tenant ID identifies an organizational boundary. A session ID identifies an interaction. An API key identifies a caller. None, by itself, establishes the human mandate governing a particular action. That is the architectural gap.

The Context and RAG row isn't theoretical: Zenity Labs' SalesBleed research showed instructions planted in a public lead form redirecting Agentforce into reading and leaking account data — the agent already held the required read permissions, and the retrieved content supplied the rest.

Not every layer needs to become an authorization engine

Inference caches need isolation boundaries. Agent memory needs provenance and access rules. Gateways and runtimes need to propagate trusted delegation context. Policy engines need to evaluate authority. Receiving systems need to enforce it before consequential actions commit. The architecture works when these responsibilities stay separate — but the chain of authority stays connected.

That distinction cuts against a tempting shortcut: forcing a mandate ID into every cache key. vLLM already supports cache salting for cross-tenant prefix-cache side channels, which shows the isolation problem is real and already being worked on at the serving layer. But cache isolation and authorization solve different problems — one governs who may reuse state, the other governs what an agent may do with it. A model's cache can often outlive a mandate without creating a security risk. What can't survive is the assumption that yesterday's authorization still permits today's action.

Authorization at login is not authorization at commit

Database systems group related reads and writes into transactions, with isolation semantics defining whether operations see newly committed changes or a stable snapshot. Agent execution needs equally explicit rules: planning against a snapshot cannot establish that authority remains valid at commit.

The Northwind failure is a time-of-check to time-of-use (TOCTOU) race: approval changes between the agent's check and the payment's commitment.

A Delegated Authority Layer connects these responsibilities across the systems already involved: a signed mandate issued at delegation, invoice and approval versions recorded at planning, no authority expansion to subagents, an independent check at the boundary that controls the write, and reconciliation before any retry — spanning identity systems, policy engines, runtimes and receiving applications, with enforcement at the resources that matter.

Revocation creates a race between the authority check and the action. A gateway may approve a request milliseconds before its mandate is revoked. The receiving system must validate current authority and commit the action atomically, or use equivalent coordination guarantees. Once committed, the runtime must know whether the action can be canceled, compensated or only reconciled.

A safe stop depends on both current authority and knowledge of what already committed. This is where authorization meets the transaction manager and consistency model from the Database Kernels for AI series.

EXPLAIN AUTHORITY: make the chain inspectable

The Database Kernels for AI series now reaches the security question: was this execution authorized against the state that actually mattered?

Picture EXPLAIN AUTHORITY beside EXPLAIN INFERENCE and EXPLAIN AGENT TASK. Before execution, it would expose the mandate, relevant state and policy decision. After execution, it would connect those decisions to independently captured outcomes.

The commit gate enforces; the record makes that enforcement inspectable. A record alone cannot authorize or prevent an action.

Enforcement belongs at the resource that commits the action, not inside the model or the gateway alone:

# Conceptual operation; the agent cannot approve itself.

payment_service.commit_if_authorized(
    mandate=verified_mandate,
    action=proposed_payment,
    expected_approval_version=observed_version,
    idempotency_key=stable_action_id,
)

# Payment service / coordinated authority:
# - Read authoritative current approval
# - Verify mandate and policy constraints
# - Reject stale or revoked authorization
# - Consume single-use authority with the commit
# - Persist decision and execution evidence

This is conceptual, not a universal API — where authorization and the consequential write span different systems, the implementation needs a coordinated protocol with explicit atomicity and revocation guarantees.

Same agent. Same credentials. Different authority.

The records below show what that enforcement looks like from the outside, for the same agent and mandate, under two different approval states.

Case A — approval valid · ALLOW

EXPLAIN AUTHORITY  action=act_19e  task=tsk_4b2  delegation=dlg_7f3a
  principal   user:priya@acme (verified)
  agent       procurement-agent v2.3 · operator=acme
  mandate     invoice=4471 · recipient=Northwind:verified-17
              max=$500 total · once · expires=Fri · signed
  context     invoice v12 · approval v6 · policy ap-payments v8
  inference   inf_a81 (plan) · inf_a84 (invoice extraction)
  decision    pd_311 ALLOW at plan by ap-policy
  decision    pd_318 ALLOW at commit by payment-service
              approval v6 current · $420 · mandate active and unused
  execution   committed · txn=pay_91c2 · single-use authority consumed
              idempotency-key=pay:acme:dlg_7f3a:act_19e

Retries of this authorized payment reuse the same operation ID and idempotency key; a new attempt must not create fresh spending authority. Deduplication still depends on the receiving system enforcing that key.

Case B — approval withdrawn · DENY

Replay the opening scenario: procurement withdraws approval after a duplicate-invoice flag, before the commit gate runs.

EXPLAIN AUTHORITY  action=act_19e  task=tsk_4b2  delegation=dlg_7f3a
  decision    pd_311 ALLOW at plan by ap-policy
              approval v6 active
  state       approval v7 withdrawn by procurement · duplicate-invoice flag
  decision    pd_318 DENY at commit by payment-service
              expected approval v6 · current v7 withdrawn
  execution   rejected before payment · no transaction created

The agent's credentials remain valid in both cases. What changes is whether this action still has authority. The rejection is the architecture doing its job.

A trace is not a chain of authority

The AI gateway, IAM system, runtime and payment service each hold evidence. Joining their logs by timestamp after an incident is a weak substitute for carrying the relationships through execution.

A chain of authority connects the signed mandate, current business state, policy decisions and committed actions. Enforcement points use that information before an action commits; observability and audit systems preserve the evidence afterward.

One action can depend on several inference calls and policy decisions. Its evidence forms a graph, attested by enforcement points and receiving systems, and correlated across durable, tamper-evident records. Private context need not be centralized.

OpenTelemetry, OCSF, AuthZEN and AP2 provide pieces of the plumbing. Connecting them requires agreement on what each authority field and attestation proves.

Portable evidence lets observability follow the task, security inspect enforcement and auditors trace a payment back to its authority.

Key takeaways: three decisions

1. Architects and Security Engineers — Enforce authority at commit
   • Start with one consequential workflow. Trace the mandate, delegated agents, policy decisions and final action.
   • Make authority part of execution. Identify the state each action depends on and independently verify authorization before commitment.
   • Design for failure. Handle revocation, retries, uncertain outcomes and recovery explicitly.
2. Founders and Investors — Build the missing infrastructure
   • Start with an enforceable wedge. Payments, procurement, access grants or production changes — not another generic agent dashboard.
   • Integrate with the existing stack. Connect identity, policy, agent runtime, business state and resource-side enforcement.
   • Prove the difficult part. Demonstrate revocation, commit-time authorization, recovery and portable execution evidence across multiple systems.
3. CIOs, CISOs and Enterprise Leaders — Measure delegation debt
   • Discover the authority already granted. Inventory sanctioned and shadow agents connected to enterprise systems.
   • Classify consequential actions. Start with spending money, changing sensitive data and modifying production infrastructure.
   • Measure control coverage. Track Delegated Authority Coverage (DAC) and Authority Enforcement Coverage (AEC) alongside adoption and ROI.

Autonomous AI needs an executive mandate

If you can't observe consequential agent actions in real time, verify their authority at each execution boundary, and intervene before commit, you're accumulating delegation debt faster than you can govern it. No security dashboard, AI gateway or agent runtime compensates for the absence of enterprise-wide authority policy.

Executives must mandate that every consequential agent action carries a verifiable chain of delegated authority, an enforceable execution boundary and an accountable owner. Real-time visibility and risk scoring can identify exposure, but they cannot substitute for authorization — payments, data disclosures and production changes may be irreversible, or recoverable only after the damage is done.

Build the locks around the action

The Northwind payment is only $420. The same question applies to changing a supplier's bank details, granting access, sending confidential data or committing production infrastructure changes.

A Delegated Authority Layer has to connect the original mandate to the commit gate at every consequential step, without taking away the autonomy that made agents worth having.