The Personal Agent Protocol Is Taking Shape. What Does It Mean for Financial AI Risk?

A personal agent can be correctly identified, properly authorised and still do the wrong thing.

That distinction matters as Sierra and Meta develop the Personal Agent Protocol, an emerging open standard intended to help personal AI agents interact with businesses on behalf of customers. Introduced on 6 October 2026, the initiative proposes a common framework for agent identification, customer authorisation and interactions across websites, APIs and company-operated agents.

On 9 October, Sierra published a further update alongside the developing specification, announcing additional design partners and demonstrating how a personal agent could interact with a business agent in a mortgage-related workflow.

The design-partner list includes financial institutions such as Bank of America, BBVA, Chime, Synchrony and Wells Fargo, alongside PayPal/Venmo and technology participants including Adyen, Mastercard, Plaid, Stripe and Visa.

Their participation signals interest in developing common infrastructure for agent-to-business interactions. It does not establish that every listed organisation has deployed or formally adopted the protocol.

The specification remains in development, with Draft 0.1 documentation and unresolved questions. Payments are explicitly identified as an area for future extension rather than functionality already covered by the current draft.

Yet the risk-management questions begin well before an AI agent receives permission to initiate a payment.

An authorised personal agent could retrieve account information, interact with a bank's customer-service system, request documents or communicate financial recommendations. Each interaction creates questions about what the agent understands, which instructions it follows and how it responds when a workflow becomes ambiguous.

The Personal Agent Protocol addresses an important part of this challenge: establishing who an agent represents and what it is permitted to access or do.

AetherLab's view is that financial institutions must evaluate a separate question alongside identity and authorisation: does the agent behave appropriately within the authority it has been given?

That distinction could become central to how banks, payment providers and financial-service platforms evaluate third-party personal agents.

The Personal Agent Is Becoming a New Financial-Services Interface

Most financial institutions have built their digital experiences around a familiar assumption: customers interact directly with a website, mobile application or customer-service representative.

Personal agents introduce another participant into that relationship.

Instead of navigating several banking interfaces, a customer might instruct an AI assistant to retrieve information, compare financial products, investigate a transaction or contact a service provider.

The agent would then interact with the institution's systems on the customer's behalf.

Sierra's October announcements provide an early illustration of how this model could develop.

In a demonstration involving Meta's personal agent and Rocket's mortgage-related agent, the interaction showed how a customer-authorised personal agent could share information and communicate with a business agent during a mortgage pre-approval workflow.

The demonstration is relevant because mortgage-related interactions involve customer information, financial context and potentially consequential recommendations or next steps.

It should not be interpreted as evidence that the protocol is generally deployed in mortgage processing or that participating financial institutions have adopted it in production.

What it illustrates is the proposed interaction model: a customer delegates part of a task to a personal agent, and that agent communicates with a business through a structured interface.

This creates questions that conventional website and API integrations were not necessarily designed to answer.

How does the institution recognise that a request originates from an authorised personal agent? How does it establish which customer the agent represents? What information can the agent retrieve, and which actions require additional approval?

Without a common interaction framework, businesses may need to support different approaches to agent identification, authorisation and communication.

The Personal Agent Protocol is an attempt to establish that shared foundation.

For financial institutions, its significance extends beyond convenience. A common framework could make it easier to distinguish authorised agent interactions from unsupported automation and establish clearer boundaries for what an agent can request.

However, the practical implications will depend on how the specification develops and how institutions implement it.

What the Personal Agent Protocol Is Designed to Establish

In its announcement introducing the protocol, Sierra describes an open standard intended to make interactions between personal agents and businesses more structured and interoperable.

The proposed framework addresses several important requirements.

It is designed to help businesses recognise when an AI agent is acting for a customer, support customer authorisation for read-only or write access, and define parameters governing what personal agents can do.

The specification uses OAuth for authorisation and supports connections through standards such as MCP and OpenAPI. It also aims to maintain sessions across different interaction surfaces, including websites, APIs and company-operated agents.

These capabilities address meaningful integration problems.

A bank receiving a request from a personal agent needs a way to establish the relationship between the customer, the agent and the requested action.

