Tenuo Agent Authorization

Tenuo Agent Authorization

Implement the smallest end-to-end integration that enforces approved authority at the component performing the effect. Prompts and instructions coordinate an agent; they are not authorization.

Locate the boundary

Identify the action-selecting process, the effecting component, every direct or fallback route to the effect, and who issues, holds, and verifies authority.

• An in-process guardrail limits calls reaching a wrapper. It is not an independent boundary when the agent process can bypass it or reach the resource directly.
• Effect-boundary enforcement verifies in a server, gateway, sidecar, worker, or tool host outside the agent's authority before performing the effect.

Tier 1 rejects out-of-policy calls in trusted code, including calls a manipulated prompt induces. Tier 2 keeps those checks and adds signed, holder-bound authority and delegation that can only narrow, which an independent verifier can check. Describe a requested local-policy integration by those checks, as enforcement. Read Integration trust levels. When the agent can skip the guard, identify the effecting component outside the agent's control where enforcement must run. Do not invent a warrant-issuance requirement for a local-policy request.

If an original unguarded application route remains, close it or report the integration as incomplete; a residual-risk disclaimer does not make that route protected. Read Architectural patterns only when the enforcement location is undecided or the task changes deployment topology.

For an MCP integration, run scripts/inspect_mcp_project.py --root ., confirm its findings in source, then read End-to-end MCP integration. Do not add a verifier in isolation: identify how legitimate callers receive holder-bound warrants and send proof with each protected call. If issuance is missing, observation and policy discovery may still be useful, but report that enforcement is incomplete.

For native function, shell, computer-use, or framework tools, run scripts/inspect_native_tools.py --root ., confirm its findings in source, then read Native agent tool integration. Determine whether the framework hook actually runs for every selected tool type; when it does not, enforce in the handler or downstream service that owns the effect.

Resolve the actual API

1. Read manifests and lockfiles to determine the resolved Tenuo version.
2. Inspect that installed package's README, declarations, importable source, and packaged examples. Not every package ships examples.
3. If those artifacts are insufficient, inspect an immutable repository release tag whose package manifest matches the resolved version.
4. Use main only for an unreleased checkout or as an explicit fallback. Never silently mix main examples with a released dependency.
5. Find existing wrappers, authority transport, trust-root configuration, identity, secrets, logs, and effect handlers before editing.

Read exactly the applicable language reference:

• Python integration for tenuo and its framework adapters.
• TypeScript integration for @tenuo/core or @tenuo/mcp.
• Rust integration for the tenuo crate or a Rust enforcement service.

For MCP, also read End-to-end MCP integration. It defines the issuer-to-effect completion gate and reporting levels shared across languages.

For native tools, also read Native agent tool integration. Ordinary application functions count as native tools even without a framework. It covers function-tool dispatch, built-in execution tools, handoffs, and framework hook bypasses.

Read Framework-neutral integration only when no official adapter or verified recipe covers the framework. The linked examples are pinned to the release represented by this skill; use another version's installed API or matching tag rather than adapting them by guesswork.

Implement one vertical slice

1. Name a capability for the effect and constrain every argument that materially changes it.
2. Issue short-lived authority to the holder's public key. The holder creates proof; the verifier-facing API accepts a presentation or public transport data, never a private signing key.
3. Configure trusted roots, verification time, and local policy ceilings independently of request data. A test clock belongs in private test code or trusted verifier construction, not a caller-selectable execution argument.
4. Verify immediately before the effect and execute with the returned or identically normalized verified arguments. Reject values that cannot be represented losslessly in both authorization and effect types; unchecked numeric casts can authorize a different value than the one executed.
5. Fail closed for missing, malformed, expired, untrusted, wrong-holder, wrong-capability, or constraint-violating authority.
6. Make the effect client private to or owned by the enforcement component, or guard every effecting method.

Delegate only when required. Bind the child to its recipient, use the shortest useful TTL, narrow authority when the work is narrower, and make leaf authority terminal. Equal delegation can be valid when it remains within the parent envelope.

API examples belong in normal SDK example directories where CI exercises them. Do not copy Python, TypeScript, or Rust API snippets into this skill.