The payment networks have told the market that trusted-agent protocols close the agent risk problem. They do not. Protocols close the identity and authorisation half of the problem. The other half, whether the transaction inside a valid mandate is fraudulent, is still unaddressed. This article explains the gap and what has to sit on top of the protocol to close it.
What a trusted-agent protocol actually confirms
A trusted-agent protocol confirms three things. First, that the agent exists in a registry and has been verified by the network. Second, that the user issued a signed mandate authorising the agent to transact under specified conditions. Third, that the request currently being made is cryptographically bound to that mandate.
These are important properties. They prevent a random script from pretending to be a shopping agent, and they prevent an agent from exceeding the limits the user set.
Where protocols stop
Protocols do not evaluate whether the counterparty is a mule. They do not detect whether the agent was prompted into transacting through social engineering. They do not know whether the mandate itself was obtained by deception. They do not catch unusual velocity across the agent's user base. They do not notice when a session's declared intent diverges from the actual outgoing payments.
In short, protocols answer 'is this agent authorised to transact,' not 'is this transaction fraudulent.' These are different questions and need different machinery.
How fraud looks inside a valid mandate
Prompt injection: a malicious instruction embedded in a product page, document, or email causes the agent to transact against the user's actual interest. The mandate is valid, the agent is valid, the transaction is fraudulent.
Social engineering through the agent: a bad actor manipulates the user into authorising an action the user would not have taken with full context. The mandate is signed under false pretence, but it is signed.
Mandate drift: within a session, the agent's actions move away from the user's declared intent. Each individual action is inside the mandate, the pattern is not.
Agent session compromise: the agent's credentials or session token are stolen. The mandate is valid, the attacker is now acting as the agent.
Mule payouts inside the limit: the agent is instructed to pay to a counterparty that is a mule. The amount is within the mandate, the counterparty is the fraud.
What has to sit on top of the protocol
A fraud layer that treats the agent as a first-class actor with its own features. Agent ID, mandate hash, declared intent, session identifiers, agent reputation, velocity across the agent's user base, counterparty history, and intent-vs-cart divergence are all features the model should see.
A policy engine on the bank side where the customer can define which agents are allowed, with what limits, and when step-up authentication is required. The bank owns consent, not the network.
An explainability layer that can tell the bank, the customer, and later the regulator exactly why a given agent transaction was blocked or allowed.
Why this matters for the bank, not just the network
If an agentic payment goes wrong, the customer calls the bank. The customer does not call the agent, does not call the network, and probably does not know what a protocol is. The bank will be asked why the transaction was allowed. The bank's answer cannot be 'the agent protocol said it was fine,' because that is not an answer the regulator or the customer accepts.
UMCA's Agent Risk Intelligence provides the fraud layer banks need on top of whichever protocol is operating, or in its absence. It is the second half of the picture the networks have not shipped.
