CAPMAS, a joint effort from EPFL and Swisscom, lets developers give AI child agents narrowly scoped permissions via macaroons. It cuts token-handling latency by a factor of 30 and keeps full-user JWTs out of the agents’ reach.
Why the change matters
When an LLM orchestrates downstream tools, teams often hand the spawned “child” agent the same JWT the user logged in with. A JWT is a signed blob that lists every permission the user holds—HR data, project files, admin rights, and so on. If the model hallucinates a destructive command, the child agent can execute it with the user’s full authority. One mistake can expose an entire organization’s data.
The shortcomings of the current workaround
Minting a narrow token on demand with the RFC 8693 token-exchange flow adds several round-trips to the IAM system, inflates network traffic, and introduces noticeable latency. Teams that spin up many short-lived agents quickly find the overhead crippling.
How CAPMAS works
CAPMAS splits permission granting into two stages:
- IAM-side encoding – The IAM service runs an encoder that translates a natural-language request (e.g., “list files in the finance folder”) into a set of matching privileges.
- Macaroon creation – Those privileges become caveats inside a macaroon, a flexible token format that lets downstream agents add further restrictions but never remove existing ones.
When an agent receives the macaroon it can tighten the scope—say, limit a file-list request to a sub-directory—but it cannot broaden it. At each hop the IAM service validates the intersection of all caveats, guaranteeing that no agent exceeds the original allowance.
Performance numbers that speak for themselves
- Speed – CAPMAS processes a permission request in under 20 ms, roughly 30 × faster than the RFC 8693 exchange.
- Accuracy – In a benchmark with a large catalog of tools, a standard LLM missed 53 % of the privileges it needed. CAPMAS hit 90.9 % accuracy with only a 2.1 % miss rate.
- Bandwidth – Because the macaroon carries only the final set of caveats, the data exchanged is a fraction of what a full token-exchange flow would require.
A pragmatic adoption workflow
- Pre-filter the request – Convert the user’s natural-language intent into a top-k allowlist before any orchestrator touches the tool catalog.
- Seal the allowlist – Encode that allowlist into a macaroon that the child agent cannot broaden.
- Verify at the service – Let the target service ask IAM to compute the intersection of all caveats before honoring the request.
These steps replace the “give the child the whole house key” pattern with a “hand over a single-use, limited-scope key” model.
What CAPMAS doesn’t fix
The framework does not stop prompt-injection attacks, where an attacker manipulates the LLM’s prompt to inject malicious commands. Its protection covers honest-but-curious agents and untrusted LLMs that might otherwise act on a full JWT. Teams still need separate defenses—input sanitisation, sandboxing, or model-level guardrails—to address prompt-based threats.
Who stands to gain
- Enterprise developers building AI-driven assistants that invoke internal APIs.
- Security teams looking to reduce the blast radius of a compromised model.
- Product owners who need fast, reliable permission checks for high-frequency agent spawning.
What’s next
CAPMAS is a proposed design.
Takeaway: Swapping full-user JWTs for narrowly scoped macaroons gives developers a way to keep AI agents honest without paying the latency penalty of traditional token-exchange flows. The trade-off remains a continued need for prompt-injection safeguards.
