Nice use of Rust for the sandbox layer. One thing that helped in our multi-agent experiments was giving each agent its own key and having every tool call carry a signed receipt. That makes debugging a lot easier because you can at least answer "which agent requested this call with these params?"
If delegation is involved, carrying the delegation proof alongside the receipt helps explain why agent B thought it was allowed to act.
Gateways and signatures solve different problems. A gateway controls access; a signature lets the server verify what request was actually sent. That matters for replay, tamper, and forgery cases after the request passes the edge.
We've been using per-tool-call Ed25519 receipts for this in MCP flows. Verification happens directly in the server handler instead of adding another proxy hop. You can also add a server co-signature if you want proof of what the server received and responded.
Had a very similar issue porting a hypervisor to ARM S-EL2. Writes would succeed, there were no faults, and everything looked reasonable in GDB, but the other side never saw the data. The root cause was that Secure and Non-Secure physical address spaces were backed by different memory even at the same address, and a single PTE bit selected between them. That took me much longer to understand than I’d like to admit.
One thing I keep thinking about with AI security is that most of
the focus is on model behavior — alignment, jailbreaks, guardrails.
But once agents start calling tools, the attack surface shifts to
the execution boundary. A request can be replayed, tampered with,
or sent to the wrong target, and the server often has no way to
distinguish that from a legitimate call.
Cryptographic attestation at the tool-call level (sign the request,
verify before execution) would close a gap that behavioral controls
alone can't cover. Curious whether Glasswing's threat model
includes the agent-to-tool boundary or focuses primarily on the
model layer.