Identify the fields that decide where money goes, require each to come from a signed or sealed source, and treat anything that arrives from outside as a prompt to verify, never as an instruction. A changed bank account in an email can open a verification task. Only a named person, using contact details you already hold, can change the payee.
What is the risk, and who owns the control?
An external claim is any statement that arrives from outside your authenticated systems: an email, a PDF invoice, a phone call, a chat message, a web page. Most are true. The ones that matter are not: "our bank details have changed", "please pay this urgently before the deadline", "the finance director has approved this". Agents are especially exposed, because they read every word and are built to be helpful.
The finance or payments operations lead owns the control. The fraud or financial crime team owns the verification method. Treasury owns the payee master data. The position, argued fully in why an external claim should never authorise a payment, is that no external claim, however plausible, should be able to change who is paid, how much, or when, without a separate check.
How do you set up the control, step by step?
- Person, payments lead: list the payment-critical fields. Payee name, account number, sort code or equivalent, amount, currency, date, and the approval itself. Evidence: a field list per payment type.
- Person, data owners: name the signed source for each field. Payee details come from the vendor master; amounts come from an approved invoice matched to a purchase order; approvals come from the approval system. Evidence: field-to-source map.
- Integration team: stamp every fact with its class. Inbound email, attachments and chat are external by default. Evidence: stamped facts.
- Platform: refuse payment actions that rely on external facts for any critical field. Evidence: refused verdicts naming the source bound and the field.
- Agent, depth 2: turns an external change request into a verification task. It drafts the task with the claim, the current signed value, and the difference. It does not contact the claimant using details from the claim. Evidence: a held task linked to the original message.
- Person, payments operations: verifies out of band. Call the supplier on the number already held in the vendor master, not the number in the email. Record who was spoken to. Evidence: a verification note.
- Person, a second approver: approves the master data change. A different person from the verifier. Evidence: two identities on the change.
- Platform: applies a cooling period to new payee details. The first payment to changed details is held for a named approver. Evidence: held verdict on first use.
| Step | The agent does | Depth | Stays with a person |
|---|---|---|---|
| List critical fields | Nothing | none | Payments lead |
| Name signed sources | Nothing | none | Data owners |
| Read inbound claim | Reads and stamps as external | 1 | Nothing |
| Raise verification | Drafts the task with the difference | 2 | Operations verifies out of band |
| Change master data | Nothing | none | Second approver |
| First payment to new details | Prepares the payment | 4, held | Named approver releases |
Which decisions does a named person keep?
- Verifying any change to payee details. Always by a route that does not depend on the claim.
- Approving the change in the master data. Separate from verifying it.
- Releasing the first payment to new details.
- Overriding urgency. If an external message says a payment must go today, a person decides whether that is true. The agent should treat urgency as a warning sign, not a reason.
- Reclassifying a source. Only a data owner can decide that a channel is signed.
Which controls matter, and what record do they produce?
Source class enforced at the action. The check happens when the payment is attempted, not when the email is read. Evidence: the verdict lists the class of every fact behind each critical field. Why class matters more than content is set out in sealed, signed, declared, external: why source class matters.
No contact details from the claim. Evidence: verification notes show the contact used and its source.
Separation of verifier and approver. Evidence: identities on each change.
Containment across agents. An accounts payable agent that writes an external claim into a shared note can pass it to every other agent that reads the note. Stamps travel with facts so the class survives. The wider problem is covered in how to stop one agent's mistake spreading to others. Evidence: derived facts keep the external class.
Append-only record. Evidence: the claim, the verification, the change and the first payment linked in one case.
What should you measure, and where does it go wrong?
Measure the number of external change requests received, the time to verify each, refusals on the source bound, payee changes made without a linked verification (target zero), and first payments to new details released without a hold (target zero).
It goes wrong in predictable ways. Attachments are treated as internal because they were saved to the document store. The agent replies to the claimant asking for confirmation, and the fraudster confirms. A trusted channel is assumed: a supplier portal where anyone with the password can change bank details is external for this purpose unless the change is verified. Urgency wins: a person under time pressure approves the first payment without reading the verification note. The control is per agent, so a second agent with payment rights never got the rule.
Where Pryme fits
In Pryme, the Pryme Context Protocol stamps every fact with its class, and the source bound is checked at the moment of action. An external claim cannot authorise a payment for any agent at any depth; that rule sits at the platform floor. Every refusal, verification task and held payment is filed. The governed agentic operating system guide shows how this connects to the other bounds.
Questions people ask
Can the agent ever accept new bank details from a supplier?
It can receive them and raise a verification task. It cannot apply them. The change becomes signed only after a person verifies it by a separate route and a second person approves it.
Does this apply to internal emails too?
Yes, if the email is the only evidence. An email from a colleague's address saying "pay this" is still a message, and accounts can be compromised. Approvals belong in the approval system.
What about customers asking to pay a refund to a different account?
Treat it the same way. A refund to an account other than the one the money came from is a payee change, and it needs verification and a held first payment.