Tenuo Warrant

Tenuo Warrant Creator

Help developers create tenuo warrants by translating natural language intent into capability tokens with the right constraints. Warrants are a new authorization primitive — most developers haven't seen them before — so this skill bridges the gap between "I want my agent to do X" and the actual warrant code.

Announce at start: "I'm using the tenuo-warrant skill to help you create a warrant for your agent."

The Core Idea

A warrant is like an API key that can only get weaker. Once created, it can be delegated to sub-agents with fewer permissions (attenuation), but never more. Think of it as a capability token with built-in least-privilege enforcement.

For developers familiar with other auth systems:

• OAuth: Warrants are like scopes, but scopes are static strings — warrants carry semantic constraints (e.g., "files under /data" not just "files:read")
• IAM: Warrants are like IAM policies attached to a session token, but they're cryptographically chained so each delegation provably narrows scope
• RBAC: Instead of roles with fixed permissions, warrants carry exactly the permissions needed, bound to a specific agent and expiration

Flow

Phase 1: Discover Context

Before asking questions, scan the codebase:

1. Check for existing tenuo usage — search Python and TypeScript manifests and sources for import tenuo, from tenuo, @tenuo/core, tenuo_cloud, Warrant, SigningKey, createTenuo, session, and narrow
2. Detect the installed SDK and version — inspect manifests, lockfiles, and existing warrant construction before choosing minting or delegation APIs
3. Check for tenuo-cloud — look for tenuo_cloud imports, tc_ prefixed env vars, or AsyncTenuoCloudClient

This tells you which warrant source and resolved SDK surface to use. Do not generate application or tool-boundary enforcement from this skill.

Route by the detected runtime. For TypeScript, read references/typescript.md and use TypeScript names throughout; never make the developer translate Python builders or vocabulary. For Python, verify the installed Python API before using the examples below.

Phase 2: Persona Check

Infer persona from context first — if the codebase scan, the user's language, or a prior message makes it obvious, skip the question. Only ask if genuinely ambiguous:

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

• Developer → continue only for warrant design, minting, or delegation. For application or tool-boundary enforcement, hand off to tenuo-agent-authorization. For a call that is being denied under an existing warrant, hand off to tenuo-denial-triage.
• Security engineer → suggest /tenuo-audit instead ("That skill is designed for reviewing and explaining existing warrants — it'll frame everything in IAM/RBAC terms you're used to")
• Platform engineer → continue, but note the sidecar + policy file workflow is coming soon. For now, help them create warrants via the SDK

Phase 3: Natural Language Intake

Ask the developer to describe what their agent needs to do in plain language. Encourage them to be specific about:

• What tools/actions the agent needs for this specific task (not what it might ever need)
• What data or systems it accesses
• Any boundaries (file paths, URLs, environments)
• How long it should be valid

Example prompt: "Describe what your agent needs to be authorized to do. Be as specific as you can — for example: 'My agent needs to read files under /data/reports, call the GitHub API to create issues, and run for at most 30 minutes.'"

TTL guidance: Always ask about task duration and push for the shortest plausible TTL. If the user gives a long TTL (> 1 hour), push back:

"You said 24 hours — that means if this warrant or key is compromised, it's valid for a full day with no revocation path (open-source) or until manually added to the SRL (cloud). Could this task complete in 15–30 minutes? A short TTL with re-issuance is safer than a long-lived credential."

Default to task-duration + a small buffer (e.g., 5 minutes for a 2-minute task). Only accept long TTLs if the user explicitly understands the trade-off.

Phase 4: Draft the Warrant

Take the natural language description and produce a draft warrant spec. Apply Principle of Least Authority (POLA) throughout: every capability and constraint should reflect what the agent needs for this specific task, not what it might ever need. If a capability is mentioned but not clearly required for the stated task, challenge it:

"You listed delete_file — do you need that for this task, or is it something the agent might use in other contexts? It's easy to add later; it's hard to narrow once it's in use."

For each capability and constraint, explain what you chose and why using this mapping:

Present the draft like this:

Here's what I'm proposing for your warrant:

📋 Capabilities:
  • read_file — with path constrained to Subpath("/data/reports")
    "Your agent can read any file under /data/reports, but path traversal
     attacks are blocked. ../../etc/passwd → denied."

  • create_issue — with url constrained to All([UrlSafe(), UrlPattern("https://api.github.com/*")])
    "Can call GitHub's API, but SSRF is blocked — no reaching internal
     services or cloud metadata endpoints."

⏱ TTL: 1800 seconds (30 minutes)
🔗 Max delegation depth: 3 (agent → sub-agent → sub-sub-agent)

Phase 5: Validate Each Mapping

Walk through each constraint and ask for confirmation:

"I interpreted 'read files under /data/reports' as a Subpath("/data/reports") constraint. This means:

• ✅ /data/reports/q4.csv — allowed
• ✅ /data/reports/2024/summary.txt — allowed
• ❌ /data/reports/../../etc/passwd — blocked (traversal)
• ❌ /data/other/file.txt — blocked (outside scope)

Does that match what you intended?"

Fill gaps with targeted questions:

• "You mentioned API access — should the agent be able to write (POST/PUT) or just read (GET)?"
• "Should the agent be able to delegate this warrant to sub-agents? If so, how deep?"
• "Any time limit on how long this authorization should last?"

Safety check — always verify: Any capability that involves network access (fetching URLs, calling APIs, web search, webhooks) MUST have UrlSafe() applied, even if no specific URL pattern is needed. This prevents SSRF attacks where the agent could reach internal services, cloud metadata endpoints (169.254.169.254), or localhost. If a network-facing capability is missing UrlSafe(), flag it and add it. This is the single most common constraint omission.

Phase 6: Explain the Full Warrant

Present a complete plain-language summary:

📋 Warrant Summary

This warrant authorizes the holder to:
  ✓ Read files under /data/reports (path traversal protected)
  ✓ Call https://api.github.com/* (SSRF protected)
  ✗ Cannot write files
  ✗ Cannot access any other network endpoints
  ✗ Cannot delegate beyond depth 3

⏱ Expires in 30 minutes
🔒 Proof-of-possession required (warrant is useless without the holder's private key)

Blast radius (if compromised):
  An attacker with this warrant could read files under /data/reports
  and create GitHub issues. They cannot write to the filesystem, access
  other APIs, or escalate privileges. The warrant expires in 30 minutes
  and requires the private key to use.

In familiar terms:
  • IAM: Allow s3:GetObject on arn:aws:s3:::data/reports/*,
         Allow execute-api:Invoke on github-api/issues/*
  • OAuth: Scopes: files:read:reports, github:issues:write. Expires: 1800s
  • RBAC: Role: report-reader-github-issuer, Namespace: agent-pool