Guest Post by Alan Karp, Principled Architect of The Global Computer,
DIF Member, Trusted AI Agents Working Group
Editor’s Note: To Silicon Valley insiders, Alan Karp has been the unsung guru of delegation and “capability security” for decades, urging people at a wide range of conferences to reconsider some of the scaling and security properties of open-world tokens in distributed systems. Below, he gives a general, high-level argument grounded as much in human nature as in computer science how permissions get delegated when humans send out agents (who spin up swarms of sub-agents and communicate with other companies’ agents…), i.e. in the bold new future in which our industry suddenly finds itself.
It seems that everyone wants to control delegation, almost instinctually: either who you can delegate to, or whether anyone holding a permission can delegate it to anyone else in the first place. For example, one of SSI’s most important pieces of canonical prior art, the Simple Public Key Infrastructure (SPKI) defined in IETF RFC 2693, includes a do-not-delegate boolean on all its permission objects. Other systems limit the depth of delegation. Still others put restrictions on who can use a delegation (requiring authentication and often RBAC in the invocation of that delegation token). The result is a system that is often less secure and harder to use than a fully capability-based system, but more “familiar” to identity professionals.
Blocking delegation breaks “encapsulation,” meaning, it tends to lead to a mismatch between the contents of a token and how it actually gets used. It presumes that you know how I run my business, i.e., that the specifics of my IT infrastructure and its policies can and should be knowable to anyone who might need to interact with them. You could set a max delegation depth of 3, which works today across all your use cases and counterparties, but breaks tomorrow when I add a security-countersignature step to my implementation without telling you. You limit who I can delegate to, which breaks my service when I reorganize my company.
The problem isn’t limited to delegating to others. Say that you get a delegation at max-depth granting you query and update permission on a database. You want to do a query with a program that you don’t fully trust. Unfortunately, you can’t delegate just the query permission, because that attenuated token would be max-plus-one, over the limit. Instead, you might be tempted to hand to that half-trusted piece of software your own credential, which risks the program doing an unwanted update (in your name and on your liability).
As I’ve seen many times in my years of consulting and advising, blocking delegation prevents careful attenuation, making the system less secure (or making Peter insecure to keep Paul from overstepping in this one narrow way). You’ve also lost responsibility tracking, since more than one party is using the same credential. Even when you’re prevented from sharing credentials, you can always proxy requests (the classic, “here log in as me, then it will let you do it”). Now your users are introducing an unnecessary level of indirection!
A better approach is a “Please do not delegate” or “Only delegate according to this policy.” Most people want to obey your policy unless it keeps them from doing their job. You can ask them to include a justification for violating your rules. You can detect and document the exception you’re making each time, and see opportunities for refinement emerge from the logs. Just don’t block the delegation unconditionally, or people will work around your restrictions!
Continue the conversation at AIdentity & Non-Human Identity Impact Day 2026
On October 6 in Munich, DIF Executive Director Grace Rachmany will speak at AIdentity & Non-Human Identity Impact Day 2026 in the session: Who Approved That? The One Question Your Agent Logs Cannot Answer [Advanced]
📅 October 6, 2026 · 15:20–15:40
📍 Marriott Hotel, Munich, Germany
The session will examine how to trace an AI agent’s actions back to the human who authorized them, the scope of the authority granted, and when that authority was revoked—including a live forensic demonstration using KYA-OS.
