An external claim should never authorise a payment

An external claim can tell an agent what to look into, but it should never be enough to move money. Emails, uploaded invoices, phone instructions and web content all arrive from outside your control, and any of them can be forged. A payment needs evidence from a source you hold or have verified, and a named person to release it.

What counts as an external claim?

An external claim is any statement that reaches the agent from a party you have not verified, through a channel you do not control. A supplier email saying its bank details have changed is one. So is a PDF invoice attached to a ticket, a caller saying they are the account holder, or a page the agent found while researching a counterparty.

The content may well be true. Most supplier emails are genuine. The problem is not that external claims are usually false; it is that the agent has no way to tell the true ones from the forged ones by reading them. A well-made fake invoice is, to a model, the same as a real one.

This is why provenance has to be a property of the fact, not a judgement the model makes. The guide to why source class matters sets out the four classes. External sits at the bottom, not because it is worthless, but because it cannot be checked from where the agent stands.

Why is payment the line, rather than every action?

Agents act on external information all the time, and they should. A customer's email describing a problem is external, and the agent should read it, classify it and draft a reply. A news item about a counterparty is external, and the agent should flag it for a reviewer. None of that moves money.

Payments are different for three reasons. They are hard to reverse once they leave your account, often impossible on instant rails. They are the direct target of fraud, so the incentive to forge the claim is high. And the harm lands on someone who did not make the mistake: your customer, your supplier or your firm's balance sheet.

So the rule is narrow and firm. External information may inform any task. It may not, by itself, be the evidence that authorises a payment, a change to payee details, or a release of funds.

How does a forged claim get through without this rule?

Take an illustrative case. A mid-sized firm's accounts payable agent receives an email from what looks like a regular supplier. It says the supplier has moved banks and attaches a letter on headed paper with new account details. The agent updates the payee record and, the next day, prepares the monthly payment of 40,000 to the new account.

At no point did the agent do anything outside its instructions. It was asked to keep supplier records current and to prepare payments on schedule. A person may even have approved the payment, seeing a familiar supplier name and a familiar amount. The fraud succeeded because a claim from outside was allowed to change the facts that the payment rested on.

The fix is not a smarter model. It is a rule that a payee change sourced from an external claim is held until it is confirmed through a channel you already trust, such as a call-back to a number held on file.

What may the agent do with an external claim instead?

The agent still has useful work to do. It should not ignore the claim; it should route it.

• Record the claim with its source class, so every later step can see where it came from.
• Compare it against what is already held: the existing payee details, past invoices, the supplier's registered address.
• Flag mismatches and draft the verification request, such as a call-back script or a confirmation letter.
• Hold any payment or payee change that depends on the claim, with a reason a person can read.
• Close the task only once the claim has been confirmed through a stronger source, and record which one.

This keeps the agent productive and keeps the authority where it belongs. Our playbook on how to stop external claims from authorising payments covers the steps in operational detail.

What does this rule not replace?

Provenance is one bound among several. A payment that rests on strong evidence still needs a person to release it, because the payment approver must never be the agent. It still has to sit inside the customer's own limits. And it still has to clear the agent's certificate for that capability.

The external-claim rule closes one specific route: the one where the agent is tricked into treating a forged instruction as a fact. It belongs on any list of what an AI agent should never be allowed to do, but it is not the whole list.

Where Pryme fits

The Pryme Context Protocol stamps every fact reaching an agent with its provenance class: sealed, signed, declared or external. An external claim cannot authorise a payment. That rule is enforced at the moment of action, not left to the model's judgement, and the verdict records which fact was external and why the action was held or refused. See the governed agentic operating system, explained for how this sits alongside the other bounds.

What should you do differently?

List every action in your payment flows that can be triggered or changed by information arriving from outside: payee changes, new beneficiaries, urgent payment requests, refund destinations. For each one, ask whether an external claim alone could carry it through. Where it could, add a rule that holds the action until a stronger source confirms it, and make that rule part of the platform rather than part of each agent's prompt.