Why 'monitoring' isn't enough for AI agents — and how I made delegation cryptographically verifiable

Description and use

By signing delegations with Ed25519 and verifying them client‑side, the system provides independent, tamper‑proof proof of authorization. Capability subset checks prevent escalation, ensuring each hop only retains authority it actually holds.

Problem

AI agents increasingly delegate authority across multiple hops, but existing monitoring tools only log actions, which can be forged by the server and provide no independent proof of authorization.

Outcome

By signing delegations with Ed25519 and verifying them client‑side, the system provides independent, tamper‑proof proof of authorization. Capability subset checks prevent escalation, ensuring each hop only retains authority it actually holds.

Workflow

• 1. Agent A creates a delegation payload (who, to whom, capabilities, timestamp).
• 2. A signs the canonical JSON payload with its Ed25519 private key.
• 3. The server stores the payload, signature, and A’s public key.
• 4. A client (auditor or browser) fetches the delegation data.
• 5. The client rebuilds the canonical bytes (sorted keys, no whitespace).
• 6. The client imports A’s raw 32‑byte Ed25519 public key via WebCrypto.
• 7. The client verifies the signature against the canonical bytes.
• 8. If verification succeeds, the delegation is marked verified; otherwise it fails.
• 9. The system also checks that the delegated capabilities are a subset of the delegator’s effective capabilities, rejecting escalations.

Evidence

When an auditor asks "who authorized this agent to spend money / delete data / call that API?", is a log you control actually proof?

Source

Instead of recording that Agent A delegated to Agent B, what if the delegation itself were cryptographically signed by A?

Source

The browser fetches the delegation's payload, signature, and the signer's public key, rebuilds the canonical bytes, and verifies — locally.

Source