Attenu derivation engine — threat model

Status: draft, 2026-08-18. Scope: the derivation engine (attenu-derive) and its trust boundary with the enforcement shim (attenu-guard). Required before P3 (enforce) per the plan of record. Numbers cited are reproducible from the committed corpus and eval gates (see "Evidence").

Attenu derives the minimal enforceable authority for an AI-agent delegation (a task + the tools available + the parent's authority → an attenuated Authority), and the shim enforces it. This document states what an attacker controls, what they can and cannot achieve, and where the residual risk sits. It is written for a security reviewer, not for marketing: every guarantee names its mechanism and its test.

1. Assets

2. Trust boundaries and actors

  UNTRUSTED                          TRUST BOUNDARY                     TRUSTED
  ─────────                          ──────────────                    ───────
  task text  ─────────────┐
  tool outputs ───────────┤   →   [ derivation engine ]   →   Authority proposal
  (a compromised sub-agent)│         L1 templates                     │
                           │         L2 catalog/heuristics            │  meet(parent)
  the acting agent itself ─┘         L3 LLM proposal (untrusted)      ▼
                                     L4 fail-closed              [ shim: enforce ]  →  allow / deny
                                                                      │
                                                                 hash-chained ledger (A2)

• Untrusted by construction: the task text, any tool's output, the acting agent, and — critically — the L3 model proposal. The engine treats all four as attacker-influenced input.
• Trusted: the closed caveat vocabulary, the meet operation, the parent's already-attenuated authority, the catalog/templates as reviewed artifacts, and the shim's enforcement + ledger.
• Out of scope of this document: the host process integrity (if the attacker runs code in the enforcing process, no in-process guard survives — same assumption as any authorization library), key management for the ledger anchor (§7, ADR-14), and the customer's own model/tool supply chain.

3. Attacker model

An attacker who controls the content of a delegated task and the behaviour of a sub-agent — the realistic prompt-injection / compromised-tool scenario. They can write any task text, name any tool or scope, claim any authority, and make the agent attempt any call. They cannot modify the engine's code, the vocabulary, the catalog, or the shim (those are the trusted base).

4. The core invariants (what the attacker cannot do)

I1 — No escalation past the parent. Every proposal is meet(parent_authority, proposal); meet can only intersect, never add. A child is therefore always ⊆ its parent, transitively to the root. An attacker cannot make any agent hold authority its parent did not already hold. Mechanism: Authority.meet (shim), closed vocabulary. Test: escalation_count == 0 is a G1 gate on every release; adversarial suite confirms it on real chains.

I2 — Authority is a function of DECLARED structure, never of task text. The scope set is derived from the agent's role, its declared sub-agent roster, and its tools available — inputs set by the application developer, not by the (attacker-controlled) prompt. Task text may only ever narrow (an explicit "do not write files" tightens the label); it can never add a scope. Mechanism: templates compute scopes from tools_available ∩ role families; the explorer match is robust to task-text verbs; a sub-agent declared no_write never holds write/egress/exec at any layer; delegate scopes come from the declared roster, not from which teammates the task names. Test: T17 injection gate — 24 injection payloads × 3 positions × every real task = 40,464 variants, 0 widened, 0 escalations (CI-gated over committed gold). This invariant was found by the suite: two early widenings (an injected "…send an email…" promoted a read-only sub-agent; a delegate set was read off the prompt) are fixed and pinned.

I3 — Over-reach is denied, and the denial is on the ledger. Any call in a family the node was not granted, any read past its RowLimit, any call past a scoped CallLimit, and any call after the node is revoked, is denied by the shim before the tool body runs. Test: T16 adversarial gate — injected scope/ceiling/lifecycle over-reach on real chains, 100% blocked (scope-class 100%), 0 misses across the corpus.

I4 — Tier-2 authority is never inferred. Payments, mail/egress, deletes and code-exec families are withheld unless a curated catalog entry grants them; a name heuristic can only ever grant tier-0/1 (reads, computation, plain writes). An unknown tool resolves to unknown.<tool> and is granted by no template — fail-closed (L4). Evidence: on out-of-sample public datasets the withheld share is ~2–3% and unresolved ~1–10%, all fail-closed; on the real customer-service app, 2 of 8 calls were correctly held pending curation (mail.send), not silently granted.

I5 — The recorder is a non-channel. The sampling recorder redacts at capture (ADR-05): only derived features leave the process — tool names, scope classes, quantity buckets, argument shapes and salted hashes. No argument value, key, or payload is written to the shipped corpus. Test: property test asserts no raw value/key survives redaction; the corpus row carries no task (hashed), and per-run salts prevent cross-run correlation of hashes.

5. Attack walkthroughs

6. Residual risks (honest)

• R-a: Under-provisioning breaks a benign workflow. The security posture is fail-closed, so the failure mode is denial, not over-grant. Mitigated by shadow-first rollout (would-deny, block nothing) and the benign-deny gate (hold-out ≤ 2%); measured continuously. A new domain's tool that resolves only to a withheld tier-2 family is held pending curation — visible, not silently denied — and the day-0 defaults must surface that state distinctly. Closed at the ledger (2026-08-19, console slice 1): every deny carries a disposition (held_pending_grant · withheld_tier2 · unresolved · out_of_authority) stated by derive.disposition.tool_dispositions() and recorded by the shim; the denial handed to the model carries the same word; undeclared tools land on the ledger as unresolved in every adapter. Tests: shim tests/test_core_v02.py (disposition), tests/test_adapters_contract.py, engine tests/test_disposition.py, tests/test_run_adk_enforce.py.
• R-b: A curated catalog error. Curated entries are trusted; a wrong one (e.g. a genuine payment tool mapped to data.read) would under-restrict. Mitigation: curated entries are the reviewed surface; heuristics — the un-reviewed surface — are structurally barred from tier-2 (I4), so the un-reviewed blast radius is tier-0/1 only.
• R-c: L3 (LLM proposer) is attacker-influenceable. By design it is untrusted: its output passes through meet (cannot escalate) and a circuit breaker falls back to L2/L4. L3 is not yet shipped — on the two customer-domain apps measured, L2 (catalog + heuristics) resolved everything (L4 = 0%), so L3 is deferred until a domain shows real unresolved gaps.
• R-d: Ledger integrity depends on the anchor. The hash-chain is tamper-evident, not tamper-proof: an attacker who can rewrite the whole log and re-hash it defeats detection unless the chain head is anchored out-of-band. Who may revoke, and how the head is anchored, is ADR-14 — to be resolved before a production enforce deployment.
• R-e: Model monoculture in the corpus. Ceilings derived from Haiku-class over-exploration may be looser than a frontier model needs; a small frontier slice is planned to calibrate.

7. Open decisions (pre-P3)

• Ledger anchoring (ADR-14): external anchor for the chain head; the revocation authority model.
• Denial contract + strike policy: uniform machine-readable denial; revoke after N same-scope denials (decided: N=3, per-installation configurable); surface a child's denial to its parent.
• Day-0 "held pending curation" UX: distinct from "denied", with a fast curation path (G4). Ledger half done (disposition, above); the UI half is the console's Decisions queue (slice 1, Plan B).

Evidence (reproducible)

• python -m pytest -q — includes the T17 injection gate and T16 adversarial gate over committed gold.
• python -m attenu_derive.eval.g1 --holdout express --check — escalation 0, benign-deny/unused thresholds.
• python -m attenu_derive.eval.shadow --all — would-be benign blocks vs blocked over-reach on real chains.
• python -m attenu_derive.eval.adversarial --all — per-class block rates.
• python -m attenu_derive.eval.injection --all — widened/escalation counts over every real task.