A financial-service provider may want to permit an agent to retrieve information while preventing it from changing customer details.

A customer may need a way to grant specific access without giving an agent unrestricted control over an account.

The protocol provides a proposed structure for these interactions.

Its draft specification also includes an optional Operations extension addressing approval, recording and duplicate-execution concerns for supported actions.

These are useful safeguards for workflows where an agent may request or initiate consequential operations. Approval mechanisms can help ensure that particular actions are explicitly authorised, while execution records and duplicate-execution protections can support operational accountability.

However, implementing these mechanisms does not, by itself, demonstrate that an AI agent will interpret instructions appropriately, resist manipulation or follow customer-defined behavioural policies under adversarial conditions.

The distinction is important.

The protocol addresses identity, authorisation and aspects of interaction control. Behavioural assurance concerns how the AI system actually responds within that framework.

Financial institutions need to evaluate both.

The current development roadmap also makes clear that the specification is evolving. Payments remain an open topic for future work.

The participation of payment companies and networks should therefore not be interpreted as evidence that the protocol already enables payment initiation or that financial institutions are processing payments through it.

Identity, Authorisation and Behaviour Are Three Different Controls

As personal agents become more capable, financial institutions need to distinguish three layers of assurance.

Identity establishes who is making the request and whom the agent represents.

An institution needs to recognise the agent and establish its relationship to the customer. This helps determine whether an interaction is legitimate and which customer context applies.

Authorisation establishes what the agent is permitted to access or do.

A customer might authorise an agent to retrieve transaction information but not update account details. The institution must enforce those permissions through appropriate access controls and application logic.

Behavioural assurance examines how the agent acts within those boundaries.

An agent might possess legitimate read access but still disclose sensitive information in an inappropriate response. It might follow manipulated instructions embedded in retrieved content, misunderstand a customer's request or produce a prohibited recommendation.

The distinction matters because an agent can operate within technically valid permissions while producing an outcome that violates a customer-defined policy or the institution's intended workflow.

Consider an agent authorised to retrieve account information for a customer.

The authorisation may permit access to transaction records. It does not necessarily establish that the agent will summarise those records accurately, avoid unnecessary disclosure or resist instructions embedded in untrusted content.

Likewise, permission to interact with a customer-service system does not prove that the agent will distinguish a routine information request from an action requiring additional confirmation.

Authentication and access controls remain essential. They limit the systems and information available to an agent.

Behavioural testing examines a different aspect of risk: what the agent attempts, produces or communicates when conditions become unusual or adversarial.

For consequential financial workflows, all three layers need to work together.

Financial Risk Can Arise Before an Agent Can Initiate Payments

The most obvious concern about personal agents in financial services is whether they could initiate transactions incorrectly.

That concern is legitimate, but it would be premature to treat the Personal Agent Protocol as a payment-initiation standard. Payments remain outside the current draft.

More importantly, meaningful financial risk can arise in interactions that do not involve moving money.

An agent with read-only access may retrieve sensitive account information. A customer-service agent may respond to requests involving disputed transactions, account restrictions or confidential documents.

An advisory assistant may communicate recommendations based on financial information. Another agent may help a customer complete a service request or update preferences that affect future communications.

These workflows involve different levels of authority, but each can produce consequences if the AI behaves inappropriately.

Read access does not eliminate disclosure risk

An agent may be authorised to retrieve information without being authorised to disclose that information to every participant in a connected workflow.

For example, a personal agent could receive account information from a financial institution and then interact with an external website or another service.

The risk question is whether the agent preserves the intended information boundaries when combining data from multiple sources.

The institution's access controls govern what its systems release. Testing the agent's behaviour can help assess whether the information is subsequently handled in accordance with the defined policies and instructions.

Customer-service interactions can become consequential

An AI agent might contact a bank's customer-service assistant to investigate a disputed transaction.

The request could involve sensitive account details, customer identity information or explanations of previous activity.

If instructions become ambiguous, the agent may produce an inaccurate representation of the customer's intent or disclose more information than the task requires.

The relevant test is whether the agent recognises the uncertainty and requests clarification when necessary.

Financial recommendations create a separate exposure

A personal agent comparing financial products may be authorised to retrieve product information.

