AVE-2026-00081: Lingering authority -- a task-scoped capability outlives the episode that justified it

[chaksaray]

Candidate record

Proposed ave_id: AVE-2026-00081
Attack class: Persistence - Lingering Authority
Severity: MEDIUM (AIVSS 6.1)

Source

Santos-Grueiro, Igor. "Lingering Authority: Revocable Resource-and-Effect Capabilities for Coding Agents." arXiv:2606.22504, cs.CR, submitted 2026-06-21. Coins the term "lingering authority": a temporary resource/effect capability remains exposed after the episode that justified it has closed. Proposes PORTICO, a reference monitor implementing an explicit request-grant-invoke capability lifecycle. Empirically: a non-revoking baseline permits 10/10 tested post-closure capability reuses and executes 6/6 forbidden effects (file writes, git mutation, network egress) in a deterministic stale-write audit, versus 0/10 and 0/6 under the revoking design.

Why this is a distinct behavioral class (from issue #217, Part 2)

Checked against the two closest existing records by real field comparison, not label similarity:

• AVE-2026-00021 (Human-in-Loop Bypass) and AVE-2026-00063 (Approval Gate Bypass Configuration): both describe actively bypassing a confirmation/approval check at the moment of action (via instruction or config). This candidate involves no bypass of any check -- the grant was legitimately issued and nothing re-checks it when its own justifying condition ends.
• AVE-2026-00045 (Cross-App-Access Escalation): a valid, unexpired grant used outside its scope, within one session, no elapsed time or external event required. This candidate's grant is used within its originally intended purpose, but past the point where a real external, checkable event (episode closure) should have ended it -- the inverse framing (temporal/lifecycle, not scope).
• AVE-2026-00050 (Parasitic Toolchain): an undeclared registration smuggled in beyond manifest scope at session init. This candidate's capability is legitimately declared and granted; the gap is purely a missing closure-triggered revocation.

Part 1 of issue #217 (AVE-2026-00045's own framing) was checked against its real current text and found already precise -- no change needed there.

Framework mappings (verified against primary sources, not corpus precedent)

• owasp_mcp: MCP02 (Privilege Escalation via Scope Creep) -- read the category's full primary-source text (github.com/OWASP/www-project-mcp-top-10, commit 165fe0f78ef104459237b4a8e0f6e78db9b02391). Its detection checklist names 'no enforced expiration for scopes or tokens' verbatim, and its own remediation feat: add 5 new ave records #3 is 'Expiry-Based & Just-in-Time (JIT) Access... require revalidation for long-running or recurring tasks' -- the same gap this class describes.
• owasp_asi: ASI03 (Identity and Privilege Abuse) -- read the actual 2026 PDF (genai.owasp.org) directly, page 15-16. Its own Common Example feat: add new ave rule records #4 is literally 'Time-of-Check to Time-of-Use (TOCTOU) in Agent Workflows: permissions may be validated at the start of a workflow but change or expire before execution' and Example Attack Scenario doc: add new ave records #5 ('Workflow Authorization Drift') describes exactly this mechanism.
• mitre_atlas: checked directly against the live 170+ technique ATLAS.yaml -- no clean fit (AML.T0091.000 Application Access Token is stolen-credential abuse, a different mechanism). Genuine gap, not an unresearched omission.
• nist_ai_rmf: checked the actual NIST AI 100-1 text (Tables 1-4) -- MANAGE-2.4 and GOVERN-1.7 are the closest, but both operate at whole-AI-system deactivation/decommissioning granularity, not per-capability revocation. No clean fit.

Checklist

• Positive + negative conformance fixture
• python3 scripts/validate_records.py
• pytest tests/ -x -q
• Published via node scripts/build-records.js
• README / CHANGELOG updated