Skip to content
Home » Intent-Based Auth: Why Agent Permissions Need a Mission

Intent-Based Auth: Why Agent Permissions Need a Mission

The gap that keeps enterprises stuck

An agent can hold a valid API token and still do the wrong thing. That is the whole problem.

At AI Engineer NYC 2026, Allie Howe of Keycard opened a panel by naming the gap precisely: standing access tells you what a system can call, not whether it should call it right now. Authorising a tool call at runtime — in context, against a live mission — is a different decision entirely. Most enterprise auth infrastructure was never designed to make it.

Ian Livingstone, Keycard’s CEO, put it plainly: existing permissions were built for a world where humans made all the decisions and software was deterministic. An agent explores, retries, and finds new routes toward a goal. Dick Hardt, founder of AAuth and co-creator of OAuth, traced the mismatch to OAuth’s origin — a protocol designed to let one website talk to another, assuming registered clients and browser redirects. Copying those coarse scopes into an agentic setting preserves their coarseness. Livingstone noted that Salesforce’s OAuth for a long time offered a single scope: api. In an agent context, that is nearly useless. Watch the opening discussion at 2:17:04.

Michael Davis, Global Chief Security Architect at JPMC, added a practical frame: successful enterprises onboard agents the way they onboard developers. Day-one access is limited; autonomy expands as trust is earned. The agent’s own claim about what it intends is only one input. The environment it runs in, whether it is sandboxed, and what surrounds it all shape the access it should receive.

Why a mission changes the decision

The payment example from the panel makes the stakes concrete. A check carries a payee, an amount, a date, and a memo. Those fields convey both constraints and a reason for acting. Financial systems already authorise transactions, not just identities. But even a valid payment can be wrong: if the agent made the identical payment five seconds earlier, a second one is a duplicate. The decision needs the broader history.

Hardt calls that context a mission in AAuth. A person — a human or an organisation — gives the agent a goal. The agent negotiates the parameters. A mission identifier then follows every subsequent decision, so the organisation can reconstruct what happened and why. The mission must still obey organisational policy: asking an agent to read the CEO’s email cannot grant access the requester never had. Hardt separates the worker from the component supervising its permissions so the agent cannot approve its own access.

Livingstone draws a line between two distinct layers of intent. Business intent is why a company adopted an agent — say, to make developers more productive. Immediate task intent is what a specific session is trying to accomplish — fixing a bug in staging. Permissions should reflect the intersection of those two purposes. Davis cautions that the intersection is not static: reading an executive’s email means something different when the requester is that executive’s administrative assistant. Mission tracking across weeks-long workflows is, as Davis noted, early work rather than a capability already deployed everywhere.

Commerce, supervision, and who controls the guardrails

Agentic commerce exposes the problem from both sides. A buyer wants an agent to choose the right item within a budget. A merchant wants to know who sent the agent, whether to trust it, and what it is trying to do. Livingstone compares this to the longstanding problem of an unfamiliar client arriving at a website: anti-abuse systems must distinguish useful activity from spam, while agents need a way to interact without every site treating them as unwanted automation. Identity and agreed protocols give a resource owner more information for that decision.

Hardt’s deeper concern is who controls supervision. If the vendor supplying the worker also decides every permission, the user cannot easily substitute a supervisor implementing their own policy. Interoperable protocols would let those components come from different providers. Livingstone argues for a federated web where resource owners decide what they allow using shared standards, rather than a system that gives a few large providers privileged entry. Davis adds the accountability layer: connecting intent to outcome makes it easier to assign responsibility when real money moves.

Mission context also clarifies failure modes after the fact. The same audit record can help an investigator distinguish three distinct problems:

  • A harmful request: the agent carried out a goal the user should never have pursued.
  • A misunderstanding: the agent acted on the wrong interpretation of the goal.
  • An execution error: the software performed the wrong operation.

Without mission context, investigators have only the agent’s post-hoc explanation.

Budgets, sandboxes, and toxic combinations

Good intent does not guarantee proportionate behaviour. Howe described a restaurant-reservation incident in which an agent’s repeated requests reportedly caused an account to be banned. The agent was trying to complete a legitimate task; persistence became abuse. Watch the budget discussion at 2:41:10.

Hardt’s response in AAuth is resource budgets. A token can expire after a period of time or after its budget is exhausted. Once the budget is gone, supervision decides whether to grant more. The difference from traditional rate limiting: the agent receives continuous feedback on how much budget remains and can adjust its behaviour before hitting a hard cutoff. It knows the constraint is real.

Livingstone describes the architectural pattern: a sandbox contains tools, while an egress proxy outside it enforces authorisation. Keeping powerful credentials out of the sandbox reduces the chance the agent discovers and reuses them through an unintended path. Davis warns that separation alone is incomplete. Stored memory can bias later decisions, and combinations of otherwise reasonable tools can create dangerous capabilities — what Davis calls toxic combinations. One practical response is to remove tools dynamically during a task: disable external egress while an email operation is underway, then restore it when the mission changes. Constraining available tools also reduces irrelevant exploration and, in practice, can improve agent performance.

The audit log must live outside the agent

Davis imagines intent context appearing alongside a trace span, so an engineer can inspect both the user’s intention and the environmental conditions at the time of any action. Authorisation decisions become shorter-lived and better-informed as those conditions change.

Livingstone is direct about one requirement: the audit log must remain outside the worker’s control. An agent that can tamper with the only record of its own behaviour undermines every investigation that follows. The record — who requested an action, for what purpose, which operations followed — is also a prerequisite for holding responsible parties accountable. Livingstone frames this as a liability question rather than a regulation question. Pre-existing liability law asks who employed the agent and who is responsible for the damage. The tamper-resistant log is how you answer it.

The panel closed on honest disagreement. The proposed authorisation systems can constrain a worker serving an approved mission inside a responsible organisation. Whether those controls can contain people deliberately using agents to cause harm is a separate, unresolved question — and the one the panel’s most cautious voice considers the real risk. Watch the closing exchange at 2:55:15.

Where to start

Enterprise mission tracking is early. Most organisations do not yet have it. But the architectural decisions made today — sandbox boundaries, egress proxy placement, credential separation, log ownership — determine how quickly intent-based controls can be added as the tooling matures.

Pick one production agent workflow and map every standing permission it holds. Identify the coarsest scope. Then ask a specific question: would a mission identifier have distinguished the last unexpected action it took from a legitimate one? That exercise surfaces the gap between what the agent is allowed to do and what it should have done, and gives security and application teams a shared vocabulary to close it.


Eagentix helps growth-focused enterprises redesign and automate manual business processes. We combine executive strategy, implementation support, and managed services to build dependable operations across Southeast Asia.

Sources

Leave a Reply

Your email address will not be published. Required fields are marked *