That does not establish that every recommendation it produces will be appropriate, accurate or consistent with the policies governing its use.

Behavioural testing can examine manipulated instructions, prohibited responses and sensitive-information handling.

It does not validate the financial merits of the recommendation or replace the institution's suitability, compliance or decision-making processes.

These examples are potential risk scenarios, not documented failures of the Personal Agent Protocol or its design partners.

They illustrate why the scope of financial AI risk is broader than payment execution.

The Challenge of Connecting One Agent to Another

One of the more important implications of the proposed protocol is its support for interactions across websites, APIs and company-operated agents.

This could create workflows in which a customer's personal agent communicates with a financial institution's own AI assistant, which may then interact with internal tools or information systems.

Each component may have its own instructions, permissions and safeguards.

The challenge is understanding how those controls behave when the components interact.

Imagine a customer asking a personal agent to investigate an unexpected account charge.

The personal agent contacts the bank's customer-service agent. The bank's agent retrieves relevant information through an internal system and returns a response.

The personal agent then interprets that response and communicates with the customer.

The workflow appears straightforward, but several behavioural questions arise.

What happens if the bank's response contains text that the personal agent incorrectly treats as an instruction? What if the customer has asked for something that conflicts with the institution's policies? What if an external source introduces misleading information into the interaction?

Could the personal agent disclose sensitive information while attempting to clarify the issue? Could either agent produce a prohibited response or continue when human escalation is required?

An institution may have tested its own customer-service agent in isolation. That does not necessarily establish how the complete interaction will behave when an external personal agent becomes part of the workflow.

Similarly, a third-party personal agent may have passed its developer's internal evaluations without being tested against the specific policies and sensitive-information boundaries of the financial institution it connects to.

This is where the scope of testing becomes important.

For consequential applications, institutions may need to evaluate the complete workflow, including agent-to-agent communication, connected tools, external inputs and escalation conditions.

The Personal Agent Protocol can provide a framework for authorised interactions. Behavioural testing can examine whether those interactions produce acceptable outcomes under defined scenarios.

What Banks and Payment Providers Should Test

The appropriate testing programme depends on the financial workflow, the authority granted to the agent, the customer-defined policies and the consequences of failure.

A banking customer-service assistant should not be evaluated using exactly the same scenarios as an investment-research agent or a personal agent interacting with a mortgage provider.

The controls, sensitive information, prohibited behaviours and escalation requirements may differ substantially.

However, the identity-versus-behaviour distinction suggests several areas that deserve attention before integrating third-party personal agents into consequential financial workflows.

Manipulated instructions and conflicting objectives

An agent may encounter instructions from the customer, the institution, external websites and connected tools.

Testing should examine whether untrusted content can redirect the agent or cause it to violate customer-defined policies.

It should also explore how the agent responds when instructions conflict or the customer's request is unclear.

Sensitive-information handling

An agent may legitimately retrieve financial information while still being subject to restrictions on how that information can be used or disclosed.

Testing should examine attempts to elicit inappropriate disclosure, combine sensitive information in prohibited ways or communicate data to unintended recipients.

These tests complement, rather than replace, account permissions and technical data-access controls.

Abnormal tool and API responses

A connected application may return incomplete information, an unexpected error or a response that the agent cannot interpret reliably.

The institution should understand whether the agent requests clarification, stops the workflow, escalates appropriately or attempts an alternative action that exceeds its intended role.

Policy adherence in customer-service workflows

An agent may be permitted to help with disputes, account enquiries or service requests while remaining subject to defined policies.

Testing can examine whether unusual prompts or conflicting instructions lead to prohibited advice, inappropriate responses or failures to follow escalation requirements.

Recovery, approval and human escalation

The protocol's proposed Operations extension recognises the importance of approval and execution safeguards for certain actions.

Behavioural testing can complement these mechanisms by examining whether an agent requests confirmation when appropriate, interprets approval conditions correctly and stops when a workflow requires escalation.

Not every consequential situation should be resolved autonomously.

The objective is to develop evidence showing how the agent behaves under conditions that ordinary functional testing may not cover.

What Evidence Should Institutions Request Before Integration?

