Tenuo Audit

Tenuo Warrant Auditor

Help security engineers and CISOs understand what tenuo warrants authorize, assess blast radius, review delegation chains, and flag security risks — all explained in the access control language they already know.

Announce at start: "I'm using the tenuo-audit skill to review your warrants and assess authorization risk."

How Warrants Map to Familiar Concepts

Warrants are tenuo's authorization primitive — capability tokens with cryptographic delegation chains. If you're coming from traditional access control, here's the translation:

The key difference: warrants carry semantic constraints on arguments (e.g., "files under /data" with path traversal protection), not just action labels. And delegation is monotonically attenuating — each hop in the chain can only narrow permissions, never widen them. This is enforced cryptographically, not by policy.

Flow

Phase 1: Context Discovery

Scan the codebase for tenuo usage:

1. Search for Python and TypeScript usage: import tenuo, from tenuo, @tenuo/core, Warrant, mint_builder, grant_builder, createTenuo, session, narrow, @guard
2. Check for tenuo_cloud imports or tc_ env vars (indicates cloud deployment)
3. Look for warrant serialization patterns (base64 strings, warrant.serialize(), Warrant(...) deserialization)

Phase 2: Persona Check

Ask: "Before we start — are you a developer building agent integrations, a platform engineer setting up infrastructure, or a security engineer reviewing permissions?"

• Security engineer / CISO → continue with this skill
• Developer creating or delegating authority → suggest tenuo-warrant.
• Developer integrating enforcement into an application or tool boundary → suggest tenuo-agent-authorization.
• Developer with a denied call to make work → suggest tenuo-denial-triage.
• Platform engineer → continue, adjusting framing for infrastructure review

Phase 3: Source Selection

Ask: "What would you like to audit?"

• a) A warrant string — they'll paste a base64-encoded warrant for you to decode and explain
• b) Warrants in the codebase — find all mint_builder, grant_builder, GuardBuilder, mint(), grant() calls and analyze them
• c) A delegation chain — multiple warrants showing parent → child relationships
• d) Cloud audit trail ☁️ (Tenuo Cloud only) — connect to tenuo cloud API for issuance receipts, approval history, revocation status

Phase 4: Decode and Analyze

For each warrant found, extract and present:

Structural properties:

• Issuer public key (who created it)
• Holder public key (who can use it)
• Current depth and max_depth
• TTL / expiration time
• Parent hash (chain link to parent warrant)

Authorization surface:

• List of capabilities (tools/actions granted)
• Constraints on each capability's arguments
• Closed-world status (are unconstrained arguments rejected?)

Use the resolved SDK's diagnostics before reconstructing these facts by hand. For the current TypeScript SDK, import the warrant into a trusted verifier, then use session.inspect() for depth, maxDepth, terminal, expiry, canAuthorize, tools, and approval gates. Use tenuo.explain(session, tool, args) for representative calls and per-field satisfaction. These APIs are diagnostic only; they do not replace verification at the effect boundary. For other runtimes, use their equivalent only after verifying it in the installed package.

Phase 5: Plain-Language Explanation

Present what the warrant authorizes in security review format:

🔍 Warrant Analysis

Holder: [key fingerprint or identifier]
Issuer: [key fingerprint or identifier]
Chain depth: 2 of 3 (1 delegation hop remaining)

AUTHORIZED ACTIONS:
  ✓ read_file
    └─ path: Subpath("/data/reports") — traversal protected
       Allowed: /data/reports/*, /data/reports/2024/q4.csv
       Blocked: /data/reports/../../etc/passwd, /data/other/*

  ✓ create_issue
    └─ url: UrlSafe + UrlPattern("https://api.github.com/*")
       Allowed: https://api.github.com/repos/org/repo/issues
       Blocked: http://169.254.169.254/metadata (SSRF), http://internal:8080

DENIED (not in capability set):
  ✗ write_file, delete_file, execute_command, send_email, ...
  ✗ Any tool not explicitly listed above

TEMPORAL:
  ⏱ TTL: 1800s (expires 2026-03-13T15:30:00Z)
  🔗 Delegation: depth 2/3 — can delegate once more, then terminal

BINDING:
  🔒 Proof-of-possession: Required (bearer token risk mitigated)
  📋 Closed-world: Active (unconstrained arguments rejected)

Phase 6: Familiar Framework Mapping

Translate the warrant into equivalent policies the security engineer is used to reviewing:

IAM Policy Equivalent:
{
  "Effect": "Allow",
  "Action": ["s3:GetObject", "github:CreateIssue"],
  "Resource": ["arn:aws:s3:::data/reports/*", "github:repos/*/issues"],
  "Condition": {
    "IpAddress": {"aws:SourceIp": "not-applicable (UrlSafe handles this)"},
    "DateLessThan": {"aws:CurrentTime": "2026-03-13T15:30:00Z"}
  }
}

RBAC Equivalent:
  Role: report-reader-github-issuer
  Namespace: agent-pool
  Bindings: [read_file, create_issue]
  Session limit: 30 minutes

OAuth Equivalent:
  Scopes: files:read:reports, github:issues:write
  Token type: DPoP-bound (not bearer)
  Expires: 1800s
  Refresh: None (warrant is one-use authority chain)

Phase 7: Delegation Chain Verification

For delegation chains (multiple warrants showing parent → child):

Verify invariants I1-I5 statically:

• I1: child.issuer == parent.holder (delegation comes from the right entity)
• I2: child.depth == parent.depth + 1 (depth increments correctly)
• I3: child.expires_at <= parent.expires_at (child can't outlive parent)
• I4: child.capabilities ⊆ parent.capabilities (capabilities only narrow)
• I5: child.parent_hash == SHA256(parent.payload) (chain integrity)

I6 (PoP signature) is a runtime property — it cannot be verified from static warrant inspection. Instead, check whether PoP enforcement is configured in the codebase. If not, flag as HIGH risk.

Visualize attenuation:

Root Warrant (depth 0, max_depth 3)
  ├─ read_file: Subpath("/data")
  ├─ write_file: Subpath("/data")
  ├─ call_api: UrlSafe + UrlPattern("https://*.example.com/*")
  └─ TTL: 3600s

  └─► Orchestrator Warrant (depth 1)    [ATTENUATION: -write_file, narrowed path]
      ├─ read_file: Subpath("/data/reports")
      ├─ call_api: UrlSafe + UrlPattern("https://api.example.com/*")
      └─ TTL: 1800s

      └─► Worker Warrant (depth 2)       [ATTENUATION: -call_api, terminal]
          ├─ read_file: Subpath("/data/reports/2024")
          └─ TTL: 300s (TERMINAL — cannot delegate further)

Flag violations clearly:

• "VIOLATION I3: Child warrant expires at 16:00 but parent expires at 15:30 — child outlives parent"
• "VIOLATION I4: Child has write_file capability but parent does not — privilege escalation"

Phase 8: Risk Assessment

Assess each warrant against this risk framework:

Present findings with severity and remediation:

🔒 Security Assessment

HIGH ⚠️  UrlSafe not applied to "call_api" capability
         Risk: Agent could call internal services or cloud metadata endpoints
         Fix: Add UrlSafe() constraint — All([UrlSafe(), UrlPattern("https://...")])

MEDIUM ⚠️  TTL set to 86400s (24 hours)
           Risk: If compromised, attacker has a full day to exploit
           Fix: Reduce to task duration + buffer (e.g., 1800s for a 15-min task)

LOW ℹ️  Capability "read_file" not narrowed from parent to child
        Note: Both have Subpath("/data") — child could be narrowed to
              Subpath("/data/reports") for tighter least-privilege