Your AI Can Click “Buy.” Should It?
A discussion of agent identity and authorization, using a fictional finance agent to explore prompt injection, the confused deputy problem, and why an agent's intent should shape what it is allowed to do. It draws parallels to fraud detection in banking and social engineering, then turns to practical consumer use of agents for daily briefings, trip planning, and German bureaucracy, asking where convenience becomes risk and when a human should make the final call.
Agent Identity Is Authorization Under a New Set of Pressures
The conversation starts from a simple question: why is agent identity treated as a distinct problem when authentication and authorization have been studied for decades? The answer depends on which kind of agent is meant. A coding agent such as Claude Code or Codex operates under heavy human supervision, while a long-running autonomous agent that manages finances or inboxes is a different case entirely. To anchor the discussion, the speakers use a fictional finance agent named Ryan, who is responsible for monitoring accounts receivable, tracking cash, provisioning monthly spend, and producing monthly and quarterly reports without being prompted for each task.
Jobs, Tasks, and the Limits of Human-Era Access Models
The distinction between a job (responsibility) and the tasks that decompose from it matters here. For humans, access is granted through slow, request-based processes: a person asks another person for temporary access, and the request is approved. That model breaks down when an organization runs many agents, each of which may need narrow, short-lived access in the moment. Policies written in advance miss the “long tail” of access needs, because nobody knows an agent needs a specific scope until it actually does. Ideally access would be as precise, limited, and revocable as possible, but that is hard to maintain in practice.
Zero Trust Meets Non-Deterministic Software
Zero trust assumes that no system is trusted by default and that every caller must prove its identity on every request. Identity alone is not enough, though. Being able to prove who you are does not mean you are authorized to perform an action, so identity and authorization must be checked separately. Traditional software had one advantage that made this tractable: code was compiled and deployed, and it did the same thing every time. Microservices and purpose-built services emerged partly because a single monolithic program doing a hundred things is harder to govern from an identity perspective. Agents break this assumption. They can improvise and take actions they were not explicitly instructed to take.
The Confused Deputy, Prompt Injection, and Intent
The confused deputy problem, described decades ago, maps closely onto this situation. Imagine Ryan receives an invoice that, in addition to a legitimate payment request, instructs it to email someone or transfer money to a different account. That embedded instruction is effectively prompt injection: contradictory instructions entering a system that was authorized to act on other instructions. The more useful response is not primarily new identity machinery but risk assessment of individual actions, borrowing from fraud detection in banking.
The key ingredient is intent. To judge whether an action is legitimate, the system needs to know why the agent is doing it. Ryan’s intent is to produce a monthly financial report for leadership, and every action in the chain should be evaluated against that intent. The conversation raises the question of whether intent can always be captured, and suggests that for an organization acting on its own data and money, it should be a prerequisite. The harder case is an injection sophisticated enough to present a plausible intent, which an LLM acting as a judge might accept without hesitation. This is why policy enforcement remains necessary: a judge that reads plausible language can be fooled in ways that a hard rule cannot.
Lessons from Fraud Detection
Fraud systems in banking typically work in layers. The cheapest layer is deterministic policy, essentially a long chain of conditionals, which acts as a gray filter that actions must pass first. Machine learning models trained on known fraud patterns come next, and they are continuously updated because fraudsters keep adapting, which makes the field a cat-and-mouse game. Applying AI judgment is the most expensive layer and is generally reserved for cases the cheaper layers cannot resolve. An agent system could mirror this structure: deterministic policies, then statistical models, then an AI reviewer that evaluates the declared intent carried through the chain of actions.
Tokens, Identities, and Why Shortcuts Persist
Machine identities already outnumber human ones in a typical enterprise, and agents spawning agents multiply that number further. The difficulty is that the tools built for this were designed around fixed, deterministic workloads. Access tokens are minted at a point in time with scopes that reflect what was authorized then. Revoking them after circumstances change is expensive, so teams rely on short expiration times, which are an imperfect workaround. Tokens also do not record why access was granted, which is precisely the information needed for dynamic agents.
The speakers argue that the core principle is separating the principal, the human on whose behalf an agent acts, from the agent’s own workload identity. An agent should present its own identity as a workload acting for a named principal, and its permissions should be scoped to the task at hand and removed when that task completes. The reason this rarely happens is that narrow, ephemeral permissions are cumbersome to manage, so organizations default to over-permissioning. The result is probably many over-privileged agents in production.
Social Engineering as the Human Precedent
Prompt injection has a human analogue in social engineering. The speaker recounts a university researcher who mailed CD-ROMs packaged as official security updates to companies. Roughly 60 to 70 percent of recipients installed the software, despite the fact that it was harmless research code. The lesson is that people follow instructions that look authoritative, and agents exhibit the same vulnerability.
Consumer Agents and the Browser as Attack Surface
The conversation then turns to how individuals actually use agents. One speaker runs recurring computer-use tasks through the ChatGPT desktop app that scan several email accounts, LinkedIn, WhatsApp, Telegram, and Slack, then produce a daily briefing. The chat interface has become a control center: instead of switching between applications, the user dictates instructions such as replying to a Telegram message, drafting an email for review before sending, or forwarding a Slack message. The approach works well until too many threads run at once, when the browser’s tab focus gets disrupted. The workflow also surfaces a practical concern: if the agent operates through the same logged-in browser sessions a human uses, anyone who compromises that browser inherits the agent’s access to email, banking, and payment information.
This creates a tension between convenience and safety. A long-running logged-in session lets the agent complete tasks without interruption, but it also means the agent holds credentials and session state that an attacker could exploit. Banks offer a useful comparison. Routine actions proceed on a standard login, while larger transfers or new payees trigger re-authentication. The user gains additional permissions at a specific point in the workflow, and that step-up model suggests a pattern agents could adopt, where reading data and performing high-impact actions require different levels of approval. OAuth token exchange supports some of this, but it still does not capture intent.
Where Humans Still Make the Final Call
The Japan trip planning example shows the current boundary. The agent located flights and tickets, but the user completed passenger details and entered payment information manually. That is close to end-to-end automation, but a human still makes the final call on spending. A similar pattern appeared in a German residency and ID paperwork process: the agent filled out forms written in German and identified which documents were needed, yet it failed to flag that a driver’s license appointment required an interpreter. The requirement was not stated clearly on the website, and the user discovered it on arrival. The episode points to a gap that agents should close by surfacing unwritten requirements, such as booking an interpreter, rather than leaving users to find them out in person.
The German bureaucracy example also highlights a cultural difference in how rules are treated. Rules are written to be followed, not negotiated, and the speakers contrast this with the more flexible norms they experienced in Spain and the United States. For agent design, the parallel is that a policy should be treated as binding and applied consistently, since the purpose of writing a rule is that it gets enforced.
Identity, Principal, and the Path Forward
The overall picture is that agent identity is not a marketing category but a real problem created by software that acts on behalf of people and can improvise. Existing principles such as least privilege, zero trust, revocable access, and separation of duties still apply, but they must be adapted to agents that carry intent, spawn sub-agents, and operate through the same interfaces humans use. The most promising direction combines deterministic policy, risk scoring modeled on fraud detection, short-lived scoped permissions, and step-up approval for consequential actions, with a human retaining the final decision where the stakes are highest.