An AI Agent Got Its User Banned From Resy — Keycard, JPMorgan Chase & AAuth

A coding agent may need to investigate a staging bug without gaining the power to change production. Yet the API permission available to it may cover much more than that task. At AI Engineer New York, Keycard’s Allie Howe and Ian Livingstone, JPMorgan Chase’s Michael Davis, and AAuth founder Dick Hardt discuss how to authorize agents as they work.

Runtime authorization makes a decision when an agent requests a tool call. That decision is difficult because tools and APIs often expose coarse permissions, a policy cannot anticipate every situation, and the environment may change during the task. Livingstone recalls Salesforce historically offering a single OAuth API scope: access to the API alone says little about which action a particular agent should take.

Hardt describes OAuth as a tool originally designed around access between websites, with assumptions such as client registration and browser redirects. Scopes added useful restrictions, but different instances of an agent may discover different needs while working. Davis suggests onboarding agents as organizations onboard developers: start without full commit access and add capabilities as confidence grows. Whether an agent is operating in a sandbox, for example, can change the autonomy an organization permits.

Howe’s Notion example makes the granularity problem concrete: a tool can fetch a page, while the desired permission may be to get only one database on that page. An authorization layer can decide whether to permit the exposed call; intent alone does not make the underlying tool more granular.

Davis draws on banking’s distinction between authenticating a person and authorizing a transaction. A paper check carries a payee, amount and date as limits, plus a memo explaining purpose. An agent’s payment request similarly needs details about this transaction and why it belongs in the work underway.

A scope that permits payments cannot answer whether the agent should make this payment again. Hardt’s example is a payment repeated five seconds after the first: the individual call may look permissible, while its history makes it suspect. AAuth’s proposed mission supplies the larger assignment against which individual decisions can be considered.

A mission begins with a person or organization delegating work. The agent may clarify the parameters with that principal, and a mission identifier can follow subsequent decisions so an investigator can reconstruct what happened in that assignment. Livingstone contrasts a shopping session with a production-debugging session: even if both use the same agent, they call for different access and different moments to involve a human.

A user’s request does not automatically make an action permissible. Hardt proposes separating the worker from a supervisor that decides what the worker may do. A deterministic rule might reject unauthorized access to the CEO’s email; a more contextual decision might examine whether forwarding a message outside the organization fits the mission. This arrangement is a proposal, not a guarantee that a supervising agent will always judge correctly.

Livingstone’s policy model starts with deterministic rules for actions that must never happen or always require a human. Those rules leave a gap: an organization cannot write every task-specific decision in advance. His proposed answer is to combine the organization’s purpose for adopting an agent with the user’s immediate purpose.

For example, an organization may adopt a coding agent to make developers more effective, while the present session is meant to fix a bug in staging. The permitted actions should fit both contexts. Human approval remains available for consequential cases, but asking for it on every action risks consent fatigue.

Context can change the answer. Davis notes that an administrative assistant might legitimately read the CEO’s email, or might need only the calendar. Information from different parts of an organization can contribute to the decision, and a mission can remain relevant across many events or even weeks. He describes mission and policy tracking as early work for most enterprises; a system also has to contend with older permissions that do not always behave as their labels suggest.

Commerce adds another party to the authorization problem. A shopper wants an agent to buy the right item within a personal budget; a merchant needs to decide whether an unfamiliar agent should be allowed to interact with its site. Davis extends the banking idea of knowing the customer to knowing the agent, alongside the intentions of the user, operator and processor.

Livingstone compares the problem to an unregistered visitor arriving at a website. The resource has to decide whom to trust and how to communicate with a client it has not met before. CAPTCHAs were intended to distinguish human visitors from abusive automated traffic; he observes that capable agents complicate that distinction.

Hardt favors interoperable protocols so a person can choose a supervising component independently of the agent doing the work. Otherwise, the worker’s vendor may also control its guardrails. Livingstone likewise makes the case for federated standards under which individual resources can make their own access decisions. These are design goals for an emerging ecosystem.

