PrincipalLatch

Inspiration

AI Agents can be correctly identified but still be unauthorized to access a specific resource. A user login tells us who opened the application, but it does not prove which Agent is calling the backend, whom it represents, or whether its authority has been revoked.

PrincipalLatch explores a simple idea: identity proves who the Agent is, while a revocable Mandate determines what it is currently allowed to do.

What it does

PrincipalLatch is lightweight authorization middleware for Agent runtimes.

In the demo, Alice authorizes a research Agent to read her document. The backend verifies the Agent’s signed Passport and Alice’s current Mandate before accessing the protected provider.

The same Agent is denied when it requests Bob’s document because Bob is a different resource owner. After Alice revokes the Mandate, the Agent keeps the same valid identity but can no longer access Alice’s document.

Each decision produces an audit record showing the Human, Agent, requested action, resource, policy rule, Mandate revision, and provider outcome.

How we built it

PrincipalLatch extends the Agent Starter Kit with:

• A React and Fastify control plane
• Short-lived Ed25519-signed Agent Passports
• Signed, revocable authorization Mandates
• Backend ownership and scope enforcement
• Isolated Codex Agent execution using rootless Podman
• TokenDance’s Responses API for model inference
• Separate policy and provider audit records

The backend derives the requested action from the API route and obtains resource ownership from a trusted Resource Catalog. Authorization is revalidated immediately before provider access, so revoked authority cannot be reused.

Challenges we ran into

The main challenge was proving that a denied request never reached the protected data provider. We therefore separated policy decisions from provider outcomes and recorded both independently.

Revocation also introduced a time-of-check/time-of-use problem. We addressed it by reloading the latest signed Mandate immediately before resource access and serializing admission and revocation operations for the same Mandate.

Accomplishments that we're proud of

• Enforced the required User A allow / User B deny scenario at the backend boundary
• Separated Agent identity from delegated Human authority
• Demonstrated revocation without rotating the Agent’s identity
• Proved that denied requests do not access protected content
• Added automated tests for signatures, ownership, revocation, isolation, race conditions, cleanup, and secret redaction
• Published a reproducible implementation and architecture documentation

What we learned

Agent identity alone is not enough for a trustworthy runtime. The system must independently verify the Human principal, the Agent principal, and the current authority for the exact action and resource.

We also learned that an authorization decision is only part of the evidence. A secure Agent runtime should be able to demonstrate whether the downstream provider was actually called.

What's next

Next, we plan to move Mandate and audit state into a transactional database, add managed key rotation and workload attestation, enforce outbound-network allowlists, and package PrincipalLatch as reusable HTTP and MCP middleware for different Agent runtimes.

Built With

• codex
• github
• typescript