If personal agents become a common interface to financial institutions, product, security and risk teams may need a consistent way to evaluate their behavioural exposure.

A statement that an agent uses an established authorisation protocol is useful, but it addresses only part of the assessment.

Institutions may also need evidence describing which behaviours were tested, the policies applied and the limitations identified.

For a third-party agent integration, a reviewable evidence package could include the scope of the assessment, the model and workflow configuration tested, and the relevant customer-defined policies.

It could record scenarios involving manipulated instructions, sensitive-information requests, ambiguous intent, abnormal tool responses and attempts to bypass behavioural restrictions.

Where vulnerabilities are identified, the documentation should explain what happened, which controls were affected and how the issue was remediated.

Retesting results can then show whether the relevant behaviour improved under the scenarios examined.

Residual risk should remain visible. A successful assessment does not establish that every possible failure has been eliminated, particularly when agents interact with changing external systems.

This evidence can support several institutional decisions.

A product team may use it to understand whether a proposed integration is ready for further evaluation. Security teams may use it to investigate behavioural vulnerabilities. Risk and governance leaders may use it to assess whether identified weaknesses have been addressed.

The evidence can also help institutions determine where additional controls or restrictions are necessary before expanding an agent's access.

These are proposed risk-management practices, not requirements established by the Personal Agent Protocol.

Their value lies in giving institutions a more substantive basis for assessing agent behaviour than identity and authorisation alone can provide.

How AetherLab Supports Behavioural Assurance

AetherLab's role sits alongside identity, authorisation and conventional financial controls.

It does not provide OAuth infrastructure, verify agent identities, authorise payments or enforce account-level permissions.

Its contribution is the assessment of generative and agentic behaviour against defined policies and the preparation of reviewable technical evidence.

AdversarialScan can perform point-in-time testing of relevant AI behaviour, including manipulated instructions, conflicting objectives, ambiguous customer intent, attempts to bypass defined policies, sensitive-information requests and abnormal tool responses.

For a financial institution evaluating a personal-agent integration, this can help identify whether the tested system attempts prohibited actions or produces responses inconsistent with the institution's requirements.

Evidence Pack can document the testing scope, scenarios applied, observed failures, controls and mitigations, retesting results and remaining exposure.

This information can support product, security, risk and governance reviews, including decisions about whether further remediation or testing is appropriate.

AetherLab does not validate financial decisions, replace fraud or transaction-monitoring systems, certify compliance or guarantee that an AI agent will never fail.

Nor does the existence of an assessment establish that an agent has met every requirement for integration with a particular financial institution.

The purpose is narrower and more practical: helping institutions understand how AI systems behave under tested conditions and giving decision-makers evidence they can review.

The Next Financial AI Risk Question Is Behavioural

The Personal Agent Protocol represents an important attempt to establish common rules for how personal AI agents interact with businesses.

For financial institutions, clearer agent identification, customer authorisation, action-approval mechanisms and interaction parameters could provide a useful foundation for future integrations.

But those controls answer specific questions.

They help establish who an agent represents, what access it has been granted and how certain operations should be authorised or recorded.

They do not establish that every agent will interpret instructions appropriately, resist manipulation or remain within customer-defined behavioural policies throughout a complex workflow.

That distinction matters even before payment initiation becomes part of the protocol.

A personal agent retrieving account information, interacting with a banking assistant or communicating financial recommendations may already be operating in a consequential environment.

As institutions evaluate these integrations, the relevant question should extend beyond whether an agent is authorised to participate.

They should also ask what evidence demonstrates that the agent behaves appropriately when instructions conflict, external information is manipulated or connected systems behave unexpectedly.

Identity establishes the relationship. Authorisation establishes the permitted scope. Behavioural testing helps examine what happens within that scope.

For financial institutions preparing to interact with third-party personal agents, understanding all three will be important to making informed product and risk decisions.

Evaluate AI Behaviour Before Expanding Agent Access

AetherLab helps financial institutions test generative and agentic AI behaviour and prepare reviewable technical evidence for product, security and risk decisions.

See how AdversarialScan and Evidence Pack can support the evaluation of customer-facing financial AI, agentic workflows and third-party agent integrations.

Explore AetherLab's Payments Solutions