An agent can ask. Only the runtime can act.

The problem

An agent is an untrusted process

It can be prompt-injected, buggy or compromised. Connecting it to a workflow does not make its decisions trustworthy, and message access brings three risks.

What matters is not whether the agent can write a message. It is whether it can authorise one, choose the identity it goes out under, or step around policy.

The problem

AMAP's one move: a request is never permission

AMAP was designed for email workflows, where the runtime holds the mail credentials. This walkthrough uses amap-router-local, a reference runtime that carries no mail at all: no provider, no credentials, no network. It moves the same artifacts between agents on one machine, so what is left is exactly what the protocol asks of a runtime.

Isolation first

AMAP assumes the agent is already contained

The protocol defines who may do what across a boundary. It does not create the boundary. Running each agent in isolation is the operational baseline that gives the protocol's guarantees meaning, and it is good practice even when nothing is malicious.

Isolation first

…and run it like infrastructure

If your environment cannot provide one of these, the matching guarantee does not hold. It is not merely weaker. This walkthrough uses sandy for isolation because it provides every one of them, and shows each.

The pieces

Five parts, one boundary: they meet only at the contract, and only one side is trusted

The seam

The boundary is a directory tree

Runtime and connector never call each other. They share directories, and the design rests on which side can write which one. Everything the agent reads, it cannot forge; everything it writes is only a request.

Two lanes

Mail and delegation carry different trust

They are declared separately, and a pair of agents may sit on only one of them, so a sender can never pick which trust it is judged under.

On both lanes a reply goes back to the sender and nowhere else, even against the direction of a delegation edge.

Knowing it holds

Three outcomes, never two

The deployment's verify checks the manifest against the policy, the payload byte for byte, each agent's lanes and mounts, and the router's container and health. Every check ends one of three ways.

The fleet roster keeps the same honesty. It lists who exists so agents can find addresses, and says it is neither permission nor a prediction. The verdict in outbox/results is the only report of what happened.

Run it yourself · with sandy

Why sandy

The runtime and the connector need no changes between environments; only the deployment knows where agents run. sandy supplies every property AMAP needs, and makes each one visible.

sandy is one choice, not a requirement. You can replace the sandy container with the isolation method of your choice, provided it implements at a minimum credential, network and file-system isolation: for example, NVIDIA's OpenShell, a runtime built for isolating autonomous agents, or the gVisor sandbox with an egress allowlist in defending-code-reference-harness. The runtime and the connector stay as they are. What you replace is this deployment, with one that supplies each row of the table above in your environment.

Run it yourself · 1 of 4

Install sandy, then choose a path

# install, then check the host is ready
curl -fsSL https://raw.githubusercontent.com/rappdw/sandy/main/install.sh | bash
curl -fsSL https://raw.githubusercontent.com/rappdw/sandy/main/doctor.sh | bash
sandy --print-schema | jq '.schema_version'   # must print 3 or 4

curl -fsSL https://raw.githubusercontent.com/proofpoint/amap-deploy-sandy/main/install.sh | bash

mkdir -p ~/amap-demo/alpha ~/amap-demo/beta
cd ~/amap-demo/alpha && sandy --start
cd ~/amap-demo/beta  && sandy --start

mkdir -p ~/amap && cd ~/amap
git clone https://github.com/proofpoint/amap-deploy-sandy
python3 amap-deploy-sandy/amap-siblings.py --apply

Run it yourself · 2 of 4

Make two workspaces and install

# sandy creates each sandbox at its first launch (3 of 4)
mkdir -p ~/amap-demo/alpha ~/amap-demo/beta

cd ~/amap/amap-deploy-sandy
python3 amap-sandy.py install --apply
# writes a working policy, the payload, and the router's config

"feature": {
  "version": 1,
  "groups": {},
  "default_peers": [],
  "peers": {},
  "task_graph": "ALL",
  "task_deny": [],
  "fleet_domain": "sandy.<this host>.internal",
  "container_recreate_interval_hours": 24
}

task_graph: "ALL"

The delegation lane, which is directed: every selected agent may task every other.

default_peers, peers, groups

The mail lane, which is mutual. Empty, because a pair of agents may not sit on both lanes: they carry different trust.

task_deny

Ordered pairs [sender, recipient] to block even though task_graph grants them. None.

fleet_domain

The right-hand side of every address, naming this host's router: <slug>@sandy.<this host>.internal. A name only; nothing touches a network.

container_recreate_interval_hours

How often the agent containers are rebuilt, once you load the job amap-sandy.py cadence prints.

This works as written: every sandbox launched with claude is selected, and every one may task every other. To narrow it, edit ~/.sandy/features/amap/feature.json in place and run install --apply again. A glob in its top-level sandboxes.exclude keeps a sandbox out, and explicit task_graph edges replace "ALL". Nothing is delivered until you start the router in the next step: that is the approval.

Run it yourself · 3 of 4

Start the router, then the agents, then verify

# the router needs no agent running yet
cd ~/amap/amap-router-local
docker/build.sh
docker/run.sh --config ~/.sandy/features/amap/router.json \
  --detach

# then agents, in any order, whenever you need them
cd ~/amap-demo/alpha && sandy --start
cd ~/amap-demo/beta  && sandy --start

cd ~/amap/amap-deploy-sandy
python3 amap-sandy.py list     # both: selected
python3 amap-sandy.py verify   # exit 0 before going on

Starting the router is the approval: its first poll of each agent is first sight, and anything staged before it is never delivered. The router picks up each agent on its next poll after the agent launches, so agents can delegate to each other as they come online. It runs with no network and re-reads its config every poll, so later policy changes need only install --apply.

Run it yourself · 4 of 4

Send your first delegation

cd ~/amap-demo/alpha && sandy --attach   # terminal 1
cd ~/amap-demo/beta  && sandy --attach   # terminal 2: watch it arrive

You have just watched the first flow for real. The runbook then breaks each guarantee on purpose: a write to the payload fails with EROFS, a task that was never granted is held, and a stopped router makes verify say UNKNOWN.

amap-deploy-sandy · Apache License 2.0 · AMAP is a draft contract; the spec repository is normative.