API Keys Are Your Agent's Weakest Link

The threat model: three ATT&CK paths into agent keys

When an attacker targets an agent fleet, they don't need to compromise the LLM — they need one leaked .env file. Three MITRE ATT&CK techniques map directly to agent credential exposure:

On the ATLAS side, AML.T0070 (LLM Plugin Compromise) and AML.T0066 (LLM Jailbreak) both list credential exfiltration as a downstream objective — the LLM itself can be coerced to print its own environment variables if the input isn't sandboxed.

Why agent key hygiene is harder than developer key hygiene

A human developer has one laptop. A 40-agent fleet has 40+ active key stores, each potentially holding OpenAI keys, Anthropic keys, database credentials, and third-party API tokens. The surface area scales with the fleet. The hygiene practices rarely do.

Three structural problems specific to autonomous agents:

• No rotation cadence. Agents don't have HR offboarding processes. A key issued in January may still be active in December, unknown to anyone.
• Overly broad scopes. Agent scripts often use admin-level keys because it's easier to provision one key than to scope each agent's access. T1552.001 turns every one of those broad keys into a skeleton key.
• Keys embedded in prompts. The worst case — and it happens — is an agent that has a key hardcoded in its system prompt. A single prompt-injection via AML.T0082 (Supply Chain Compromise via Dependency) exposes it to any content the agent reads.

The four controls that actually work

1. Prefixed keys with 256-bit entropy

Use a recognizable prefix (sk_agent_, bo_live_) with 32 bytes of secrets.token_urlsafe(32) entropy. The prefix enables automated leak detection via gitleaks and GitHub Secret Scanning. Without a prefix, you're hunting for a 32-char random string in your entire codebase — a losing game.

This maps to NIST CSF ID.RA-01 (Asset Risk Identification) and NIST AI RMF MAP-5.1 (map key assets and risks).

2. Hash-only storage — never plaintext

Store only the SHA-256 hash of each key in your database. Show the raw key to the agent exactly once at creation time. If your key table is dumped — T1003 (Credential Dumping) — the attacker gets hashes, not live credentials. This is the single highest-return control; it turns a catastrophic breach into a rotate-and-move-on event.

Reference: NIST AI RMF MEASURE-2.7 (evaluate key security controls), NIST CSF PR.DS-10 (data-in-use protection).

3. Per-agent scoping: least-privilege at the fleet level

Every agent gets its own key, scoped to only the endpoints it needs. A research agent needs read access to the search API. It doesn't need write access to the billing API. Apply the same principle you'd use for IAM roles — but at the per-agent level, not per-service-account.

# Example: scoped key issuance for a research agent
key_metadata = {
    "agent_id": "topic-deep-researcher-01",
    "scopes": ["search:read", "firecrawl:fetch"],
    "rate_limit": {"requests": 500, "window_secs": 3600},
    "ip_allowlist": ["10.0.1.0/24"],  # agent's subnet only
    "expires_at": "2026-09-03T00:00:00Z"
}

This directly counters T1190 — if a public-facing endpoint is compromised, the attacker's blast radius is limited to what that key can do. Scoping aligns with NIST AI RMF MANAGE-2.4 (manage AI system components to reduce risk).

4. Automated rotation + revocation pipeline

Rotate every agent key on a fixed cadence (90 days is the upper bound; 30 days is safer for high-value agents). Wire revocation to your agent lifecycle: when an agent is decommissioned, the key is revoked atomically, not on a manual checklist.

At BlindOracle, key revocation is part of the agent audit and passport lifecycle — an agent whose passport is revoked automatically loses its API access within one rotation cycle. The revocation list is checked on every validate_key() call, not just at issuance.

Detecting leaks before they become incidents

The AML.T0082 (Supply Chain Compromise) vector means your keys can leak through dependencies, not just your own code. Run two secret-scanning passes:

• CI/CD pre-commit: gitleaks with a custom ruleset for your key prefixes. Block the commit, don't just warn.
• GitHub Secret Scanning: Enable it on all repos including private ones. Register your key prefix patterns as a push-protection pattern. GitHub will reject pushes that contain matching strings before they hit the remote.

When a leak is detected, the response must be automatic: validate the leaked string against the key store, revoke immediately, and notify the agent's owner. A 3-minute revocation window is achievable; a 3-day manual process is not. This is NIST CSF DE.CM-01 (continuous monitoring) in practice.

Framework mapping