EVIDENCE TRAIL
Short-lived agent tokens — minutes, not weeks
Verbatim excerpts from the upstream sources cited on the mitigation page, with what each source does and does not prove. The title "short-lived agent tokens" is Helmwart's normalised label for what upstream documents variously call "short-lived credentials," "ephemeral access," "time-bound permissions," and "short-lived by policy." The strongest verbatim upstream match is OWASP Top 10 Agentic 2026 (§ASI03): "Issue short-lived, narrowly scoped tokens per task … to limit blast radius."
Last cross-checked against upstream sources: · 8 sources
References
Each entry shows what the source supports and what it does not prove.
OWASP Top 10 for Agentic Applications 2026
§ASI03 Identity and Privilege Abuse — Prevention and Mitigation Guideline 1 "Enforce Task-Scoped, Time-Bound Permissions"
"Enforce Task-Scoped, Time-Bound Permissions: Issue short-lived, narrowly scoped tokens per task and cap rights with permission boundaries - using per-agent identities and short-lived credentials (e.g., mTLS certificates or scoped tokens) - to limit blast radius, block delegated-abuse and maintenance-window attacks, and mitigate un-scoped inheritance, orphaned privileges, and reflection-loop elevation."
Supports: Verbatim use of "short-lived, narrowly scoped tokens per task" as the canonical token-lifetime control. Directly names per-agent identities and short-lived credentials as the mechanism, and names blast-radius containment as the rationale — matching this control's stated goal.
Does not prove: Frames the control as one item in a privilege-abuse checklist; does not specify concrete TTL values (minutes vs hours) or the renewal architecture.
OWASP Top 10 for Agentic Applications 2026
§ASI02 Tool Misuse and Exploitation — Prevention and Mitigation Guideline 6 "Just-in-Time and Ephemeral Access"
"Just-in-Time and Ephemeral Access. Grant temporary credentials or API tokens that expire immediately after use. Bind keys to specific user sessions to prevent lateral abuse."
Supports: Names JIT / ephemeral credentials as a distinct mitigation pattern for tool-access abuse. "Expire immediately after use" is the strongest OWASP upstream wording for minimal-lifetime tokens.
Does not prove: Scoped to tool-access abuse (ASI02), not to the broader credential-theft / identity-spoofing rationale this control also targets. Does not cover renewal mechanics or fleet-scale jitter.
OWASP Agentic AI — Threats & Mitigations v1.1
§T3 Privilege Compromise / §T9 Identity Spoofing & Impersonation — Playbook Step 1: Implement Secure AI Authentication Mechanisms
"Limit AI credential persistence. Ensure that AI-generated credentials are temporary and expire after short timeframes to reduce exploitation risk."
Supports: Direct instruction to limit credential persistence and enforce short timeframes for AI credentials. Applies to both T3 (privilege compromise) and T9 (identity spoofing) — the two primary threats this control cites.
Does not prove: Does not define "short timeframes" quantitatively. Does not address the renewal path, jitter, or the conditions (disconnected agents, fleet scale) under which short TTL can cause harm.
NIST SP 800-207 — Zero Trust Architecture
§2.1 Tenets of Zero Trust — Tenet 6
"All resource authentication and authorization are dynamic and strictly enforced before access is allowed. This is a constant cycle of obtaining access, scanning and assessing threats, adapting, and continually reevaluating trust in ongoing communication."
Supports: Establishes "dynamic … authentication and authorization" as a foundational ZTA tenet. Short-lived tokens with automated renewal are the canonical implementation of "dynamic" credentials at the identity layer.
Does not prove: Does not name short-lived tokens or TTL values explicitly. The dynamic-auth tenet is in §2.1 (Tenets of Zero Trust), NOT §4.4 (Collaboration Across Enterprise Boundaries) — the MDX cited §4.4, which is a misattribution; the correct section is §2.1 Tenet 6.
OWASP Non-Human Identities Top 10 — NHI7:2025 Long-Lived Secrets
NHI7:2025 — Long-Lived Secrets (description and risk statement)
"Long-lived Secrets refers to the use of sensitive NHIs such as API keys, tokens, encryption keys, and certificates with expiration dates that are too far in the future or that don't expire at all. If a breached secret is long-lived, it provides attackers with access to sensitive services without any time constraints."
Supports: Names the inverse anti-pattern — long-lived secrets — and explains exactly why it is dangerous: no time constraint on attacker access after breach. Short-lived tokens directly remove this constraint.
Does not prove: The source MDX incorrectly cited this risk as "NHI4 (Long-Lived Secrets)." The verified entry is NHI7:2025; NHI4:2025 is "Insecure Authentication" — a different risk. Does not specify token TTL thresholds or renewal patterns.
Red Hat — Zero Trust for Autonomous Agentic AI Systems
Section on Zero Trust token exchange / delegated token exchange in multi-agent hops
"Delegated token exchange: Instead of forwarding the client token to downstream agents or tools, each call must use a scoped token issued specifically for that hop. … Token exchange is defined in OAuth 2.0 Token Exchange (RFC 8693). In this Zero Trust design, it is used not only for downscoping, but to preserve explicit on-behalf-of semantics. … [The exchanged token] is scoped to the new audience and purpose [and] is short-lived by policy."
Supports: Verbatim "short-lived by policy" as the requirement for exchanged tokens in zero-trust agentic architectures. Names RFC 8693 token exchange as the mechanism — matching the Helmwart deployment guidance. Confirms short-lived tokens are "is short-lived by policy" not just recommended.
Does not prove: Scoped to the OAuth/RFC 8693 token-exchange pattern for multi-agent hop credentials; does not cover cloud IAM primitives (STS, Workload Identity, Managed Identity) or the TTL tuning guidance this control also addresses.
MITRE ATLAS AML.M0026 — Privileged AI Agent Permissions Configuration
No verbatim excerpt pulled yet — open the original to verify the cited section.
Supports: Defines the RBAC/ABAC and least-privilege access-control posture for privileged AI agents. Short-lived tokens are one implementation of least-privilege principle — if access expires, the agent cannot maintain elevated permissions beyond task scope.
Does not prove: AML.M0026 does not mention short-lived tokens or TTL values. Its guidance is RBAC, ABAC, and least privilege scoping — adjacent but not equivalent to time-bounding credentials. The MDX implies this mitigation directly supports short-lived tokens; it supports the broader access-control posture only.
MITRE ATLAS AML.M0019 — Control Access to AI Models and Data in Production
AML.M0019 — description
"Require users to verify their identities before accessing a production model. Require authentication for API endpoints and monitor production model queries to ensure compliance with usage policies and to prevent model misuse."
Supports: Establishes authentication as the access-control gate for production AI systems. Short-lived tokens are the credential mechanism that makes per-request authentication practical — a token that expires forces re-authentication.
Does not prove: Does not reference token lifetime, TTL, or short-lived credentials. The connection to this control is inferential: authentication enforcement is necessary but not sufficient to mandate short TTL.