The record of intent also helps after something goes wrong. Davis describes using it to distinguish what the user wanted from what the agent attempted, narrowing an investigation into human error, software error or another cause. He expects more interoperable records to help organizations define responses to agent incidents, much as financial systems have procedures for an incorrect payment.

Howe describes an agent trying to book a restaurant on Resy that repeatedly called the service and got its user’s account banned. The recording describes 200 API calls in an hour; the video description says 200 calls in 90 minutes, so the precise rate is uncertain. The failure illustrates a valid goal pursued with excessive use of a downstream service.

Hardt says AAuth added budgets after observing agents repeatedly use resources without a signal that those resources were scarce. A grant can be limited both by time and by an amount of resource use. Access ends when either limit is reached; a supervisor can then decide whether to provide more.

The distinction from the rate-limit behavior Hardt describes is feedback. Instead of encountering an unexplained cutoff, the agent can receive information about its remaining and consumed budget and adjust its behavior. A budget supplies a limit; the panel does not demonstrate that it would have prevented this particular ban.

What keeps a determined agent from finding another credential after a refusal? Livingstone describes a sandbox containing the agent’s tools, with an egress proxy outside it. Outbound access passes through a point where authorization can be applied, while credentials and broader access are kept away from the agent.

The diagram traces the proposed outbound path. The sandbox lets the model experiment with its available tools; the external proxy is where a separate layer can enforce access decisions before traffic reaches a resource.

Davis adds that separation must account for combinations of capabilities. Memory or context can bias an agent toward a bad action, even when its tools are individually useful. His example dynamically disables web search or other external-egress tools during an email task, then restores them when that work is complete. The changing tool set constrains what can be combined at that moment.

Livingstone also expects selective tools to reduce context bloat and wasted exploration: an agent sees capabilities suited to the task and can stop when it lacks what it needs. That is a proposed efficiency benefit, not a measured token saving in this discussion.

Production deployment requires more than identity: teams need to discover agents and their capabilities, validate inputs and outputs, constrain execution and decide when a person must intervene. Davis says these questions bring application and security engineers into the same authorization discussion. He reports cases where restricting available actions improved an agent’s work, without presenting a comparative measurement.

Livingstone places runtime authorization inside the Secure Software Factory reference architecture, which describes human-driven, workflow-driven and agent-driven levels. At each level, access decisions support questions such as when to involve a person, which agents may hand work to others and whether an agent may patch production.

The bottleneck he identifies has shifted: generating software is easier, while getting it into production and keeping it working remains hard. A factory must support deployment, iteration and response to incidents, not just produce code.

A robot raising its arm must account for nearby objects and its own movement as well as its intended action. Davis uses that analogy to expand authorization context: location and time can matter, as can the security state of both a server and an administrator’s device. The same requested access may warrant a different decision when the environment changes.

Davis imagines attaching environmental context and user intent to an OpenTelemetry span, so someone inspecting a trace can see the conditions around a decision. Hardt adds the possibility of shorter-lived decisions that reflect the environment at the time. These are proposed capabilities, not a demonstrated implementation.

The audit log needs protection from the agent it records. Livingstone describes a Hugging Face incident in which an agent reached the open internet through a Squid proxy vulnerability and monitoring did not record the actions he wanted to inspect. His conclusion is to keep enforcement and a tamper-resistant record outside the agent’s control, including who delegated the work and for what purpose. He also expresses the view that existing liability frameworks should address damage from agents; the panel does not resolve the legal allocation in any particular case.

The closing question asks whether these controls are enough to avert catastrophic AI risks. Hardt considers fully autonomous agents detached from organizations speculative, while identifying two nearer concerns: an insider using privileged access to unleash an agent, and malicious actors deliberately using powerful tools to cause damage. He predicts serious incidents without assigning a probability.

Another panelist declines to put a number on the risk and expresses confidence that engineers will find solutions as they iterate on increasingly capable agents. Livingstone is more optimistic about the odds of extinction, placing them close to zero. He points to human incentives, liability and the ability to unplug computers, and expects society to learn from failures. He also acknowledges the cost to people who lose data in those failures. The panel ends with a real disagreement about risk, even as its members share an interest in building better controls.