I've been spending weekends thinking about authorization for AI agents, specifically delegation.
The failure mode I keep hitting: once you give an agent tools, it gets ambient authority over all of them. There's no clean way to say "for this task, read-only on the reports table" or "spin up no more than 3 VMs." When the agent spawns sub-agents mid-execution, they inherit full access by default.
IAM doesn't help much. Authority stays tied to the agent's identity even as intent shifts during execution.
I'm exploring a capability-based model instead: authority is explicit, task-scoped, and attenuating. Closest to Macaroons/Biscuit, but adapted for workflows where delegation happens dynamically mid-task.
I came to the same realization a while ago and started building an agent runtime designed to ensure all (I/O) effects are capability bound and validated by policies, while also allowing the agent to modify itself.
Thanks! Just looked at Agent OS. Love the 'Signed Receipts' concept in your AIR spec.
We reached the same conclusion on the 'Ambient Authority' problem, but I attacked it from the other end of the stack.
Tenuo is just the authorization primitive (attenuating warrants + verification), not the full runtime. The idea is you plug it into whatever runtime you're already using (LangChain, LangGraph, your own).
I'm currently in stealth-ish/private alpha, but the architecture is designed to be 'userspace' agnostic. I’d love to see if Tenuo’s warrant logic could eventually serve as a primitive inside an Agent OS process.
I'll shoot you a note. I would love to swap notes on the 'Capabilities vs. Guardrails' implementation details.
The failure mode I keep hitting: once you give an agent tools, it gets ambient authority over all of them. There's no clean way to say "for this task, read-only on the reports table" or "spin up no more than 3 VMs." When the agent spawns sub-agents mid-execution, they inherit full access by default.
IAM doesn't help much. Authority stays tied to the agent's identity even as intent shifts during execution.
I'm exploring a capability-based model instead: authority is explicit, task-scoped, and attenuating. Closest to Macaroons/Biscuit, but adapted for workflows where delegation happens dynamically mid-task.
Early prototype (Rust core, Python SDK, LangChain integration), still thinking it through. Notes here: https://niyikiza.com/posts/capability-delegation/