How Should Agent Authorization Reflect the User’s Intent?

Allie Howe of Keycard moderates a discussion with Keycard CEO Ian Livingstone, JPMorgan Chase security architect Michael Davis and AAuth creator Dick Hardt about intent-based authorization for agents.

Howe describes runtime authorization as checking an agent's actions as it calls tools instead of relying solely on broad standing access. Coarse APIs, incomplete policies and changing environments make the decision difficult.

Livingstone says regulated organizations prioritize security and continuity. Their systems contain many identities and legacy permissions, so an agent needs a way to request access without gaining unintended capabilities.

He points to broad OAuth scopes as a problem: an API-wide permission may convey much more access than a particular agent task needs. Existing systems were often designed around human decisions and more deterministic software.

Hardt argues that OAuth originated in a different application environment and that common scopes can be too coarse for changing agent tasks. OAuth has evolved, but existing integrations still determine the actual granularity available.

Davis compares granting agents autonomy to onboarding developers: start with limited access and expand capability as evidence and conditions justify it. The environment, including whether work is sandboxed, matters alongside the agent's own claims.

Davis says financial systems already reason about individual transactions at runtime. A payment's amount, recipient and timing constrain the action, while a memo provides context about its purpose.

Hardt adds that a single transaction may look acceptable in isolation but conflict with the broader task—for example, a duplicate payment made seconds after the first. The decision needs both transaction details and mission context.

Livingstone contrasts a shopping session with a production-debugging session: the two need different permissions and different points at which to involve a person. He argues that knowing the task helps constrain the relevant access.

Hardt describes an AAuth mission as a goal delegated by a person or organization. The agent and user can clarify parameters, and a mission identifier can connect subsequent decisions and actions for audit.

Howe asks what happens if someone requests access to a CEO's email outside their authority. Hardt says established deterministic policy should reject unauthorized access and proposes a separate supervisor for contextual decisions.

Livingstone suggests deterministic rules for actions that must never happen or always require a human, combined with task-specific context. He also notes the usability cost of asking people to approve too many actions.

He distinguishes an organization's reason for adopting a tool from a user's immediate task, such as fixing a staging bug. The permissions for a run should fall within the intersection of relevant constraints.

Davis adds that context can change an access decision: an authorized assistant may have some access to a principal's email or calendar, depending on the assigned role and policy. The decision is not simply a static label.

Davis says enterprise mission tracking and dynamic authorization were still early in practice. A shared vocabulary can help teams discuss decisions across systems and diagnose long-running work.

Howe turns to agentic commerce: a user may want an agent to buy the right item within a budget, while a merchant needs to decide what traffic and actions to trust.

Davis extends “know your customer” to knowing the agent and the intentions of the user, operator and processor. He sees that context as useful for commerce and compliance discussions.

Livingstone says websites have long had to handle unknown clients and prevent abuse. An agent arriving at a site presents a related problem: the site needs a basis for deciding whether and how to interact with it.

Hardt advocates interoperable protocols so people can choose separate components for doing work and supervising it. He argues that a user should not have to depend entirely on the worker agent's vendor to define all guardrails.

Livingstone likewise favors federated standards and asks whether the emerging ecosystem will allow different providers and resource owners to interoperate. This is a design preference, not an established outcome.

Davis says connecting an action to a person's intent can support accountability and investigation. What the user wanted, what the agent attempted and what actually happened are separate facts to preserve.

He says propagating relevant context through events can help investigators distinguish human error, agent error and other causes. Financial systems already have procedures for some incorrect transactions; agent workflows need comparable clarity.

Howe describes a reported incident in which a restaurant-booking agent made roughly 200 calls and its user's Resy account was banned. The discussion uses it to illustrate that pursuing a legitimate goal can still cause unwanted effects.

Hardt says AAuth experiments led to resource budgets as well as time limits. When a budget is exhausted, a supervising component can decide whether more access is appropriate; the agent can receive feedback on consumption.

He contrasts this with a simple rate limit that cuts requests off without necessarily explaining the remaining allowance. A budget can expose scarcity, although an agent still needs enforcement outside its own promises.

Livingstone describes separating the agent's reasoning from tools and credentials, using a sandbox and an external egress proxy as an authorization boundary. The boundary must be designed and maintained; it is not automatically secure.

Davis agrees that separation is valuable but warns that context and memory can bias future decisions. He discusses toxic combinations of capabilities and dynamically removing tools during sensitive work.

As an example, he suggests restricting external egress while an agent handles sensitive email, then restoring capabilities when appropriate. Actual permissions must fit the organization's threat model and workflow.

Livingstone argues that presenting only relevant capabilities may also reduce distraction and wasted work. He offers this as a hypothesis about agent efficiency, not a measured result from the panel.

Davis says production engineering is shifting from simply obtaining access to discussing dynamic authorization, validation and when to involve a human. Security and application teams need a shared language.

Livingstone describes a secure software-factory reference architecture in which runtime authorization is one component among orchestration, deployment and oversight. He frames safe production iteration as a broader challenge than generating code.

Howe asks what cybersecurity can learn from robotics, where a robot must consider both its intended movement and the changing environment before acting.

Davis suggests including environmental signals such as location, time, device condition and system vulnerabilities in short-lived authorization decisions. Observability can preserve the relevant context for later diagnosis.

Livingstone argues that enforcement and audit records should sit outside the agent's control. A trustworthy record should show who delegated what, for what purpose, and which actions were allowed or denied.

The panel closes with differing views on severe AI risk. Hardt worries about malicious actors and misuse; Davis expresses confidence in engineers' ability to improve controls; Livingstone is more optimistic about catastrophic risk.

These are forecasts and opinions, not probabilities established by the discussion. The common operational theme is that organizations still need to constrain, observe and investigate agent actions.

Hardt distinguishes accidental failures from deliberate misuse and says the latter worries him most. Davis emphasizes iterative engineering, while Livingstone thinks society can learn from incidents; none offers a demonstrated risk estimate.

Howe thanks the panel and closes the discussion. The participants leave the audience with a practical challenge: connect delegated goals to enforceable limits and independent records.