Users delegate authority to AI agents when they give software permission to access information or perform actions on their behalf. Secure delegation does not mean giving an agent unlimited control. It means establishing who the user is, which agent is acting, what the agent may do, under what conditions, for how long, and how every action can be reviewed or stopped.
This distinction matters as AI agents move from answering questions to taking actions. An agent may search for a product, schedule a payment, change an account setting, or initiate a financial transaction. In each case, the system must preserve the relationship between the human user, the agent, the requested action, and the organization responsible for authorizing it.
Delegated authority is permission granted by a person or organization to another party, application, or agent to act within defined limits. In an AI system, the delegation usually connects four identities:
The agent may act on behalf of the user, but it is not the user. A secure system should be able to identify both. This is different from authenticating an application with a shared service credential, because a shared credential can hide which user authorized an action and which agent performed it.
A practical delegation flow normally combines user authentication, consent, authorization, policy enforcement, and ongoing verification.
The user first proves control of their account through an appropriate authentication method. Authentication answers a narrow question: Who is the user? It does not, by itself, define what an agent may do after the user signs in.
For higher-risk financial actions, the authentication decision may also consider device, behavior, location, transaction details, and other context. The goal is to avoid treating a successful login as blanket approval for every later action.
The service should establish which agent is requesting access. Agent identity can include the application, deployment, software version, operator, organization, and execution instance. This creates a record of which software acted, not only which user was associated with the request.
Consent is meaningful only when the user can understand what they are allowing. A useful consent request explains:
Consent should not be hidden inside a vague statement such as “allow this agent to manage your account.” Specific permissions make authority easier to review and easier to enforce.
The resulting authorization should be scoped to the task. Common limits include:
| Control | Example | Why it matters |
|---|---|---|
| Resource scope | Read a user's calendar but not their banking data | Prevents unrelated access |
| Action scope | Create a payment instruction but not release funds | Separates preparation from execution |
| Amount or transaction limit | Approve purchases up to a defined value | Limits financial exposure |
| Time limit | Permission expires after one hour or one task | Reduces the impact of stale access |
| Audience restriction | Token is valid only for a specific API | Reduces replay and misuse risk |
| Context restriction | Allow transfers only from a trusted device or location | Connects authority to risk conditions |
OAuth 2.0 provides widely used mechanisms for delegated access, including authorization codes, scopes, refresh tokens, and token exchange. OAuth can help deliver a limited token, but it does not replace agent identity, business policy, transaction monitoring, or human oversight.
When an agent calls an API, the request should carry enough context for the receiving service to make a decision. That context may include the user, agent, client application, requested scope, transaction details, authorization time, and delegation chain.
A service should not assume that every action suggested by an agent reflects the user's original intent. The agent may misunderstand a natural-language request, rely on manipulated information, or be influenced by untrusted content. Authorization should therefore be checked at the point of action, not only when the agent is first connected.
Low-risk actions may proceed automatically. High-risk actions should trigger stronger controls, such as explicit confirmation, step-up authentication, transaction signing, dual control, or review by an authorized person.
This is especially important in banking and payments. A user may authorize an agent to “handle my bills,” but that general instruction should not automatically authorize a large, unusual, or irreversible transfer. The institution still needs to evaluate the specific transaction and the surrounding context.
Every material action should produce an auditable record showing who authorized the agent, which agent acted, what authority was used, what happened, and which controls were applied. Users and administrators also need a practical way to revoke permissions, rotate credentials, terminate an agent session, and investigate past activity.
Impersonation makes an agent appear to be the user. Delegation preserves the distinction between them.
| Impersonation | Delegation |
|---|---|
| The system sees the user as the apparent actor. | The system can identify the user and the agent. |
| Agent permissions may be difficult to distinguish from user permissions. | Agent permissions can be narrower than the user's full authority. |
| Audit records may not show the software responsible. | Audit records can preserve the delegation chain. |
| Revoking one agent may be difficult without affecting the user. | Agent access can be revoked independently. |
For regulated services, preserving this distinction supports accountability. It also helps security teams investigate whether an action resulted from a user's deliberate instruction, an agent's interpretation, a compromised integration, or an unauthorized party.
Agentic systems challenge a basic assumption in existing payment journeys: that the person who selects, reviews, and submits a transaction is the same person interacting with the payment interface at that moment.
When an agent acts for a user, financial institutions need evidence of:
This shifts the security question from “Was the account authenticated?” to “Was this action authorized, intended, and appropriate in context?” That question is closely related to the shift from identity to intent in account takeover prevention.
For agent-initiated payments, emerging approaches such as Google's Agent Payments Protocol (AP2) focus on verifiable proof of user intent, payment authorization, and transaction evidence. These approaches are developing, not a substitute for an institution's own authentication, fraud, compliance, and transaction controls.
An agent with access to more data or actions than it needs creates unnecessary exposure. Use least privilege and separate read, prepare, approve, and execute permissions.
An agent may have legitimate access but be tricked into using that access for an unauthorized purpose. The resource server should validate the requested action, the authority behind it, and the intended recipient rather than trusting the agent's explanation.
Instructions can arrive through documents, websites, email, tool responses, or other content the agent processes. Untrusted content must not silently expand the user's authority or override higher-priority policies.
Access tokens and refresh tokens can be abused if they are exposed, copied, or accepted outside their intended audience. Use short-lived, narrowly scoped credentials, secure storage, rotation, and sender-constrained or proof-of-possession mechanisms where appropriate.
Natural-language instructions are often incomplete. “Book the cheapest option” or “pay the invoice” may leave important questions unanswered. Agents should request clarification or confirmation when the action is material, irreversible, unusual, or outside established policy.
A log that records only the final API call is not enough. Investigators need the delegation grant, relevant policy decision, agent identity, user confirmation, tool calls, transaction data, and final outcome.
No single protocol solves every part of agent authorization. Implementations commonly combine established identity and authorization standards with application-specific policy and risk controls.
Several AI-agent authorization proposals are currently Internet-Drafts. They should be treated as work in progress rather than settled standards. Financial institutions should confirm the status, maturity, and regulatory suitability of any protocol before relying on it in production.
No. Secure delegation should give the agent only the permissions required for its task. An agent's authority should be narrower, time-limited, and subject to policy and transaction controls.
Not always. Consent establishes that the user allowed a class of access or action. The service may still need to evaluate the specific transaction, risk signals, compliance requirements, and whether the request matches the delegated scope.
The bank needs an agent identity that can be authenticated and linked to the client application, user, authorization grant, and transaction. The payment request and audit record should preserve that relationship.
The institution should be able to reconstruct the delegation and decision chain, revoke the agent's authority, investigate the action, and apply appropriate recovery or dispute processes. Clear limits and approval checkpoints reduce the potential impact of mistakes.
Authentication can help prove who was present or which credential was used. It does not automatically prove that the final action matched the user's intent. Intent validation requires transaction context, clear approval, policy checks, and evidence of what the user authorized.
Standards, protocols, and regulatory expectations for AI-agent authorization are evolving. Organizations should obtain appropriate legal, compliance, and security guidance before deploying agents that access customer data or initiate financial actions.