{"slug": "an-ai-agent-acted-across-two-companies-whose-audit-log-knows-which-human", "title": "An AI agent acted across two companies. Whose audit log knows which human?", "summary": "A developer built Crumb, a system that creates tamper-evident audit logs binding individual humans to AI agent tool calls across different identity providers. The system solves the cross-company delegation problem by stapling upstream tokens into new ones, preserving cryptographic proof of the original human identity. This allows auditors to verify the human behind an agent's action without trusting the operator.", "body_md": "Here is a setup that is going to be normal soon, if it isn't already.\n\nAlice logs into her company's tools through their identity provider. She points an agent at a task. That agent hands part of the work to a sub-agent, and the sub-agent calls a tool that lives in a partner company's system, behind a *different* identity provider. The tool does something it shouldn't. An auditor pulls the record.\n\nWhose log knows it was alice?\n\nNot the agent's. The agent is a process; it can claim to be anyone. Not the model's either, which reads whatever it was handed and has no idea which human is behind the session. The honest answer in most deployments today is that the partner's system can prove *a bot* called it, and can prove *which company's bot*, and then the trail goes cold. The person who actually directed the action dissolves into \"some agent at the vendor.\"\n\nI have been building [Crumb](https://crumb.alexlaguardia.dev) to refuse that outcome: a tamper-evident record that binds the individual human behind an agent's tool call, verifiable by someone who does not have to trust whoever ran the agent. Within a single identity provider, that chain was already working. This post is about the part that wasn't, and why it took longer than I expected.\n\nWhen the whole chain lives under one identity provider, delegation has a clean answer, and it is a real standard. RFC 8693 token exchange lets you mint a token that carries two identities at once: the human as the `sub`\n\n, and the agent acting for them as a nested `act`\n\nclaim. Add a hop and you nest again. The human stays at the root the whole way down.\n\n```\n{\n  \"iss\": \"https://idp-a.local\",\n  \"sub\": \"alice\",\n  \"act\": { \"sub\": \"researcher\", \"act\": { \"sub\": \"planner\" } },\n  \"aud\": \"read_record\"\n}\n```\n\nOne provider signs that token. A resource server verifies it against that provider's public key, walks the `act`\n\nchain back to alice, and it is done. No shared secret, no trusting the gateway that minted it. I covered that build in an earlier post. It holds up.\n\nThe catch is in the assumption hiding under \"one provider.\"\n\nReal delegation does not stay inside one company. The interesting, dangerous case is the one that crosses.\n\nSo `planner`\n\n, holding a token IdP A signed, needs the call into B's domain to carry a token B will honor. The textbook move is another RFC 8693 exchange, this time against B. You hand B the token A issued, and B mints you a fresh one.\n\nAnd right there is the problem, sitting in plain sight in the spec. When B does that exchange, it mints a token signed *only by B* and drops A's signature on the floor. The new token says `sub: alice`\n\nbecause B copied it across, but the cryptographic proof that A authenticated alice is gone. Downstream, all you hold is B's word: \"A told me it was alice.\"\n\nFor most systems that is fine, because most systems were already trusting B. But Crumb's entire reason to exist is to let an auditor verify *without* trusting the operator. A cross-issuer hop that resolves to \"trust B\" puts the trust-me point right back in the middle of the chain I was trying to make checkable. It is the one thing I am not allowed to wave away.\n\nThe fix I landed on is to stop throwing the upstream token away.\n\nWhen B exchanges A's token, two things happen. First, B verifies A's token against A's public key. B can only do that if it federates with A, so A has to be in B's trust set. That is a real relationship and I will come back to how honest it is. Second, instead of discarding A's token, B *staples* it into the one it mints: the exact inner JWS rides along in a `prv`\n\nclaim, its SHA-256 in `psh`\n\n, and the inner issuer in `pis`\n\n.\n\n```\n{\n  \"iss\": \"https://idp-b.local\",\n  \"sub\": \"alice\",\n  \"act\": { \"sub\": \"researcher\", \"act\": { \"sub\": \"planner\" } },\n  \"aud\": \"read_record\",\n  \"prv\": \"<the exact JWT that IdP A signed>\",\n  \"psh\": \"sha256:5992849d649979e6...\",\n  \"pis\": \"https://idp-a.local\"\n}\n```\n\nNow the outer token is not an assertion that alice was authenticated. It is a pointer to the original proof, hash-pinned so it can't be swapped. B signed its own segment. A already signed its segment. Nobody re-signed anybody else's.\n\nA verifier handed the outer token walks the chain backward and checks each segment against the key of the issuer that actually signed it.\n\nEach rule maps to one way a dishonest issuer could try to cheat:\n\n`prv`\n\nmust have `psh`\n\nequal to the hash of that `prv`\n\n. Swap the embedded provenance for a different token and the hash stops matching.`sub`\n\nhas to be the same identity at every hop. An outer token claiming to act for alice while stapling a token A issued for bob is a lie the walk catches.The part I care about most is the negative space. A mechanism that only demonstrates the happy path is a demo, not a security property. So the demo verifies the real chain across two issuers, and then it tries to break it five ways and shows each one failing by name.\n\nThe sharpest of the five: a *malicious B* tries to fabricate an upstream human. It controls its own signing key, so it mints a perfectly valid B token that says it is acting for `mallory`\n\n, and it staples a forged \"A token\" that also names mallory. B can sign its own segment all day. What it cannot do is sign as A. The verifier checks the stapled segment against A's real key, the forgery fails there, and B's attempt to invent a human it was never handed dies at the boundary.\n\n```\n3. malicious B forges an upstream human (mallory)\n   forged upstream    rejected (InvalidSignature) — B can't sign as A\n4. swap the stapled provenance (psh left stale)\n   swapped provenance rejected (StapleMismatch) — psh pins one predecessor\n5. B claims alice but staples bob's token\n   human discontinuity rejected (HumanDiscontinuity) — same human or nothing\n6. B rewrites the inherited actor chain\n   rewritten chain    rejected (ActorChainBroken) — append-only, no rewrite\n7. upstream from an unfederated issuer\n   unfederated issuer rejected (UntrustedIssuer) — verifier trusts its own set\n```\n\nThat last one matters more than it looks. Even when B chooses to accept some sketchy third issuer C and builds a chain on it, the verifier makes its *own* trust decision. B vouching for C buys C nothing. The verifier trusts its set, not B's.\n\nHere is the boundary, stated plainly, because pretending it isn't there is exactly the tell I am trying to avoid.\n\nThis is not a new standard. The `prv`\n\nand `psh`\n\nstaple claims are a Crumb convention. There is no RFC that defines them, and if two vendors wanted to interoperate this way they would have to agree on the format first. And the whole thing still rests on a federation trust set. Somebody, somewhere, decides which issuers they accept. I did not make that decision disappear.\n\nWhat I did was make it the *only* thing you have to decide, and make everything downstream of it checkable. You pick your trusted issuers, once, explicitly, in an object you can read. After that, no single issuer in the chain gets to assert the human on its own word. Each one signs only its own segment, and the verifier re-checks all of them. The federation set is the assumption. The cryptography is not.\n\nCross-issuer identity does not have a trust-free answer. The question gets smaller: who do you federate with. Everything after that is checkable.\n\nThe whole thing is one additive module and a demo you can run.\n\n```\ngit clone https://github.com/AlexlaGuardia/crumb\npython -m crumb.cross_issuer_demo\n```\n\nIt stands up two issuers with two different keys, crosses a real delegation chain between them, verifies it back to the human, and then fails the five forgeries above. The live timeline and the rest of Crumb are at [crumb.alexlaguardia.dev](https://crumb.alexlaguardia.dev).\n\nIf you work on agent identity or authorization and you think the stapling model has a hole in it, I want to hear where.", "url": "https://wpnews.pro/news/an-ai-agent-acted-across-two-companies-whose-audit-log-knows-which-human", "canonical_source": "https://dev.to/alexlaguardia/an-ai-agent-acted-across-two-companies-whose-audit-log-knows-which-human-12nl", "published_at": "2026-06-24 12:16:50+00:00", "updated_at": "2026-06-24 12:39:50.566664+00:00", "lang": "en", "topics": ["ai-agents", "ai-safety", "developer-tools"], "entities": ["Crumb", "RFC 8693", "IdP A", "IdP B", "Alice"], "alternates": {"html": "https://wpnews.pro/news/an-ai-agent-acted-across-two-companies-whose-audit-log-knows-which-human", "markdown": "https://wpnews.pro/news/an-ai-agent-acted-across-two-companies-whose-audit-log-knows-which-human.md", "text": "https://wpnews.pro/news/an-ai-agent-acted-across-two-companies-whose-audit-log-knows-which-human.txt", "jsonld": "https://wpnews.pro/news/an-ai-agent-acted-across-two-companies-whose-audit-log-knows-which-human.jsonld"}}