Why AMAP
Every enterprise, of any size, runs on email. Agents should be able to take part in it.
Email is the one channel every organisation already has, and the one that crosses organisational boundaries without prior arrangement. That makes it the natural place for agents to do real work. It is also where impersonation and pretexting already work against people.
The problem: give an agent a mailbox, and it inherits every pretext in it
Agents already work in email, mostly as personal assistants. Tools that let agents send mail are appearing, and they often put the mail credentials within the agent's reach.
In email, authority is carried by text, and a pretext is also text. An agent that reads email meets every pretext a person meets. An agent that can also send with the organisation's credentials turns a successful pretext into an action, at machine speed, under a legitimate identity.
Illustrative A routine supplier bank-detail change
Legitimate
- The supplier's accounts team writes: "Our remittance details have changed."
- The buyer checks out of band.
- Payment details are updated.
Agent with a mailbox
- A look-alike sender writes: "Urgent: use these new bank details today."
- The agent acts on the text.
- It confirms the change, from a legitimate address.
At machine speed: a new kind of insider.
Before giving an agent a mailbox, you need controls it can't talk its way around.
What changes: decide what the agent sees, and what it sends, outside the agent
Assume the agent will sometimes be fooled, or compromised. Don't try to make it trustworthy. Limit what an untrusted agent can do, and make the limit structural, not behavioural.
| Before: the agent holds the mailbox | After: trusted controls the agent can't bypass |
|---|---|
| A look-alike "use these new bank details" message arrives. | The look-alike message is held back. The agent never sees it. |
| The agent is fooled. | If one gets through, for example from a genuinely compromised supplier account that screening cannot catch because the sender is real, the agent can still be fooled. |
| It confirms the change, as the organisation, to whoever it chooses. | It can ask to reply, but it can't send. An unfamiliar recipient means the reply waits for a person.1 |
1 Assumes a policy that holds replies to unfamiliar recipients. AMAP fixes where that decision is made; the deployment decides what it is.
What the agent sees and what it sends are both decided outside it. AMAP governs the email channel. The agent's other tools, such as one that updates a vendor record, need their own isolation and safeguards.
The value: one side can start today, and the other side changes nothing
AMAP adds nothing to the wire between organisations. A counterparty receives ordinary email, so it needs nothing but an email address. That includes the counterparties that will never deploy an agent.
No coordination needed
You don't need a bilateral agreement, a shared platform or a new integration. Each side automates at its own pace.
No trust inherited
Their agent is just an external sender, and your policy decides. Authenticating its domain proves where it came from, not what it may commit anyone to.
Honest about what's proven
Specified "No change required" is a property of the protocol. Hypothesis The value in practice across independent organisations has not yet been tested.