tenuo

Tenuo is a task-scoped authz primitive for agentic work. We are an open protocol and an open source implementation at github.com/tenuo-ai/tenuo We created a fork of OWASP finbot with Tenuo wired in and red-teamed it with promptfoo. We went from 50 successful attacks to 0 with Tenuo. The promptfoo attacks were able to fool the model, but the deterministic guardrails Tenuo provides stopped it from acting on the poisoned instructions.

We are working on Tenuo[1] which is basically macaroons for agents. It uses capability-based cryptographic "warrants" as an authorization mechanism for multi-hop delegation. Rust core. Apache2.0 [1] https://github.com/tenuo-ai/tenuo

XAA is a great improvement to where we were in 2025. It helps track user access to mcp tools. There is a few other ongoing efforts in the IETF community. Eg; https://datatracker.ietf.org/doc/draft-niyikiza-oauth-attenu... (implementation: https://github.com/tenuo-ai/tenuo)

Building tenuo.ai (https://github.com/tenuo-ai/tenuo): task-scoped authorization for AI agents. Rust implementation of capabilities + cryptographic offline verification.

We've been working on that with tenuo: https://github.com/tenuo-ai/tenuo Task-scoped "warrants", attenuating with delegation, and enforced cryptographically at tool call. Macaroons/Biscuits for agents basically.

We've been working on a warrant model that ensures task-scoped authorization: constrain your agents to specific tools and specific arguments, cryptographically enforced at the MCP tool boundary. Even a fully compromised agent can't reach outside its warrant. Open source. github.com/tenuo-ai/tenuo

The boundary also needs to hold if the agent is compromised. Proxying keys is the right instinct. We took the same approach at the action layer: cryptographic warrants scoped to the task, delegation-aware, verified at the MCP tool boundary before execution. Open source core. https://github.com/tenuo-ai/tenuo

The two-layer framing is right. Sandbox-exec contains local blast radius, and that's important. But if the agent already has a credential in memory, sandboxing the filesystem doesn't help. I've been working on a primitive for scoped authorization at the tool call level: what was this agent allowed to do, for which task, signed by whom. The core is open-sourced: https://github.com/tenuo-ai/tenuo

Right on. Human-in-the-loop doesn't scale at agent speed. Sandboxing constrains tool execution environments, but says nothing about which actions an agent is authorized to take. That gets even worse once agents start delegating to other agents.I've been building a capability-based authz solution: task-scoped permissions that can only narrow through delegation, cryptographically enforced, offline verification. MIT/Apache2.0, Rust Core. https://github.com/tenuo-ai/tenuo

I've been working on a different authorization model for AI agents, motivated by a simple problem: once agents start delegating work to other agents, identity-based permissions and prompt guardrails break down fast. Tenuo makes authority task-scoped. A manager agent starts with a signed capability ("warrant") and can delegate to workers, but delegation can only attenuate. Each step gets narrower authority, and it disappears when the task ends. Even if an agent is prompt-injected, it can't take actions outside its warrant. Every tool call requires proof-of-possession, and arguments are validated against explicit constraints before execution. This is inspired by systems like Macaroons / Biscuit / UCAN, but adapted for AI agents processing untrusted input: - signed, ephemeral capability tokens - mandatory proof-of-possession - constraint che

Working on this problem: https://github.com/tenuo-ai/tenuo Different angle than policy-as-YAML. We use cryptographic capability tokens (warrants) that travel with the request. The human signs a scoped, time-bound authorization. The tool validates the warrant at execution, not a central policy engine. On your questions: Canonicalization: The warrant specifies allowed capabilities and constraints (e.g., path: /data/reports/*). The tool checks if the action fits the constraint. No need to normalize LLM output into a canonical representation. Stateful intent: Warrants attenuate. Authority only shrinks through delegation. You can't escalate from "read DB" to "POST external" unless the original warrant allowed both. A sub-agent can only receive a subset of what its parent had, cryptographically enforced. Latency: Stateless verification, ~27μs.

Interesting. Are you focused on the delegation chain (how capabilities flow between agents) or the execution boundary (verifying at tool call time)? I've been mostly on the delegation side. Working on this at github.com/tenuo-ai/tenuo. Would love to compare approaches. Email in profile?

I've been going down this exact rabbit hole for the last few months. The 'opt-in guardrails' problem you mentioned is the dealbreaker. If the agent can just ignore the read_file tool wrapper and call os.system('cat ...'), the policy is useless. I ended up building a 'capability token' primitive (think Macaroons or Google Zanzibar, but for ephemeral agent tasks) to solve this. My approach (Tenuo) works like this: 1. Runtime Enforcement: The agent gets a cryptographically signed 'Warrant' that mechanically limits what the runtime allows. It’s not a 'rule' the LLM follows; it’s a constraint the runtime enforces (e.g., fs:read is only valid for /tmp/*). 2. Attenuation: As the agent creates sub-tasks, it can only delegate less authority than it holds. 3. Offline Verify: I wrote the core in Rust so I can verify these tokens in ~27µs on every si