Related Work
How does Tenuo fit into the broader AI agent security landscape?
CaMeL
Paper: Defeating Prompt Injections by Design (Debenedetti et al., 2025)
CaMeL introduces a protective system layer around LLMs that secures agentic systems against prompt injection. Key ideas:
- Capability tokens: Explicit authorization for tool invocations
- Control/data flow separation: Untrusted data cannot impact program flow
- P-LLM / Q-LLM architecture: Privileged planner issues tokens to worker LLMs
Tenuo implements CaMeL’s capability token model:
| CaMeL Concept | Tenuo Implementation |
|---|---|
| Capability tokens | Warrants |
| Interpreter checks | Authorizer |
| P-LLM issues tokens | Root warrant (or issuer warrants) |
| Q-LLM holds tokens | Execution warrants |
| Token attenuation | Monotonic constraint narrowing |
CaMeL is the architecture. Tenuo is the authorization primitive.
Microsoft FIDES
Paper: Securing AI Agents with Information-Flow Control (Costa et al., 2025)
FIDES uses information-flow control (IFC) to track data provenance through agent execution:
- Taint tracking: Labels data with confidentiality/integrity levels
- Policy enforcement: Prevents unauthorized data flows
- Selective hiding: Primitives for controlling information visibility
Tenuo and FIDES solve different problems:
| Concern | Solution |
|---|---|
“Can this agent read /etc/passwd?” |
Tenuo (action control) |
“Did /etc/passwd contents leak to output?” |
FIDES (data flow) |
Tenuo tracks action flow (what operations are authorized).
FIDES tracks data flow (what information goes where).
Complementary Approaches
A complete defense may use both:
┌─────────────────────────────────────────────────────────────────┐
│ Agent System │
│ │
│ ┌─────────────┐ ┌─────────────────────┐ │
│ │ FIDES │ │ Tenuo │ │
│ │ │ │ │ │
│ │ "Is this │ │ "Is this agent │ │
│ │ data │ ───────────────────▶│ allowed to call │ │
│ │ tainted?" │ │ this tool with │ │
│ │ │ │ these args?" │ │
│ └─────────────┘ └─────────────────────┘ │
│ │ │ │
│ ▼ ▼ │
│ Data flow policy Action authorization │
│ (confidentiality) (capability tokens) │
└─────────────────────────────────────────────────────────────────┘
Example combined flow:
- Agent reads file → FIDES labels data as
confidential:internal - Agent wants to send email → Tenuo checks warrant allows
send_email - FIDES checks: can
confidential:internaldata flow to email recipient? - Both must approve for action to proceed
Key Differences
| Aspect | Tenuo | FIDES |
|---|---|---|
| Focus | Authorization (who can do what) | Information flow (where data goes) |
| Model | Capability tokens (warrants) | Taint labels (confidentiality/integrity) |
| Enforcement | Tool invocation time | Data propagation time |
| Scope | Per-task authority | Per-data-item provenance |
| Overhead | ~27μs verification | Depends on taint propagation |
Authority Separation
Paper: Authority Separation in AI Systems (Shamim, 2025)
This paper provides empirical validation of the architectural pattern Tenuo implements. Key findings across 1,000 adversarial test cases:
| Metric | Authority Separation | Baseline (Prompt-Governed) |
|---|---|---|
| Unauthorized tool invocations | 0% | 23% |
| Unsupported factual claims | 0% | 12% |
| Unnecessary execution cost | -78% | baseline |
| Catastrophic action recurrence | 0 | 4.3 mean repetitions |
Core thesis: Prompt injection, hallucination, and repeated failures are manifestations of a single architectural flaw—coupling generation with execution authority. Separating these concerns provides structural guarantees that persist under adversarial conditions.
Tenuo implements this separation: models propose actions, the authorizer enforces constraints.
Prior Art
Tenuo builds on established capability-based authorization patterns:
| System | Contribution | Tenuo Difference |
|---|---|---|
| Macaroons (Google, 2014) | Contextual caveats, attenuation | Tenuo adds PoP binding, AI-specific constraints |
| Biscuit (Clever Cloud, 2019) | Offline attenuation, Datalog authorization | Tenuo uses simpler constraint predicates |
| UCAN (Fission, 2021) | Decentralized capability chains | Tenuo focused on centralized control plane model |
Why Not Just Use Biscuit?
Biscuit is excellent. Both Tenuo and Biscuit support offline attenuation with similar mechanisms. Tenuo differs in:
- Threat model — Designed specifically for AI agents processing untrusted input
- PoP binding — Mandatory proof-of-possession (Biscuit has optional third-party caveats)
- Constraint types — Purpose-built for tool authorization (Pattern, Range, OneOf)
- Authorization model — Closed-form constraint predicates vs Datalog policies
If you need general-purpose capability tokens with flexible policy logic, consider Biscuit.
If you need AI agent authorization with prompt injection defense, use Tenuo.
Industry Approaches
| Vendor | Approach |
|---|---|
| Anthropic | Constitutional AI, RLHF alignment |
| OpenAI | System prompt isolation, function calling constraints |
| Instruction hierarchy |
These focus on model behavior. Tenuo focuses on authorization infrastructure.
The approaches are complementary: model-level defenses reduce the likelihood of malicious intent; Tenuo limits the blast radius when defenses fail.
Prompt Injection Defenses
| Approach | Description | Limitation |
|---|---|---|
| Input filtering | Detect/block malicious prompts | Evasion attacks |
| Output filtering | Detect/block harmful outputs | Post-hoc, reactive |
| Instruction hierarchy | System vs user prompt priority | Model-dependent |
| Capability-based | Limit what actions are possible | ✅ Tenuo’s approach |
Traditional Authorization Mapping
| System | Tenuo Analog |
|---|---|
| OAuth scopes | Warrant constraints |
| RBAC roles | Issuer warrant pools |
| ABAC attributes | CEL expressions |
| Macaroons | Attenuated warrants |
Citation
If you reference Tenuo in academic work:
@software{tenuo2025,
title = {Tenuo: Capability-Based Authorization for AI Agents},
year = {2025},
url = {https://github.com/tenuo-ai/tenuo}
}
See Also
- Concepts — Why Tenuo? Problem/solution overview
- Protocol Specification — How warrants work
- Security — Detailed threat model