Tenuo FAQ
How Tenuo fits into your stack, what changes in your application, and where task-bound authorization adds control.
Before you adopt Tenuo
Tenuo controls the actions agents take through tools and APIs. It checks whether each call belongs to the current task, whether its real arguments stay within the task’s boundaries, and records the decision. It bounds actions rather than trying to control model reasoning.
It complements them. Guardrails guide model behavior, gateways route and filter traffic, and IAM sets the ceiling for a principal. Tenuo makes the task-level decision at action time, inside those existing controls.
See how the layers fit together →The receiving agent gets a child warrant narrowed to its part of the work. It can drop actions, tighten limits, shorten the lifetime, or delegate a smaller grant again, but it cannot recover authority removed by its parent. The signed chain preserves who authorized every handoff.
See how delegation narrows →Approval gates pause only the calls that need human authorization and accept signed approvals bound to that exact request. Warrants normally use short lifetimes; for emergency cancellation, verifiers check signed revocation lists locally without adding a network call to the action path. Tenuo Cloud provides managed approval routing and revocation distribution, with enterprise-ready integrations and service guarantees for production deployments.
At the tool-calling path, immediately before the action executes. The verifier can run in your application, in MCP server middleware, or at a gateway for services you cannot redeploy.
Add a verification check to the tool-calling path and pass the task’s warrant with the call. Tenuo provides framework adapters and middleware, so you do not need to replace your identity system or rewrite your tools.
See the quickstart →The warrant protocol, verification core, and Python and TypeScript SDKs are open source under Apache 2.0. Tenuo Cloud adds managed boundaries, warrant issuance, approval routing, revocation lists, dry runs, and decision evidence while verification remains in your infrastructure.
Explore Tenuo Cloud →Tenuo supports common agent frameworks, MCP servers, application middleware, and gateway-based enforcement. You can begin with one workflow and add integrations without changing the warrant model.
View supported integrations →Agent authorization, explained
Short answers first, with the deeper reasoning available when you want it.
Agent delegation is when one AI agent passes authority to another so the second agent can act on its behalf. The risk is that the boundary does not travel with the task: the downstream agent inherits whatever credential it is given, which is usually far broader than the work requires. Delegation-safe authorization fixes this by making every downstream grant narrower than the one above it, never wider.
Delegation itself is ordinary engineering. A planner hands a sub-task to a researcher. An orchestrator spawns five workers. A coding agent calls a tool that is itself an agent. None of that is the problem.
The problem is what travels with the handoff. In an identity-based system the only thing an agent has to pass down is its credential, and a credential describes who you are, not what this piece of work needs. So the researcher gets the planner’s API key. The worker gets the orchestrator’s service account. Authority that was already too broad at the top of the chain arrives unchanged at the bottom, held by the component with the least context about why it was granted.
Because nothing at the handoff enforces the narrowing. A sub-agent that receives a token can use every permission on that token. If the downstream agent is written by another team, or is a third-party tool, or is assembled at runtime by the model itself, there is no place to put the check.
That is why the blast radius of a single confused agent is usually the union of everything its parents could do, rather than the small slice its task required.
A delegation-safe grant carries the boundary inside it. Each warrant names the actions permitted, the specific resources in scope, the limits that apply and the moment the authority expires. When one agent delegates to another it mints a child warrant from its own, and the format makes widening impossible: the child can drop actions, tighten the resource set, lower a limit or shorten the lifetime, and nothing else.
The resulting property is worth stating plainly. No agent anywhere in the chain can hold authority its parent did not hold. A worker five levels deep cannot reach a record the orchestrator was never allowed to touch, however convinced the model is that it should.
Every attempt writes a signed receipt naming the full chain of authority behind it, including the attempts that were denied. When someone asks why an agent touched a particular record, the answer is a chain of warrants rather than a log line and an inference. How agent audit evidence works →
Task-bound authorization grants authority to a single task rather than to an identity. Instead of giving an agent a standing credential, each task carries a signed warrant naming the actions it may perform, the specific records it may touch, any limits that apply, and when the authority expires. When the task ends the authority is gone, so there is no standing credential left for an agent to find and misuse.
Roles and service accounts were designed for software that does the same thing every day. They answer “who is calling”, and for a payroll job that runs at 2am on the first of the month, who is calling is a good enough proxy for what should be allowed.
An agent does something different every run. The same agent that reconciles two invoices this morning is asked to refund a customer this afternoon. Any role broad enough to cover both is far too broad for either, and the gap between what the role permits and what the task needs is the space a runaway agent operates in.
A warrant is issued for one task before the agent acts: these operations, these records, this spending cap, this many minutes. It is signed, so it cannot be edited by whatever is holding it, and it is bound to the agent presenting it, so a copied warrant is useless elsewhere.
When the task finishes the authority is gone. There is no standing credential sitting in an environment variable for the next agent to find, and no quarterly access review to catch the one that was never revoked. The five properties of a warrant →
In-process, at the call site, immediately before the operation executes. That placement matters more than it sounds. A gateway sees a request that looks legitimate; the call site sees the actual arguments (this record, this amount, this recipient) and can compare them against what the warrant names.
The verifier can run inside your process, so the action does not depend on a network round trip to a central service. If the verifier is not satisfied, the call does not happen and the denial is recorded.
It does not make a model behave. It does not detect a malicious instruction, score intent, or decide whether a plan is sensible. It bounds what the resulting actions can touch, which is the part that can be enforced deterministically, and the part that still holds when the model is wrong. How this compares with guardrails, OAuth scopes and gateways →
You cannot reliably stop a model from being persuaded by an injected instruction, because the instruction and the goal are processed in the same reasoning loop. What you can do is make sure a persuaded agent has nothing dangerous to reach. If authority arrives with the task, names only the records and operations that task needs, expires on its own and is verified outside the model at the point the action executes, then an injected instruction to delete or exfiltrate data is blocked before it reaches the API, and the denial is recorded.
Not reliably, and not for the reason people hope. Prompt injection is not a parsing bug that a better filter will eventually catch. The injected instruction and the agent’s own goal arrive in the same context and are processed by the same reasoning loop, and the model has no dependable way to tell which text deserves authority. Classifiers help at the margin, and every one of them can be worded around.
Treating this as a detection problem also puts the control in the least trustworthy place in the system: inside the model that is the thing being manipulated.
The useful question is not whether an agent can be persuaded but what it can do once it has been. Assume the agent is compromised on every run and ask what the worst call it could make would touch. If the answer is “any customer record” or “any amount”, detection is doing all the work.
With task-bound authority the answer is bounded in advance. The warrant for this task names the three records in scope and the two operations required. An injected instruction to drop a table or mail a dataset outward is not a judgement call the model gets to make: the verifier sees an operation the warrant does not name, and the call never reaches the API.
Yes, and the public cases follow the same shape: a capable agent, a plausible-looking instruction, and one credential lying around that was broader than the task. Read the PocketOS incident, where an agent deleted a production database in nine seconds →
A denial is a signed receipt: which agent, which warrant, what it tried, what was missing. That turns a successful injection from a silent incident into a logged one, which is usually the difference between finding out in an audit and finding out in the news. What the receipt contains →
In a swarm, authority is handed from orchestrator to worker agents many times per task, and identity-based permissions cannot express that chain. Scoping authority to the task and requiring every delegation to narrow means a worker agent can only ever hold a subset of what its parent held. Each attempt, allowed or blocked, writes a signed receipt naming the full authority chain behind it, so the swarm remains auditable.
Fan one task out to twenty workers and the interesting question stops being who they are. Workers are spawned per task, live for seconds, and are often indistinguishable from each other in any way an IAM system can name. Provisioning a non-human identity for each one is not practical, so in most deployments they all share the orchestrator’s.
That single shared credential becomes the whole security model, and it is held by the most numerous, shortest-lived and least supervised parts of the system.
Scope authority to the task and let each hop attenuate. The orchestrator holds a warrant for the job. Each worker receives a child warrant covering only its slice (this shard, this region, this subset of records), minted from the parent and provably narrower than it.
A worker cannot widen its own authority, cannot reach another worker’s slice, and cannot outlive the job it was spawned for. The bound holds however wide the fan-out gets, because it is a property of the format rather than of anyone remembering to configure it.
Every attempt, allowed or blocked, writes a signed receipt naming the full authority chain behind it. So “which worker touched this record, and who authorised it” has an answer that outlives the workers themselves, which a stream of anonymous calls from one shared service account does not. What that evidence looks like →
There is no separate swarm mode. A single agent calling one tool and an orchestrator fanning out to fifty use the same warrants and the same in-process check. A swarm is just a deeper chain.
You prove it with evidence created at the moment of the decision by a verifier outside the model. Every authorization check writes a signed receipt naming the task, the agent holding the authority, the delegation chain behind it, the operation attempted and whether it was allowed. Because the verifier signs the receipt at decision time, it is a tamper-evident authorization record rather than a claim reconstructed later from agent logs.
Three reasons, and they compound. The log is written by the agent, so an agent that was persuaded writes a persuaded log. It is written after the action, so it describes an intention rather than a decision. And it records what succeeded, not what was refused, which means the most interesting events in an agentic system leave no trace at all.
Model traces have the same problem one level up. They tell you what the agent said it was doing. They are not a record of what your systems allowed it to do.
Nothing in that list is reconstructed later, and none of it is authored by the agent it describes.
Rarely a policy document. What gets asked for is evidence that a control operated on a specific date, for a specific action, and that someone could have detected it if it had not. Record-keeping and traceability duties for high-risk AI systems, logical access-control evidence in a SOC 2 audit, and the management and measurement functions of the NIST AI Risk Management Framework all land in the same place: show the decision, not the intention.
A signed receipt per authorization decision answers that directly, and it answers it for actions an agent took autonomously at three in the morning. How this maps to EU AI Act obligations →
An approved action is a system working. A denied action is a signal: an agent attempted something outside the authority its task was given. One denial is a bug in a prompt. A pattern of them is an injection campaign, a mis-scoped workflow, or a model drifting from what you deployed it for.
This is also what makes a dry run useful. Run the verifier in observe-only mode against real traffic and the denials you would have issued tell you what your agents are actually reaching for before you enforce anything.
Non-human identity governance assumes a human owner and a quarterly cadence. Agents create and discard working identities per task, thousands of times a week, which breaks both assumptions at once.
Task-bound authority sidesteps the review rather than scaling it. There is no standing grant to certify, because authority exists only while the task runs and the receipt is the record that it existed at all.
MCP standardises how an agent discovers and calls tools, with authorization support for remote transports. What it does not decide is whether this agent, on this task, may make this particular call with these arguments. You secure an MCP server by verifying a task-bound warrant in the server’s middleware, before the tool function runs, so an out-of-scope call is refused at the tool rather than at the model.
MCP gives you a common way to expose tools and a transport that can be authenticated. Authentication answers who connected. It does not answer whether the caller should be allowed to delete this record, refund this order, or read this directory, because that answer depends on the task the agent is currently performing, which the protocol has no view of.
In practice most MCP deployments end up with a server that trusts any connected client to call any registered tool with any arguments. That is a reasonable default for a local developer tool and a poor one for anything touching production.
In middleware on the MCP server, in front of the tool functions. The server is the last place that sees the real arguments before the operation runs, and it is the one component both the agent and the tool owner have to trust.
A verifier there checks the warrant the caller presented: is it signed by a trusted issuer, is it bound to this caller, does it name this tool, do the arguments satisfy its constraints, and has it expired. If any of that fails, the tool never executes.
from fastmcp import FastMCP
from tenuo.mcp import MCPVerifier, TenuoMiddleware
verifier = MCPVerifier(authorizer=authorizer,
require_warrant=True)
mcp = FastMCP("demo", middleware=[TenuoMiddleware(verifier)])
@mcp.tool()
async def read_file(path: str) -> str:
return open(path).read()
A gateway sees a well-formed request from an authenticated client. The middleware sees read_file(path="/etc/passwd") and can compare that path against the subpath the warrant actually names. Argument-level constraints are where agent authorization lives, and they are mostly invisible at the edge.
A gateway is still useful for tools you do not own or cannot redeploy. It is a coarser net, not a substitute.
This is where task-bound authority pays for itself. One warrant is issued for the task; each server receives a child warrant narrowed to the tools it exposes, and each verifies independently and offline against the issuer’s public key. No server needs to call back to a central authority, and no server can be talked into honouring authority that its parent never held. How this behaves across a swarm →
Task-bound authorization adds the layer those controls do not express: what this agent may do for this task, with these arguments, right now. Guardrails guide behavior, OAuth and IAM establish identity and broad access, and gateways enforce traffic policy. Tenuo works within those layers to narrow authority at each delegation and record a signed decision when an action is attempted.
| Control | What it covers | What it does not decide |
|---|---|---|
| System prompt rules | Steering behaviour cheaply, in one place | Lives in the same reasoning loop as the attack, so it competes with the goal instead of constraining it |
| Output guardrails and classifiers | Catching known-bad patterns and obvious exfiltration | Probabilistic, and judged on text rather than on the action that follows it |
| Human in the loop | High-consequence, low-volume decisions | Does not survive scale; approval fatigue turns review into rubber-stamping |
| OAuth scopes, JIT credentials | Time-boxing access to an API surface | A scope names an API, not a record. It cannot say “this invoice only”, and it cannot narrow when delegated |
| IAM and RBAC | Setting the ceiling for a principal | Answers what a principal may do at most, never what this task needs right now |
| API gateway or proxy | Enforcing traffic policy and protecting services you cannot change | Usually lacks the task context needed to decide whether the specific action belongs to the current job |
| Sandboxing and isolation | Containing filesystem and process damage | The dangerous calls in an agent system are authorised API calls, which a sandbox passes straight through |
| Macaroons, Biscuit | Offline attenuation of a bearer token | General-purpose capability tokens: no task provenance, no holder binding by default, no agent-framework integration, no receipts |
| Task-bound authorization (Tenuo) | Binding authority to one task, checked against real arguments at the call site, narrowing at every delegation, signed evidence per decision | Governs calls that route through the checker; it bounds actions rather than reasoning |
A scope is a noun about an API: invoices.write. A task is a sentence about the world: refund this order, up to this amount, in the next thirty minutes. The gap between those two is every other invoice in the system.
Short-lived tokens narrow the time dimension, which genuinely helps, and leave the other three (which actions, which records, which limits) as wide as the API surface. A token also cannot be handed to a sub-agent in a narrower form: whoever holds it holds all of it. A warrant can only be passed on narrower than it arrived. Why that matters at every handoff →
LLM guardrails typically inspect model inputs and outputs, and they answer probabilistically. Authorization checks the action and its real arguments at the point of execution, and answers deterministically. Only the second kind produces a guarantee you can put in front of an auditor.
That is not an argument for running agents without guardrails. It is an argument about which layer carries the load. A classifier that is wrong once in a thousand calls is a useful filter and a poor boundary; at agent volumes, once in a thousand happens every day. Why detection cannot close the prompt-injection gap →
Macaroons introduced the idea that a bearer token can be attenuated offline by adding caveats, and Biscuit carried it forward with public-key verification and a datalog policy language. The primitive is right, and Tenuo builds on that lineage rather than pretending to have invented it.
What a general-purpose capability token leaves unsolved is everything specific to agents: binding the credential to its holder so a stolen one is worthless, naming the task it was issued for so a record means something afterwards, integrating with the frameworks agents are actually written in, and emitting signed evidence at every decision. Tenuo ships all four. The five properties of a warrant →
Every other control on this page covers one of those at best. What the evidence looks like → Run it against your own agent →
Deeper reading
Ask us directly, or skip the conversation and run it yourself.