Giving someone permission to act for you usually comes with an understanding of where that permission ends. An employee with a company card may book travel within an agreed budget but needs a manager’s approval for a larger expense. The arrangement works because the people involved understand who may make which decisions and when they need to ask again.
AI agents bring that familiar arrangement into transactions spanning different software providers, banks, and merchants. A customer can delegate a purchase and leave the agent to complete it, but the business accepting the transaction needs evidence of who granted permission, what it covers, and whether it is sufficient for the requested action.
The industry is already building ways to exchange that evidence. FIDO’s standards work draws on Google’s Agent Payments Protocol and Mastercard’s Verifiable Intent to support agent authentication and verifiable authorization. EMVCo’s draft framework for card-based agentic payments explores how participants can share and manage customer-authorized intent over time. These initiatives address related parts of the challenge, but businesses still need to decide whether the evidence presented is sufficient for a particular action.
For Regula, that is the central question behind Know Your Agent, or KYA. Our starting point and the core foundation is a verifiable connection between a person whose identity has been established and an agent acting with their authority. The business then evaluates that authority against the particular action, its risk, and its own requirements.
Start with the person granting authority
This approach concerns agents that identify themselves and present credentials or other evidence of their relationship to a customer. When software simply uses a customer’s ordinary login details, the service may be unable to distinguish an agent from the person or another program. Detecting hidden automation is a separate challenge, and a KYA framework should be clear about that boundary.
For a declared agent, the first task is to establish the connection to the person granting authority. An agent credential may identify the software or its operator, while a delegation record describes permission from a customer. The business needs evidence linking those records to that customer’s verified identity.
Existing verification and secure authentication may already support that connection. For an organizational customer, the business also needs to establish whether the person granting permission holds the relevant role, because confirming an employee’s identity does not establish their right to authorize every company expense.
Establish what the customer delegated
Take Anna, for example: she authorizes an agent to buy a refundable flight for under $500. Her permission should make the important conditions clear, including whether the budget includes fees and whether “refundable” means money returned to her card rather than credit for another flight.
Those conditions determine which decisions Anna has delegated. A refundable ticket for $480 could fit the instruction; a $700 ticket or a non-refundable fare would require a different agreement. Neither the agent’s valid credentials nor Anna’s verified identity expands the permission she gave.
The same principle applies to the purpose of the task. Permission to buy travel does not authorize changes to a bank account’s spending limits, even if those changes would help the agent complete the booking. The receiving organization needs to check the action against the actual scope of the delegation before considering whether its other requirements are satisfied.
Evaluate authority in the context of the action
An action can fit the customer’s instruction and still require additional checks under the receiving organization’s rules. A bank may accept a routine payment within an existing arrangement while requiring further confirmation for a sensitive account change, depending on the value, sensitivity, risk signals, and applicable regulatory requirements.
This is the decision KYA needs to support: can the agent proceed with the authority and evidence it currently holds, or is something further required? The organization must respect the limits the customer set even when its own assessment considers a proposed action low risk.
Permission must still be valid when the agent acts. The organization needs to check whether it has expired, been changed or withdrawn, and whether subsequent account or identity events require further confirmation. A disputed account recovery, for example, may warrant renewed identity verification even if the original delegation has not expired.
To make that assessment, the organization’s decision process needs to bring several kinds of information together:
| Information or rule | What the organization needs to understand |
|---|---|
| Verified human identity | Who was verified and how the current instruction connects to that person. |
| Agent credential metadata | Which agent or operator is identified, who issued the credential, and whether it remains valid. |
| Delegated authority constraints | The permitted actions, spending limits, conditions, expiry, and any withdrawal of permission. |
| Transaction context | The specific action, amount, merchant or payee, and purchase or payment terms. |
| Risk signals | Relevant circumstances, such as disputed account recovery or unusual activity. |
| Triggers for additional checks or approval | Conditions requiring additional approval, authentication, or identity evidence. |
| Organization’s internal rules and policies | A valid delegation doesn't obligate the organization to do something outside its rules and policies. |
The information may come from different participants, including an identity provider, bank, payment network, or authorization service. The organization accepting the action needs to understand what each source establishes and where its own rules require more evidence.
This attention to decisions during execution is reflected in Singapore’s industry-developed Safeguards for Agentic Finance at Runtime framework, published under MAS’s BuildFin.ai initiative. It addresses how agent actions are authorized, how human oversight is activated, and what is recorded at decision points.
Bring the human back for a specific reason
Returning to the customer should resolve the uncertainty preventing the next action. If Anna’s agent finds only a non-refundable ticket, it needs her agreement to those revised terms, with the approval connected to the fare she reviewed. If the service doubts who is giving that agreement, it also needs stronger evidence of the approver’s identity.
Those situations call for different responses. A changed purchase condition needs approval; uncertain account control may require stronger authentication or renewed identity verification. Liveness can contribute evidence that a real person is present during a check, while agreement to the purchase still needs to be established separately.
Where existing identity evidence and a secure session remain trustworthy, repeating a document check may add little. The organization should request the evidence needed for the decision, and decide in advance what happens if the customer cannot respond. An agent may continue searching within the original conditions or let an offer expire, but the customer’s absence cannot authorize a broader task.
Our integration with Bernini.ai illustrates how identity verification can support this process today. When a customer’s identity needs to be established or reconfirmed, Bernini.ai’s DAFNE platform can invoke Regula’s document and biometric checks, then use the results to determine how the interaction should continue under the organization’s rules. This provides evidence of who the person is, while any approval of changed purchase terms must also be recorded as part of the interaction.
Connect identity assurance to the wider workflow
For an organization accepting an agent’s action, identity verification forms part of a wider decision. The organization also needs evidence of what the person authorized, whether that permission is still valid, and whether it covers the proposed action.
Regula IDV Platform supports configurable verification workflows, allowing organizations to define where identity checks belong in their processes. We see an opportunity to extend this approach to KYA by connecting human identity evidence with information from other systems about the agent, its permissions, and the proposed action. This would help organizations assess whether the agent has sufficient authority to proceed or whether the person needs to return to approve a change, complete an additional identity check, or both.
Preserve the evidence behind the decision
An organization should be able to explain why it allowed an agent to continue or requested the person’s involvement. Regula’s 2026 study “Identity Verification in the Age of AI agents” found that 82% of surveyed organizations had been required to justify identity decisions externally, while only 50% could fully reconstruct those decisions. These findings concern identity workflows, but the same need for an explanation applies to delegated actions.
For Anna’s booking, the records should connect her verified identity, the agent, the permission in force, the fare and any subsequent approval to the final decision. That gives the organization a way to show which authority it accepted and why, while giving Anna a way to understand how her instructions were used when she was no longer supervising the purchase herself.
The future of KYA will not be decided simply by whether an AI agent can present a valid credential. Trust will depend on whether an organization can connect four things: the verified person, the agent acting for them, the authority that was actually delegated, and the action now being attempted. If those elements no longer align, the organization needs to establish why before proceeding. Depending on the reason, it may need fresh customer approval, stronger identity evidence, or to stop the action altogether.
.webp)
