Tenuo Agent Authorization
Cryptographic warrants restrict which tools an agent may call, with which arguments, for one task and every delegated hop.
Per-dimension scores and reasoning
Least privilege is strongly evidenced: signed warrants constrain tool names, arguments, holders, and TTLs; delegation can only narrow authority; and checks fail closed at the execution boundary. Signed human approval is available for sensitive actions, but it is optional and the referenced approval documentation is not supplied, so user_confirmation is reduced. Data flow is unusually explicit: verification is local, the lab identifies the commands that use the network, and sharing is tested for a fixed redacted payload and HTTPS. Key custody, public-key distribution, short TTLs, trust roots, and audit guidance support strong sensitive-data handling. Dependency controls include locked builds, commit-pinned actions in many places, cargo audit, CodeQL, fuzzing, and mutation-test claims, but some actions remain tag-referenced, a curl-to-shell installer is used, and complete dependency/advisory results are absent. External effects are intercepted before execution and may require approval, but confirmation is not universal. No mechanism reverses completed real-world effects or restores application state, so rollback is 0. The license, contributor attribution, prior art, and security contact establish source attribution, while the unverified publisher leaves the responsible legal identity unclear.
The README, security policy, CI, and lab tests describe broad checks across Rust, Python, TypeScript, MCP, Temporal, Docker, operating systems, and dependency versions, together with explicit denial exceptions and user-facing outcomes; none were executed for this review. Material version inconsistencies reduce self_consistency: the README calls v0.2 production/stable, examples and images use 0.3.0, the lab records 0.2.5-beta.0, and SECURITY lists only 0.1.x as supported. Dependency availability is thoroughly addressed through compatibility matrices, prebuilt wheels, locked builds, and platform jobs. Failure behavior includes AuthorizationDenied, MonotonicityError, missing/invalid-warrant explanations, and tested CLI messages, but the supplied files do not document a product-wide error taxonomy or recovery guidance.
The material addresses application developers, platform teams, orchestrators, and learners, with scenarios spanning in-process guards, MCP, gateways, Kubernetes, Temporal, and agent handoffs. Boundaries are exceptionally clear: Tenuo is not a sandbox, prompt technique, LLM filter, or IAM replacement, and application responsibilities are enumerated. Triggering is precise at the real tool-call boundary using the actual arguments, with missing, expired, wrongly signed, or mismatched warrants denied. Python 3.9–3.14, Node 20+, Rust, Linux/macOS/Windows, containers, and numerous frameworks are represented in configuration and CI matrices, justifying full static scores without implying independent execution.
The README has strong information architecture covering installation, quick starts, delegation, deployment choices, requirements, production guidance, Rust usage, contribution, and licensing, plus extensive examples and a guided lab. Limitations and application duties—including lack of sandboxing, path canonicalization, replay handling, node coverage, and TLS—are explicit. The complete Apache-2.0 text is present. Naming is mostly coherent, but inconsistent release numbers and maturity labels across SDKs, images, security support, and the lab prevent full marks. A CHANGELOG is referenced but not supplied, so its migration and release quality cannot be verified. Security email, PGP key, response targets, and contribution paths establish maintenance channels, but the publisher's legal identity and long-term responsibility are not independently clear.
Concrete APIs, deployment patterns, denial behavior, lab feedback, redacted reports, and multiple SDK surfaces make the product's outputs highly usable. Task-scoped, holder-bound, attenuating authorization across delegation hops offers clear marginal value beyond identity- or role-only controls. Cost-benefit is reduced because the sub-50-microsecond claim lacks a supplied benchmark method or result, while operational costs for key management, a control plane, complete wrapper coverage, and integration maintenance are not quantified.
Core claims trace to README examples, security responsibilities and test commands, CI workflows, lab privacy/network tests, and referenced formal-model files. However, several referenced documents, underlying security tests, the CHANGELOG, benchmark evidence, and actual run results are outside the supplied material, so traceability is incomplete. Cross-source corroboration is strong: documentation claims about least privilege, fail-closed behavior, platform coverage, and sharing are echoed by workflows or tests. Fact and inference are often separated through explicit non-goals and application duties, but prompt-injection resistance, production stability, sub-50-microsecond performance, and formal-verification claims are not fully demonstrated in the provided excerpts and retain a promotional or inferential element.
- This is a low-confidence static review only; builds, tests, fuzzing, formal models, and benchmarks were not executed.
- Before production use, reconcile the actual support, compatibility, and upgrade path among versions 0.1, 0.2, 0.2.5-beta.0, and 0.3.0.
- Tenuo authorizes calls but does not isolate processes or roll back business effects; retain sandboxing, TLS, idempotency controls, and application-level compensation.
- Verify complete guard coverage for every tool and graph node, path canonicalization, explicit trust roots, revocation policy, short TTLs, auditing, and secure signing-key storage.
- Validate the sub-50-microsecond, production-stability, and formal-verification claims against revision-pinned models, results, and reproducible benchmarks.
What does this agent do, and when should you use it?
Tenuo is a task-scoped authorization system for AI agents and workflows, comprising a Rust core, Python SDK, beta TypeScript SDK, authorizer sidecar, reference control plane, and framework adapters. An issuer creates a warrant containing allowed tools, argument constraints, a holder public key, and an expiry; the caller presents that warrant with a proof signed by the holder key. Enforcement occurs before execution through Python `@guard`, Rust `Guard`, MCP middleware, an API gateway, or another service boundary, where the full delegation chain and actual arguments are checked. Delegation is subtractive: a child may remove tools, tighten constraints, or expire earlier, but it cannot exceed its parent. The same authorization format can be deployed in-process, at an MCP server, beside an API, in Kubernetes, or within a Temporal workflow, with optional signed authorization receipts. It fits teams that want agents to retain planning freedom while placing cryptographically enforced limits on actions; it is neither a sandbox nor a replacement for IAM.
The issuer uses SigningKey, Capability, and Warrant.mint_builder() to define tool permissions, argument constraints, a holder, and a TTL. Python applications place authority in task scope with configure() and mint() or mint_sync(), while @guard(tool="...") checks a function call before its body runs; the Rust SDK provides the corresponding Runtime, session_from_warrant(), Call, and session.guard() flow. Across an MCP boundary, SecureMCPClient sends the warrant and a proof of possession, while Authorizer, MCPVerifier, and TenuoMiddleware validate it locally using the issuer's trusted public key. The proof covers the warrant, tool name, exact arguments, and a short time window. An orchestrator uses grant_builder() to issue a narrower child warrant; attempts to add tools or widen constraints raise MonotonicityError. The warrant model also supports A2A, HTTP, FastAPI, Temporal, LangChain, LangGraph, CrewAI, AutoGen, Google ADK, and OpenAI integration paths. Enforcement produces an allow or denial before the protected action, and deployments that need evidence can opt into signed authorization receipts.
- A platform team wants an operations agent to scale only
staging-*clusters and never exceed a defined replica ceiling or touch production. - A multi-agent orchestrator delegates work to specialized workers and must prove that authority becomes narrower at every handoff.
- An MCP tool provider wants server-side verification of the requested tool, actual arguments, and caller key possession instead of trusting the model or client.
- An infrastructure team needs one authorization model across FastAPI services, gateways, sidecars, or Kubernetes while retaining local enforcement during control-plane outages.
- A team using Temporal needs task authority to survive queues, retries, and long-running workflow execution.
- A regulated operation needs signed human approval for sensitive actions or signed receipts explaining why a call was allowed or denied.
What are this agent's strengths and limitations?
- Authorization is enforced at the real tool boundary against the tool name and exact arguments, so prompt injection cannot make the protected interface exceed the warrant's scope.
- Delegation is monotonically attenuating: each child can only remove capabilities, tighten constraints, or shorten expiry, and the verifier checks the complete chain.
- Every warrant is holder-bound and each call includes a signed proof of possession, so copying the warrant alone is insufficient to use it.
- Verification is local and network-independent; the source reports checks under 50 microseconds and continued enforcement when the control plane is unavailable.
- One protocol spans Python, Rust, beta TypeScript, MCP, HTTP, A2A, Temporal, gateways, and several agent frameworks, allowing enforcement at different operational boundaries.
- Tenuo is not a sandbox: it authorizes protected calls but does not isolate a process, so containers, virtual machines, or operating-system controls remain necessary.
- Production adoption adds management of signing keys, trusted roots, short TTLs, revocation policy, audit hooks, and mandatory enforcement at every relevant boundary.
- The TypeScript SDK is beta and requires Node.js 20+; several integrations rely on optional Python extras, with MCP and AutoGen requiring Python 3.10+.
- Tenuo Cloud is still in Early Access, and its SDK is explicitly described as a proprietary control-plane client.
- A signed warrant remains valid until its TTL expires even after the local
mint_syncscope ends, making overly long TTLs an exposure risk.
How do you install or deploy this agent?
For Python 3.9-3.14, run uv pip install tenuo or pip install tenuo. Add the integration extra you need, such as uv pip install "tenuo[mcp]", uv pip install "tenuo[fastmcp]", uv pip install "tenuo[openai]", or uv pip install "tenuo[temporal]"; the MCP extras require Python 3.10+. On Node.js 20+, install the beta TypeScript SDK with npm i @tenuo/core@beta. Rust projects can run cargo add tenuo --features sdk; the documented dependency form is tenuo = { version = "0.3.0", features = ["sdk"] }. To run the container demonstration from the repository, use docker compose up; published images include docker pull tenuo/authorizer:0.3.0 and docker pull tenuo/control:0.3.0. The documented Kubernetes command is helm install tenuo-authorizer ./charts/tenuo-authorizer --set config.trustedRoots[0]="YOUR_CONTROL_PLANE_PUBLIC_KEY".
How do you use this agent?
For the smallest Python example, generate a SigningKey, call configure(issuer_key=..., dev_mode=True, audit_log=False), define Capability("scale_cluster", cluster=Pattern("staging-*"), replicas=Range.max_value(10)), and invoke a function decorated with @guard(tool="scale_cluster") inside with mint_sync(authority):. The documented dev_mode=True setting is only for local development. In production, keep signing keys in Vault, AWS Secrets Manager, or GCP Secret Manager; configure the verifier with the control plane's public trusted_roots; disable dry_run; require warrants at every enforcement point; and enable audit callbacks and metrics. An MCP server gives Authorizer(trusted_roots=[issuer_public_key]) to MCPVerifier(require_warrant=True) and TenuoMiddleware, while the caller uses SecureMCPClient(..., inject_warrant=True). Use short TTLs: leaving a mint_sync context removes the warrant from that task's scope but does not revoke the signed warrant before its expiry.
How does this agent compare with similar options?
Traditional IAM primarily establishes identity or role; Tenuo layers on top to constrain what a workload may do for a particular task and time window. Unlike an ordinary bearer token, a warrant is bound to a public key and requires a fresh signed proof with each call. Unlike a centralized runtime policy check, signed authority travels with the request and can be verified at the execution point without a network lookup. The project identifies Macaroons, Biscuit, UCAN, and CaMeL as related or inspirational work, but the supplied material does not establish a comprehensive performance or feature ranking against them.