Just-in-Time Secrets Issuance Governance requires that AI agents receive secrets — API keys, database credentials, tokens, certificates, signing keys, and any other authentication or authorisation artefact — only for the minimum duration and minimum scope required to complete a specific task, and that those secrets are automatically revoked when the task completes or the time window expires. Agents do not hold long-lived credentials. They request scoped, time-bounded secrets from a secrets broker at the point of need, and those secrets cease to function when the need ends. The principle is simple: an agent that does not hold a secret cannot leak it, and a secret that has expired cannot be exploited. Without just-in-time issuance, agents accumulate long-lived credentials that persist in memory, configuration files, environment variables, and logs — creating a persistent attack surface that grows with every integration and every deployment.
Scenario A — Long-Lived API Key Exfiltrated Through Log Aggregation: An AI agent for automated reporting uses a static API key to access a financial data provider. The key is stored as an environment variable and has been unchanged for 14 months. The agent's debug logs, which include HTTP request headers, are shipped to a centralised logging platform. The API key appears in 2.3 million log entries. A contractor with access to the logging platform copies the key and uses it to download 6 months of proprietary financial data for a competing firm. The data provider detects the anomalous access pattern 3 weeks later and revokes the key, but by then 890 GB of financial data has been exfiltrated.
What went wrong: The API key was long-lived (14 months without rotation), broadly scoped (full read access to all data products), and present in logs (2.3 million entries). A just-in-time issued credential with a 15-minute TTL, scoped to only the specific data products needed for the current report, would have limited the exposure window to minutes and the data scope to the specific report's requirements. Consequence: 890 GB proprietary data exfiltration, data provider contract termination with £340,000 penalty, FCA investigation for inadequate information security, criminal prosecution of the contractor.
Scenario B — Stolen Database Credential Enables Lateral Movement: An enterprise deploys 12 AI agents across different business functions. All agents use the same database service account with full read-write access because "it's easier to manage one account." The credential is stored in a shared configuration repository. An attacker compromises one agent's container through a dependency vulnerability and extracts the database credential from the environment. Because the credential is shared and long-lived, the attacker now has read-write access to every database table accessible to any of the 12 agents — spanning customer data, financial records, HR data, and operational systems. The attacker exfiltrates 4.7 million customer records before detection.
What went wrong: A single, shared, long-lived credential gave every agent (and any attacker who compromised any agent) access to every database table. Just-in-time issuance would have ensured each agent received a unique, time-limited, task-scoped credential — the compromised agent's credential would access only its assigned tables and would expire within minutes. Consequence: 4.7 million customer record breach, ICO fine of £8.2 million, 18-month remediation programme, CEO and CTO departures.
Scenario C — Expired Task Credential Prevents Post-Task Exploitation: An AI agent receives a just-in-time database credential with a 10-minute TTL to generate a monthly compliance report. The agent completes the report in 7 minutes. Three minutes later, the credential expires. Two hours later, an attacker compromises the agent's container and attempts to use the credential to access the database. The credential is invalid — the connection attempt fails. The attacker finds no other valid credentials in the agent's environment.
What went right: The just-in-time credential expired after the task completed. The attacker's 2-hour-delayed compromise found no exploitable credentials. The agent's environment contained no long-lived secrets. This is the intended outcome of AG-304.
Scope: This dimension applies to every AI agent that authenticates to any system, service, database, API, or resource using any form of credential, key, token, certificate, or secret. This includes: database connection credentials, API keys for external and internal services, OAuth tokens, service account keys, TLS client certificates, signing keys, encryption keys, SSH keys, and any other artefact that grants access to a protected resource. The dimension applies regardless of whether the credential is used for read access, write access, or administrative access. Agents that do not authenticate to any external resource (fully self-contained agents with no network or storage access) are excluded.
4.1. A conforming system MUST issue secrets to agents on demand for specific tasks, with each secret scoped to the minimum permissions required for that task and no broader.
4.2. A conforming system MUST enforce a maximum time-to-live (TTL) on every secret issued to an agent, after which the secret is automatically revoked regardless of whether the task has completed.
4.3. A conforming system MUST revoke secrets immediately upon task completion, even if the TTL has not yet expired.
4.4. A conforming system MUST ensure that agents do not store secrets in persistent locations — secrets exist only in volatile memory for the duration of the task and are purged on task completion or secret revocation.
4.5. A conforming system MUST issue unique secrets per agent per task — no secret is shared across agents or reused across tasks.
4.6. A conforming system SHOULD implement a secrets broker that mediates all secret issuance, enforcing scope, TTL, and uniqueness policies centrally.
4.7. A conforming system SHOULD implement secret usage auditing that tracks which secrets were issued to which agents, when they were used, what resources they accessed, and when they were revoked.
4.8. A conforming system SHOULD implement automatic detection and alerting for secrets that appear in logs, configuration files, source code, or any location outside the designated volatile memory.
4.9. A conforming system MAY implement secret rotation mid-task for long-running tasks, replacing the active secret with a new one without interrupting the task.
Secrets management is one of the most consistently underestimated risks in AI agent deployments. The default pattern — store credentials in environment variables, configuration files, or secret management systems and provide them to agents at deployment time — creates a static attack surface that persists for the lifetime of the credential. A leaked credential is exploitable until it is rotated, which may be months or years.
AI agents amplify the secrets risk because of their operational pattern. Agents interact with numerous external services as part of normal operations: databases, APIs, email services, payment processors, cloud services, and internal systems. Each integration requires credentials. An agent with 8 integrations holds 8 credentials, each of which is a potential exfiltration target. The agent's runtime environment — its container, its logs, its configuration — becomes a repository of secrets that an attacker who compromises any part of the environment can harvest.
Just-in-time issuance eliminates the persistent credential problem. Instead of the agent holding credentials continuously, the agent requests a credential from a secrets broker when it needs to perform a specific task. The broker issues a credential that is scoped to the minimum permissions for that task and has a short TTL (typically 5-30 minutes). When the task completes, the credential is revoked. The agent's runtime environment holds no valid credentials between tasks.
The security benefit is threefold: the time window for credential exploitation is reduced from months to minutes; the scope of any compromised credential is limited to one task's permissions; and the absence of persistent credentials in the agent's environment means that a compromise of the agent between tasks yields no exploitable secrets.
Just-in-time secrets issuance requires a secrets broker (such as HashiCorp Vault, AWS Secrets Manager with dynamic credentials, Azure Key Vault with managed identities, or CyberArk Conjur), an agent-side integration that requests secrets on demand, and policies that define scope and TTL for each secret type.
Recommended patterns:
sales_summary table with a 10-minute TTL; the broker creates a database user agent-report-a3f7x with SELECT on sales_summary, TTL 600 seconds.read:all write:all and a 1-year expiry, issue a token with read:invoices and a 15-minute expiry. The agent requests a new token for each task. The OAuth provider's token endpoint acts as the secrets broker.Anti-patterns to avoid:
Financial Services. PCI DSS Requirement 8.6.3 requires that service account credentials for applications and systems are managed and changed periodically. Just-in-time issuance exceeds this requirement by eliminating persistent credentials entirely. For trading systems, credential TTLs should align with trading session boundaries.
Healthcare. HIPAA §164.312(d) requires person or entity authentication. Just-in-time secrets issuance implements this by ensuring that each agent-task combination is uniquely authenticated through a task-specific credential, providing precise attribution for every access to ePHI.
Government. NIST SP 800-63B provides authentication assurance levels. Just-in-time secrets issuance with short TTLs, unique credentials, and task-scoped permissions aligns with AAL2 requirements for multi-factor cryptographic authentication of automated processes.
Basic Implementation — Secrets are stored in a secret management system (e.g., vault) rather than in code, configuration files, or environment variables. Agents retrieve secrets from the vault at startup. Secrets are rotated on a defined schedule (e.g., every 90 days). Agent-specific service accounts exist (no shared credentials across agents). Limitations: secrets are long-lived between rotations; secrets persist in agent memory for the lifetime of the process; no task-level scoping.
Intermediate Implementation — Secrets are dynamically generated per agent per task with scoped permissions and short TTLs (5-30 minutes). A secrets broker mediates all secret issuance. Secrets are revoked on task completion. Secret usage is audited with full attribution. Secret leak detection scans logs and configurations. Agents handle secrets in volatile memory only.
Advanced Implementation — All intermediate capabilities plus: secrets issuance and revocation has been verified through independent adversarial testing including credential extraction from compromised containers, log mining, and post-task replay attacks. Mid-task secret rotation replaces credentials during long-running tasks. Zero-standing-privileges model — agents hold no valid credentials when idle. Hardware security modules protect the secrets broker's master keys. The organisation can demonstrate that a compromised agent environment yields no exploitable credentials.
Required artefacts:
Retention requirements:
Access requirements:
Test 8.1: Secret TTL Enforcement
Test 8.2: Task-Completion Revocation
Test 8.3: Scope Constraint Enforcement
Test 8.4: Secret Uniqueness Per Agent Per Task
Test 8.5: Secret Absence From Persistent Storage
Test 8.6: Compromised Environment Credential Extraction
Test 8.7: Secret Leak Detection
| Regulation | Provision | Relationship Type |
|---|---|---|
| PCI DSS | Requirement 8.6.3 (Service Account Credential Management) | Direct requirement |
| NIST SP 800-53 | IA-5 (Authenticator Management), SC-12 (Cryptographic Key Establishment) | Direct requirement |
| HIPAA | §164.312(d) (Person or Entity Authentication) | Direct requirement |
| EU AI Act | Article 15 (Accuracy, Robustness, Cybersecurity) | Supports compliance |
| ISO 27001 | A.9.2.4 (Management of Secret Authentication Information) | Direct requirement |
| DORA | Article 9 (ICT Risk Management Framework) | Supports compliance |
| FCA SYSC | 6.1.1R (Systems and Controls) | Supports compliance |
| SOX | Section 404 (Internal Controls Over Financial Reporting) | Supports compliance |
PCI DSS 8.6.3 requires that passwords/passphrases for application and system accounts are managed, changed periodically, and have complexity appropriate to how frequently they change. Just-in-time secrets issuance exceeds this requirement by replacing periodic rotation with per-task credential generation and automatic revocation. A credential with a 15-minute TTL that is unique to each task provides stronger security than a credential rotated every 90 days.
IA-5 requires organisations to manage information system authenticators by establishing initial authenticator content, administrative procedures for distribution, storage, and revocation. Just-in-time issuance implements IA-5 comprehensively: initial content is dynamically generated, distribution is through a secure broker channel, storage is volatile memory only, and revocation is automatic on task completion or TTL expiry. The control enhancement IA-5(2) (PKI-Based Authentication) maps to the ephemeral TLS certificate pattern.
A.9.2.4 requires that the allocation of secret authentication information is controlled through a formal management process. The secrets broker, with its policies for scope, TTL, and uniqueness, implements this formal management process. The audit log of all secret issuance and revocation provides the evidence trail for demonstrating controlled allocation.
The HIPAA Security Rule requires covered entities to implement procedures to verify that a person or entity seeking access to ePHI is the one claimed. Just-in-time issuance with unique, task-scoped credentials ensures that each agent-task combination is uniquely authenticated, providing precise attribution for every access to ePHI and preventing credential sharing that would undermine authentication assurance.
| Field | Value |
|---|---|
| Severity Rating | High |
| Blast Radius | Credential scope — limited to the resources accessible through the compromised credential, which under just-in-time issuance is bounded to a single task's scope |
Consequence chain: When just-in-time issuance is not implemented and agents hold long-lived, broadly scoped credentials, the failure severity escalates to Critical. A compromised long-lived credential grants persistent access to all resources in the credential's scope — potentially spanning databases, APIs, cloud services, and internal systems. The attacker can exploit the credential at any time until it is manually rotated, which may take weeks or months. The blast radius is the union of all resources accessible through the credential. For shared credentials, this includes all resources accessible to all agents sharing that credential. The consequence includes data exfiltration at the credential's full access scope, unauthorised actions using the credential's write permissions, and lateral movement to systems that trust the compromised credential. When just-in-time issuance is properly implemented, the blast radius of a credential compromise is limited to one task's scope and one TTL's duration — transforming a potentially catastrophic incident into a bounded, manageable event.
Cross-references: AG-162 (Least-Agency Provisioning) establishes the principle that agents receive only minimum required access — just-in-time issuance operationalises this at the credential level. AG-302 (Production Write Isolation Governance) relies on just-in-time issuance for production write credentials. AG-305 (Privileged Session Recording Governance) captures activity during just-in-time privileged sessions. AG-306 (Break-Glass Containment Governance) provides emergency access that complements just-in-time issuance for exceptional circumstances. AG-299 (Workspace Segmentation Governance) defines the workspace scope within which just-in-time credentials operate. AG-013 (Data Sensitivity and Exfiltration Prevention) benefits from just-in-time issuance by reducing the window for credential-based data exfiltration.