Protecting Secrets in the Age of Agentic Attacks

· 4 min read

Secure Development Security Threats

Modern defensive patterns for preventing autonomous credential compromise

Agentic attacks have changed the threat landscape. Once an autonomous adversarial system gains access to a credential, it can pivot, escalate, and exfiltrate at machine speed. Traditional “protect secrets at rest” guidance is now a threat.  Organizations must adopt patterns that protect secrets in motion, in memory, and in runtime context.

This is my current strongest guidance for protecting credentials against modern agentic threats.

1. Stop Storing Secrets in Code Repositories

Secrets should never appear in source control, not in config files, not in environment templates, not in CI/CD variables. Instead:

  • Store secrets exclusively in hardened secret safes such as AWS Secrets Manager, Azure Key Vault, Delinea, One Identity Safeguard, CyberArk, or BeyondTrust Password Safe.
  • If a container requires a file on disk, deliver it via a tmpfs mount so the secret never touches persistent storage.
  • If your application requires a file format (PEM, JSON, XML), store the file contents encoded (Base64 or Hex) in the secret manager and reconstruct them at runtime.

This eliminates “secret drift”: the slow leakage of credentials into repos, logs, and build artifacts.

2. Enterprise Grade Secret Storage

Your secret store must support:

  • Automated rotation
  • Fine grained access policies
  • Full auditability
  • Versioning
  • Strong authentication for retrieval

For non‑cloud environments, HashiCorp Vault typically provides the best concurrency and throughput for runtime secret access.

A recommended pattern is to deploy a small mapping service that:

  • Is called by a Human who must provide credentials to synchronize the PAM system credentials to Vault storage
  • Writes non-repudiable audit trail for the synchronization start and complete
  • Accepts secret updates from enterprise PAM systems
  • Pushes them into Vault during scheduled change windows
  • Normalizes naming and metadata across heterogeneous secret sources

This ensures consistent lifecycle management across cloud and on‑prem systems.

3. CI/CD Delivery Pattern for Secrets

To prevent agentic compromise during pipeline execution, model your CI/CD pipeline with the following logic:

  1. Generate a cryptographically strong 32‑byte Data Encryption Key (DEK).
  2. Use AES‑GCM‑256 for encryption.
  3. Retrieve the secret or file from your secret store.
  4. Encrypt immediately upon retrieval never expose plaintext to the job environment.
  5. Concatenate Nonce + Tag + Ciphertext, then encode as Base64 or Hex.  If you are using libraries such as BouncyCastle, ensure that the Tag + Ciphertext concatenation is consistent between CI/CD delivery and runtime decryption.  
  6. Deliver only the encrypted blob to disk or the container filesystem.
  7. Inject the DEK into a small utility that stores the key using local OS protection.

This ensures the CI/CD runner never handles plaintext secrets directly.

4. OS‑Level Secret Protection

Bind secret protection to the local operating system whenever possible with TPM or Secure Enclave backing:

  • Windows: Credential Manager with TPM‑backed user scope
  • macOS: Keychain with user scope
  • Linux: systemd-creds
  • Minified containers: Kernel Keyring (user‑scoped keys)

This prevents agentic systems from trivially scraping memory or filesystem locations.

5. Memory Safety Model

Split responsibilities into two separate processes:

  • Storage process: Receives the DEK and stores it in OS‑protected storage.
  • Runtime process: Retrieves the DEK only when needed and holds it in memory for the shortest possible time.

This minimizes the exposure window for plaintext key material.

6. Option A: Direct DEK Injection

  1. Retrieve the DEK from OS‑protected storage.
  2. Load it into a stack‑allocated byte array (or equivalent).
  3. Use the DEK to decrypt the AES‑GCM payload.
  4. Zero the DEK buffer immediately after use.

This prevents heap persistence and reduces the chance of memory scraping.

7. Option B: Key Wrapper Model

  1. Generate a cryptographically strong 32‑byte Key Input Material (KIM) and store it in OS‑protected storage.
  2. Use the KIM as input to a Key Derivation Function (HKDF or PBKDF2).
  3. Immediately overwrite the KIM after derivation.
  4. Store salts, info fields, and iteration counts separately. Only the KIM is sensitive.
  5. Use the derived key to encrypt the DEK with AES‑GCM‑256 and store the encrypted DEK on disk.
  6. Use the same wrapper to decrypt the DEK at runtime.
  7. Follow Option A’s memory‑zeroing rules.

This ensures the DEK is never stored in plaintext, even inside OS‑protected storage.

8. Final Rule: No Plaintext Strings

Modern languages store strings on immutable heaps, making them impossible to reliably wipe.  Use arrays, streams or pointers where it is supported.  

And if you are programming in dotnet, you should be able to reliably use Span and ReadOnlySpan to restrict everything to stack only memory.