Tenuo Denial Triage

Tenuo Denial Triage

A denial is the system working. Find out whether the caller, the policy, or the configuration is wrong, then fix that with the smallest possible increase in authority. Never route around the verifier, and never make a test pass by widening what the agent may do.

Announce at start: "I'm using the tenuo-denial-triage skill to find why this call was denied and the narrowest fix."

Collect the facts before changing anything

1. The exact error. Class or code, message, hint, and the field or tool it names. Keep the text; do not paraphrase it away.
2. The decision point. Which verifier denied: an in-process guard, an MCP server, a gateway, a sidecar, a worker. And which link: root trust, an intermediate warrant, the leaf, the proof-of-possession, or an approval gate.
3. The presented authority, from the SDK's own diagnostics, not from reading code. In Python, why_denied() on the warrant for the exact tool and arguments, diagnose() on the warrant, explain() on the caught error, and info() for configuration. In TypeScript, session.inspect() and tenuo.explain(session, tool, args). In Rust, the Diagnostics helper's explain_denial, why_denied, and explain_authority. From a shell, tenuo inspect and tenuo verify. When the denial happened in another process, start from the receipt: its decision code, action, request hash, and trusted-roots hash say what the verifier saw. Confirm every diagnostic name against the installed package version before relying on it.
4. The call as the verifier saw it. Tool name, every argument after normalization and injection, the holder key that signed, and the timestamp. Argument names and types matter as much as values.

Write a one-screen triage note before editing:

Error:          <class or code>: <message>
Denied check:   tool | constraint(<field>) | unknown field | expiry | PoP | chain | monotonicity | revocation | approval | configuration
Decision point: <component> at <file:line or service>, chain link: <root | intermediate | leaf | PoP>
Presented:      tools=<...> constraints=<...> holder=<key id> expires=<...>
Call:           tool=<...> args=<normalized map> signer=<key id>
Cause:          caller | policy | configuration | expected denial

Classify the denial

An expected denial is finished when you say so. Do not turn it into a change.

Rank the fixes and stop at the first that works

1. Fix the call. Right tool name, right argument names and types, values normalized the way the verifier normalizes them, the proof signed by the leaf holder over the final arguments, a fresh warrant instead of a stale one. If the effect never reads an argument, remove it from the presented call; do not name it in the policy. A value is material when the effect stores, forwards, logs, or acts on it, even if it does not change which effect runs; a material value needs a bounded constraint, never a wildcard. Do not change the effect to consume a value in order to justify naming it.
2. Stay inside the envelope. If the task is narrower than the warrant, narrow the child. If the issuer can mint authority that fits the task, request that warrant. Neither changes any policy.
3. Widen minimally, at the issuer, by naming exactly the new legitimate values. Add the one recipient to the allowed set. Raise a maximum to the number the task needs. Name a newly required argument with the tightest constraint that admits the real values: an exact value, a small set, a bounded range, a path under a root, a URL limited to named domains. Free text the effect keeps gets a regular expression that bounds its length and character set, where the SDK offers one. If it does not, use another supported bounded constraint, such as an exact value or a small allowlist. Keep every material value in the signed and verified arguments. If no supported constraint fits, remove the value from the entire call, including the effect, only when the task permits omission; otherwise stop and report the unsupported requirement. Removing a value only from the presentation leaves the effect consuming unchecked data. Keep the TTL and delegation depth as they were.
4. Last resort, with a written justification in the report: an unconstrained wildcard on a named argument that the call must carry and the effect ignores. Never on a value the effect keeps.