{"slug": "why-monitoring-isn-t-enough-for-ai-agents-and-how-i-made-delegation-verifiable", "title": "Why 'monitoring' isn't enough for AI agents — and how I made delegation cryptographically verifiable", "summary": "A developer built an open-source platform, AI Control Tower, that makes AI agent delegation cryptographically verifiable by signing each delegation with Ed25519 rather than relying on server-side logs. The approach uses canonical JSON serialization so that signatures can be verified byte-for-byte in the browser via WebCrypto, letting auditors check proofs without trusting the server. The developer argues this closes a gap as agents gain autonomy and regulation such as the EU AI Act demands verifiable accountability.", "body_md": "The problem nobody talks about with AI agents\n\nWe're rushing to give AI agents autonomy. An orchestrator agent calls a research agent, which calls a writer agent, which calls a tool. Each hop, one agent hands some of its authority to another.\n\nEvery \"AI governance\" tool I looked at solves this the same way: it logs everything. You get a dashboard, a timeline, an audit trail. Which sounds great — until you ask one uncomfortable question:\n\nWhen an auditor asks \"who authorized this agent to spend money / delete data / call that API?\", is a log you control actually proof?\n\nIt isn't. A log is a claim. If the server writes the log, the server can write anything. Monitoring tells you what a system says happened. It doesn't let anyone prove it independently.\n\nAs agents get more autonomous — and as regulation like the EU AI Act starts demanding \"verifiable accountability\" — I think this gap becomes a real problem. So I tried to close it.\n\nThe idea: sign the delegation, not just log it\n\nInstead of recording that Agent A delegated to Agent B, what if the delegation itself were cryptographically signed by A? Then:\n\nAnyone can verify the signature against A's public key\n\nThe server holds only public keys — it can verify a delegation, but it can never forge one\n\nAn auditor can check the proof on their own machine, without trusting my server at all\n\nThat last point is the whole game. \"Trust me, here's my log\" becomes \"here's the math, check it yourself.\"\n\nI built this into an open-source platform (AI Control Tower), but the technique is general. Let me show the core of it.\n\nWhy Ed25519\n\nFor signing delegations you want:\n\nSmall keys and signatures (32-byte public keys, 64-byte signatures) — these get stored and passed around a lot\n\nFast verification — you may verify a whole chain of hops\n\nDeterministic signatures — no per-signature randomness to get wrong\n\nAvailable everywhere — including natively in the browser via WebCrypto\n\nEd25519 checks every box. It's modern, boring in the good way, and — crucially for the \"verify in your browser\" goal — supported by the WebCrypto API.\n\nThe tricky part: canonical bytes\n\nHere's the bug that will silently break everything if you're not careful.\n\nTo verify a signature, the verifier must hash exactly the same bytes the signer signed. If your backend signs a JSON object and your frontend re-serializes it even slightly differently — different key order, extra whitespace, different number formatting — the bytes differ, and every verification fails, even though nothing was tampered with.\n\nThe fix is a canonical serialization both sides agree on. In Python (signing side):\n\n``` php\nimport json\n\ndef canonical_bytes(payload: dict) -> bytes:\n    # sort_keys + no whitespace = deterministic output\n    return json.dumps(\n        payload,\n        sort_keys=True,\n        separators=(\",\", \":\"),\n    ).encode(\"utf-8\")\n```\n\nAnd the matching thing in JavaScript (verifying side) has to produce byte-for-byte the same output. JSON.stringify with manually sorted keys and no spaces gets you there for simple payloads — but test it against real data, because nested objects and unicode will bite you.\n\nLesson learned: write a test that signs on the backend and verifies with the exact frontend serializer, using awkward payloads (unicode, nested objects, numbers). That one test caught more bugs than anything else.\n\nSigning (backend, Python)\n\nUsing the cryptography library (no exotic deps):\n\n```\nfrom cryptography.hazmat.primitives.asymmetric.ed25519 import (\n    Ed25519PrivateKey, Ed25519PublicKey,\n)\n\ndef generate_keypair():\n    private_key = Ed25519PrivateKey.generate()\n    public_key = private_key.public_key()\n    return private_key, public_key\n\ndef sign_payload(private_key: Ed25519PrivateKey, payload: dict) -> bytes:\n    return private_key.sign(canonical_bytes(payload))\n```\n\nWhen Agent A delegates, you build a payload describing the delegation (who, to whom, what capabilities, when), sign it with A's private key, and store the payload + signature + A's public key.\n\nVerifying — in the browser, offline\n\nThis is the part that makes it verifiable rather than trust-me. Using WebCrypto in the browser:\n\n```\nasync function verifyDelegation(publicKeyRaw, signature, canonicalPayloadBytes) {\n  // import the raw 32-byte Ed25519 public key\n  const key = await crypto.subtle.importKey(\n    \"raw\",\n    publicKeyRaw,\n    { name: \"Ed25519\" },\n    false,\n    [\"verify\"],\n  );\n\n  return crypto.subtle.verify(\n    { name: \"Ed25519\" },\n    key,\n    signature,\n    canonicalPayloadBytes,\n  );\n}\n```\n\nThe browser fetches the delegation's payload, signature, and the signer's public key, rebuilds the canonical bytes, and verifies — locally. The server never gets a chance to lie, because the proof is checked on the client. If the math checks out, you see a green \"verified\" badge; if anything was altered by a single byte, it fails.\n\n(Note: browser Ed25519 support via WebCrypto is now widespread, but if you need to support older browsers, keep a graceful fallback that verifies server-side and clearly labels it as such — don't pretend a server-side check is the same guarantee.)\n\nThe other half: capabilities can only shrink\n\nVerifiable signatures answer \"did A really authorize this?\". But there's a second rule that matters for agent safety:\n\nAn agent can never delegate more authority than it holds.\n\nIf A can call read and search, it must not be able to hand B write or delete. So every delegation runs a subset check: the delegated capabilities must be a subset of the delegator's own effective capabilities. If B tries to escalate, the delegation is rejected and an incident is raised. Combine that with the signatures, and you get a chain where every hop is both authorized (subset) and provable (signed).\n\nWhy this matters more every month\n\nSingle-agent systems were easy to reason about. Multi-agent systems — where agents spawn and delegate to other agents — are not. As they spread into companies, \"show me the log\" stops being good enough. People will start asking \"prove it.\" Verifiable delegation is one way to have an answer.\n\nTry it / steal the idea\n\nThe full implementation — signing service, capability validator, a live delegation graph where you click any edge and verify the signature in your browser — is open-source (Apache-2.0), self-hosted, and runs with one Docker command:\n\ngit clone [https://github.com/kironovlaziz-del/AI-tower.git](https://github.com/kironovlaziz-del/AI-tower.git)\n\nGitHub: [https://github.com/kironovlaziz-del/AI-tower](https://github.com/kironovlaziz-del/AI-tower)\n\nI'm a solo developer and this is an early, honest MVP — I'd genuinely love feedback, especially on the canonicalization approach and the capability model. If you're working on agent infrastructure, I'd like to hear how you're thinking about the accountability problem.\n\nHave you hit the \"monitoring isn't proof\" wall with agents yet? How are you handling it? Let me know in the comments.", "url": "https://wpnews.pro/news/why-monitoring-isn-t-enough-for-ai-agents-and-how-i-made-delegation-verifiable", "canonical_source": "https://dev.to/kironovlazizdel/why-monitoring-isnt-enough-for-ai-agents-and-how-i-made-delegation-cryptographically-verifiable-5bad", "published_at": "2026-09-22 01:24:51+00:00", "updated_at": "2026-09-22 01:53:55.699070+00:00", "lang": "en", "topics": ["ai-agents", "ai-safety", "ai-policy", "developer-tools", "ai-infrastructure"], "entities": ["AI Control Tower", "Ed25519", "WebCrypto", "EU AI Act", "Python", "JavaScript"], "alternates": {"html": "https://wpnews.pro/news/why-monitoring-isn-t-enough-for-ai-agents-and-how-i-made-delegation-verifiable", "markdown": "https://wpnews.pro/news/why-monitoring-isn-t-enough-for-ai-agents-and-how-i-made-delegation-verifiable.md", "text": "https://wpnews.pro/news/why-monitoring-isn-t-enough-for-ai-agents-and-how-i-made-delegation-verifiable.txt", "jsonld": "https://wpnews.pro/news/why-monitoring-isn-t-enough-for-ai-agents-and-how-i-made-delegation-verifiable.jsonld"}}