As AI agents move from recommending products to taking action, the place where a person reviews and approves that action becomes a critical security control. A trusted surface is a user interface that a person can rely on to see what an agent intends to do, authenticate themselves, give informed consent and create verifiable authorization. In broader terms, it is the trusted environment that connects users, agents and commerce.
The concept is becoming important in digital banking and payments because an AI agent may act when the customer is not present at checkout. Financial institutions therefore need to connect identity, device trust, delegated authority, transaction context and proof of intent. Entersekt’s work across authentication and fraud prevention sits within this wider shift from authenticating a person once to evaluating trust across a digital journey.
What is a trusted surface?
A trusted surface is a controlled interface that presents an agent’s proposed action to a person and records the person’s authenticated approval. It should show the relevant intent clearly, protect the approval process from tampering and create evidence that can be checked by the parties handling the transaction.
The term has a specific meaning in the Agent Payments Protocol, or AP2. AP2 defines the trusted surface as a user interface trusted to obtain informed user consent for an intent before creating a user-signed mandate. In AP2’s model, the trusted surface must be non-agentic, meaning that an AI model does not decide what the user is shown or how the authorization is verified.
This distinction matters. The shopping agent can search, compare and assemble a checkout. The trusted surface is the control point where the customer sees the proposed action, authenticates and approves it.
Why trusted surfaces matter in agentic commerce
Agentic commerce changes the assumptions behind online payments. A conventional checkout usually assumes that the person who selects the goods, reviews the details and authorizes the payment is present at the same interface. An AI agent separates those activities across different systems and may perform them at different times.
That separation creates four questions for banks, payment providers and merchants:
- Who is acting? The system must distinguish the customer, the agent and the merchant.
- What was authorized? The customer’s instruction must be specific enough to define the permitted action.
- Did the final action match the instruction? The payment must remain bound to the approved checkout, amount, merchant and applicable constraints.
- What evidence exists? The parties must be able to reconstruct what the customer approved and how the transaction was completed.
A trusted surface addresses the consent point in this chain. It does not replace risk decisioning, payment controls or post-transaction monitoring. It gives those controls a reliable record of the customer’s authenticated intent. This changing role of consent reflects the four shifts redefining trust in digital payments, including the move toward payment decisions that connect identity, intent, risk and evidence.
How a trusted surface works
A trusted surface generally performs five connected functions.
AP2 uses checkout mandates, payment mandates and receipts to connect these stages. The checkout mandate describes what the agent is authorized to purchase. The payment mandate connects that authorization to the payment. Receipts create evidence of the decisions made by the participating parties.
Trusted surface, trusted agent and trusted device
These concepts are related, but they solve different trust problems.
| Concept | What it establishes | Why it matters |
|---|---|---|
| Trusted surface | The customer saw and approved a defined intent | Protects consent and creates evidence of authorization |
| Trusted agent | Software is authentic and permitted to act for a person or organization | Connects the agent’s identity to delegated authority |
| Trusted device | A recognized endpoint is associated with an account or customer | Adds a possession signal and helps detect suspicious access |
| Authentication | A claimant has demonstrated control of an identity or authenticator | Supports access and transaction approval decisions |
| Authorization | An authenticated party has permission to perform a specific action | Limits what an agent or customer may do |
A trusted surface does not establish that a trusted agent remains within its permitted authority for every action. The broader trust decision depends on the relationship between the person, agent, device, merchant, payment credential and transaction.
What makes a trusted surface trustworthy?
Clear and complete intent
A trusted surface should make user intent explicit by showing the action, destination and expected outcome before the customer approves it. Relevant details may include the merchant, amount, currency, payment instrument, delivery conditions and limits on delegated authority. The exact information depends on the commerce and payment flow.
Strong customer authentication
Approval should be tied to a secure authenticator rather than an easily copied secret. Passkeys use public-key cryptography and bind authentication to the service domain. Device-native biometrics can unlock the credential while keeping biometric data on the customer’s device.
These controls align with modern digital identity guidance. NIST’s Digital Identity Guidelines address identity proofing, authentication, federation, privacy and fraud considerations, while FIDO standards define phishing-resistant authentication based on public-key cryptography.
Non-agentic control logic
The surface that displays the intent and creates the authorization must apply deterministic verification rules. An AI agent may prepare the request, but it should not be able to rewrite the approved amount, merchant or constraints after consent.
Cryptographic binding
The approval should be bound to the specific checkout, agent and transaction context. This limits replay, substitution and tampering risks. AP2 uses signed mandates, hashes and receipts to connect the customer’s approval to the checkout and payment records.
Revocation and accountability
Delegated authority needs a defined scope, an expiry date and a revocation mechanism. Financial institutions also need records that show which customer, agent, credential and policy were involved in an action. That evidence supports monitoring, investigation and dispute handling.
Trusted surfaces and financial authentication
Financial institutions already operate trusted surfaces in several forms, including mobile banking applications, authenticated web sessions and secure approval screens. The rise of agentic commerce extends their role. These surfaces may become the place where a customer delegates authority, reviews a high-risk action or confirms that an agent stayed inside defined limits.
Modern authentication can strengthen this environment by combining device identity, passkeys, behavioral signals, transaction context and risk-based decisioning. A low-risk action may pass with a silent signal from a recognized endpoint. A high-risk or unusual action may require explicit approval on a trusted device.
Entersekt’s agentic commerce research connects this model to a practical banking question: can the institution verify that an agent-driven action matches the customer’s intent and expected risk profile?
Trusted surfaces and payment security
Payment security depends on more than authenticating the customer at login. The payment flow must preserve the relationship between the customer’s instruction, the agent’s action, the merchant’s checkout and the payment credential.
Protocols such as AP2 address this by binding checkout and payment mandates to specific transaction details. Visa’s Trusted Agent Protocol takes a related approach by describing signed credentials that help merchants recognize an approved agent, verify its purpose and connect its request to a customer’s authorization.
For issuers and payment providers, this creates a new opportunity to use authenticated intent as a risk signal. The decision may consider the customer, device, agent, merchant, amount, transaction history and authorization constraints together rather than treating the payment request as an isolated event.
Implementation considerations for financial institutions
A trusted surface should be treated as part of the authentication and authorization architecture, not as a standalone screen. Start with the actions that carry the greatest financial or customer risk, such as account changes, new payment credentials, high-value transfers and agent-initiated purchases.
- Define the trust boundaries. Identify the customer, agent, application, merchant, credential provider and payment processor in each journey.
- Classify delegated actions. Separate actions that need immediate approval from those that can operate under time-limited constraints.
- Bind identity to intent. Record who authorized the action, which agent acted, what was permitted and how long the authority remains valid.
- Use risk-aware authentication. Escalate verification when device, behavior, transaction or agent signals indicate elevated risk.
- Preserve evidence. Retain the mandates, receipts, authentication result and relevant transaction context needed for investigation and disputes.
- Design recovery and revocation. Give customers and institutions clear ways to suspend an agent, replace a device or withdraw delegated authority.
These controls should work across mobile, browser, payment and customer-service channels. A fragmented trust model creates gaps when an agent starts in one channel and completes an action in another. Entersekt explores the importance of connected, real-time context in Banks need to know when the bot has permission, highlighting the risks of assessing banking channels in isolation.
What trusted surfaces do not solve
A trusted surface cannot determine on its own whether a customer’s instruction was manipulated before it reached the approval step. It also cannot guarantee that an agent, merchant or payment provider will behave correctly after authorization.
Financial institutions still need fraud monitoring, secure APIs, endpoint protection, identity verification, transaction controls and clear dispute processes. They must also account for threats such as prompt injection, malicious agents, stolen credentials, compromised devices and abuse of delegated mandates. The article Fraudsters may target AI mandates as agentic commerce takes off provides further context on emerging fraud risks when AI agents transact on customers’ behalf.
The right model is layered. A trusted surface protects consent. Authentication establishes control of a credential. Risk decisioning evaluates context. Authorization limits the action. Monitoring checks what happened afterward.
Frequently asked questions about trusted surfaces
➡️ Is a trusted surface the same as a trusted device?
No. A trusted device is an endpoint associated with a customer or account. A trusted surface is the interface that presents an action for informed approval and creates verifiable authorization. A trusted device may host a trusted surface, but the two concepts describe different controls.
➡️ Is a trusted surface a form of authentication?
A trusted surface is not itself an authentication factor. It is the controlled interface where authentication and consent can occur. The customer may authenticate with a passkey, biometric credential or device-bound key before the surface creates authorization for a specific action.
➡️ Why does agentic commerce need trusted surfaces?
Agentic commerce needs trusted surfaces because software may act when the customer is not present at checkout. The surface gives the customer a clear place to review the proposed action, authenticate, give approval and delegate authority under defined limits.
➡️ How do passkeys support a trusted surface?
Passkeys support trusted surfaces by using phishing-resistant public-key cryptography to authenticate the customer. When the customer approves an action using a passkey, the surface can link that approval to a known service and a specific transaction context.
➡️ How can banks prepare for trusted surfaces?
Banks can prepare by mapping delegated actions, defining trusted interfaces, binding customer identity to agent authority and transaction intent, and retaining evidence for review. Entersekt helps financial institutions connect device trust, authentication and risk-aware decisioning across digital journeys.
Sources and related articles
- Agent Payments Protocol specification, which defines the trusted surface role, mandates and receipts.
- Visa Trusted Agent Protocol, which describes cryptographic recognition and authorization for agentic commerce.
- NIST Digital Identity Guidelines and the FIDO authentication specifications, which ground identity, authentication and phishing-resistant credential concepts.
Standards and protocols for agentic commerce are evolving. Financial institutions should assess the latest specifications, applicable payment rules and regulatory obligations before implementing a production flow.
