Mandatum: Making an AI Agent's Authority a Chain You Can Verify

Most AI agents operate by inheriting credentials such as service accounts, API keys, shared tokens, or the user's session. However, this practice poses three major issues. Firstly, only 28% of organizations can trace agent actions back to a human or system across all environments. Secondly, 68% cannot differentiate AI agent activity from human activity.

Lastly, the lack of clear attribution makes it difficult to revoke access for a misbehaving agent without affecting the entire system. To address these problems, I developed a framework called Mandatum.

Mandatum establishes a chain of authority rooted in a named human for each AI agent. Each link in the chain commits to its predecessor by hash, ensuring that the links cannot be interchangeable. Capabilities can only be narrowed down as they move down the chain. The human at the root of the chain is carried unchanged to every leaf node, ensuring that attribution remains consistent even with arbitrary sub-delegation. Revoking any link in the chain will terminate all subsequent links.

The library itself does not make authorization decisions. Instead, it verifies that an agent holds delegated authority from a human and then passes this information to an OpenID AuthZEN Policy Decision Point (PDP). The request adheres to the AuthZEN COAZ-MCP binding's default mapping, focusing on tools and calls rather than the vendor's declared mappings or CEL (Contextual Expression Language). Additionally, it introduces new features that are not present in the standard bindings.

When it comes to implementing sequence-based authorization, the bottom block of the diagram represents the core functionality I aimed to build. It prevents a sub-agent from bypassing inherited constraints by delegating to a newly minted sub-agent. The state accumulated by the chain is fixed-size, regardless of its duration. This design allows for the creation of constraints that compile to a single bit (trigger status) and a counter, ensuring that the state remains constant throughout the chain's execution.

Several use cases could benefit from implementing Mandatum, such as a coding agent that opens pull requests, a support agent issuing credits, and a research agent with a limited number of invocations. These scenarios require mechanisms to restrict access based on the actions performed by the agent, and Mandatum provides a structured way to enforce these constraints at the tool level, rather than at the individual call level.

While Mandatum's implementation currently relies on an in-process state store, future improvements could include a distributed storage solution and third-party security reviews. The design hinges on the chain structure, which enables not only the identification of upstream actors but also the detection of authority widening through intermediate hops.

However, the exact placement of the chain within an AuthZEN request is still under consideration, and the working group is currently discussing the topic in the openid/authzen#612 thread. If you have experience with agent systems in production and believe the chain approach may be unnecessary, I encourage you to share your thoughts, as the specification includes an open-questions section where such feedback is actively sought.