Secrets in the Prompt: Why AI Coding Agents Are the New Credential Attack Surface (And the Tool That Fixes It)

What is Veil? Veil is an open-source, local HTTPS proxy designed to protect AI coding agents from leaking credentials by swapping real secrets with format-preserving placeholders at the network boundary.

Last week on this site, we broke down the Mini Shai-Hulud npm attack: 637 malicious packages pushed across 317 packages in 22 minutes, designed specifically to hijack AI coding agents through session hooks rather than steal passwords and move on. The attack was proof of concept that your AI coding agent is not just a productivity multiplier. It is an attack surface.

But the offensive story was only half the puzzle. The defensive response just shipped this week, and it is worth your attention because it addresses the structural problem at the network boundary rather than patching symptoms. It is called Veil. It is open source, it has 622 commits on GitHub, and it does one thing very well: it sits between your AI coding agent and the internet, swaps real credentials for format-preserving placeholders, and injects the actual secrets only at the network boundary where they are needed.

The agent never sees a real token. One brew install and two commands later, your .env file becomes a field of decoys, and your Claude Code session cannot leak what it never had. This is not theoretical. Credential leakage through AI tooling is the breach vector nobody is monitoring, and the numbers say it is already happening at scale.

The New Attack Surface Nobody Is Watching

AI coding agents ingest credentials through a staggering number of channels. Environment variables, .env files scattered across project directories, and hardcoded API keys in configuration files are just the beginning. Secrets are copied into prompts during debugging sessions, pulled from clipboard contents, and stored in session context that persists across conversations.

The agent does not care which channel the secret came through. It sends everything to the model provider, and those tokens travel across the wire in plaintext headers that are one misconfigured logging statement away from exposure. If the provider logs prompts for training or debugging, your credentials are now in a training dataset you do not control. If the agent caches responses locally, your tokens are sitting in an unencrypted SQLite database on your machine.

The Mini Shai-Hulud attack demonstrated exactly why this matters. Attackers do not need your password. They need your agent's session context. The malware injected persistence into Claude Code's SessionStart hooks, meaning every new coding session automatically re-executed the payload. It patched VS Code's tasks.json to fire on folderOpen and installed a systemd service called "kitty-monitor" that polled a GitHub dead-drop C2 every hour.

The payload harvested AWS credentials across the full chain (environment variables, EC2 IMDS metadata, ECS container credentials, Secrets Manager), GitHub PATs, npm publish tokens, SSH keys, and password manager vaults for 1Password, Bitwarden, and gopass. In CI/CD environments, it went further: it exchanged GitHub Actions OIDC tokens for npm publish tokens, signed artifacts via Sigstore using the stolen identity, and injected persistence into workflow files that dumped toJSON(secrets) as a build artifact.

This is not a password stealer. This is a full-spectrum credential harvesting operation that targets the thing AI coding agents cannot avoid doing: reading your project files.

Then there is the Cloudflare incident. Cloudflare's internal "Ask AI" feature, designed to let engineers query internal systems through natural language, leaked authentication tokens in production. The details remain partially under disclosure, but the postmortem confirmed what security engineers already suspected: when you give an AI model access to your internal APIs, it will surface credentials in ways you did not anticipate. Existing monitoring will not catch it because you were not watching the AI pipeline as a credential boundary.

The scale of the problem is sobering. GitHub Copilot agent workspaces grew from 83,000 to 2.3 million in 10 months. Global Git push volume is up 78% year-over-year, driven primarily by AI coding agents. Stack Overflow's 2025 survey found 84% of developers are using or planning to use AI coding tools, with 51% using them daily.

Meanwhile, GitGuardian's State of Secrets Sprawl Report found 28.6 million new secrets exposed in public GitHub commits across 2025, a 34% year-over-year increase. Commits co-authored by AI tools leak secrets at roughly double the baseline rate, and AI-service credential leaks grew 81%. Twelve of the top 15 fastest-growing leaked secret types were AI services.

You can do the rough math: 2.3 million active workspaces times the average credential density of a modern project equals an attack surface that makes the password theft era look quaint. The difference is that password theft requires finding passwords. AI credential leakage requires the agent doing exactly what you asked it to do: read your code and send it somewhere.

How Veil Fixes the Leak at the Network Boundary

The Veil architecture is clean enough to explain in three steps.

First, veil init scans your .env files and migrates Bearer secrets into your operating system's keychain. On macOS, that is Keychain; on Linux, it is Secret Service. On headless systems without a keyring, it falls back to an age-encrypted key file. The .env file gets format-preserving placeholders: same prefix, same length, same character set. The placeholder for an OpenAI key starting with sk- still starts with sk- and has the same number of characters. The agent cannot visually distinguish it from a real token.

Second, veil run claude (or cursor, or copilot) starts a local HTTPS proxy and launches your agent with HTTP_PROXY and HTTPS_PROXY set. The proxy inspects every outbound Authorization: Bearer request. When it sees a placeholder, it swaps in the real credential from the keychain. When it sees a request to a host that does not match the scoped credential, it passes it through untouched or blocks it depending on configuration.

Third, every credential injection and agent action is logged to a local SQLite database. Run veil log to see what credentials were accessed, by which agent, to which hosts, at what time. Run veil log --blocked to see what Veil prevented from leaving your machine.

The security guarantee is narrow but honest. Veil is not a sandbox. It assumes a cooperative but curious agent, one that follows standard HTTP conventions but might leak secrets it has seen. If you are worried about a hostile agent with arbitrary code execution, you need OS-level isolation on top of Veil. But for the common case of a developer running Claude Code or Cursor on a real codebase with real credentials, Veil closes the most likely leak path.

The TLS story matters because any HTTPS proxy has to terminate and re-originate TLS. Veil handles this by generating a local CA during veil init that lives entirely inside Veil's state directory. It is never added to your system or browser trust store. At runtime, Veil injects the CA into only the child process via environment variables. The CA's blast radius is bounded to processes Veil launched, and the private key is generated locally and never leaves your machine.

The compatibility story is equally clean. Anything that respects HTTP_PROXY and HTTPS_PROXY works unchanged. The agent does not need to know Veil exists. No code changes are required. Veil currently supports Bearer tokens for 13 major providers. Unknown Bearer-shaped secrets in .env are detected and reported but not automatically vaulted. If Veil cannot safely manage a credential (like AWS SigV4 signing or HTTP Basic auth), veil init leaves it in .env and tells you.

This pattern beats the alternatives on a fundamental level. Credential scanning is reactive. Environment isolation is brittle. But proxy-level swapping is transparent. It operates at the only choke point that matters: the outbound HTTP request. If the credential never reaches the agent, it cannot be leaked through the agent.

Beyond Veil: The AI Credential Security Stack

One tool does not make a security posture. If you are running AI coding agents in production with access to real credentials, you need a layered defense. Here is the four-layer stack that actually stops credential leakage:

Layer 1: Network Boundary (Veil). This prevents credential egress. The proxy intercepts outbound requests, verifies the destination matches the scoped host, and injects real secrets only at the network boundary. The agent never sees a real credential.

Layer 2: Prompt Sanitization. Even with Veil in place, developers paste secrets into prompts. You need a pre-send hook that strips known credential patterns from the prompt text before it reaches the model. Regular expressions for common token formats can catch 90% of paste-based leaks. The remaining 10% requires an organizational culture shift.

Layer 3: Audit Logging. Veil logs every credential access by default, but you need broader visibility. You must know which agent accessed which secret, for which request, to which endpoint, at what time. This data answers what an attacker acquired after an incident.

Layer 4: Least-Privilege Tokens. Every credential your AI agent can potentially access should be scoped to the minimum necessary permissions. If your agent is writing documentation, it does not need write access to your production database. OIDC-based short-lived tokens are preferable to static API keys in every scenario because they limit the attacker's window of opportunity.

Implementing all four layers is not a bonus exercise; it is the baseline. The industry is operating under a trust model that was designed for humans reading code one file at a time, not for AI agents that ingest entire repositories as context and send everything to external APIs. That trust model is broken. You fix it by assuming the agent will see everything and designing your credential architecture so that "everything" does not include real secrets.

Deployment Guide: 15 Minutes to Credential Safety

Here is how to deploy Veil and the supporting layers on a development machine.

Step 1: Install Veil.

brew install getveil/tap/veil

On Linux without a system keyring, use go install github.com/getveil/veil/cmd/veil@latest and set VEIL_PASSPHRASE in your environment.

Step 2: Initialize.

veil init

This scans all .env files in your project, moves recognized Bearer secrets to your OS keychain, and replaces them with format-preserving placeholders. Read the output carefully to manually add unknown secrets.

Step 3: Verify.

veil status
veil list

Confirm that all expected credentials are managed and that your .env files contain only placeholders.

Step 4: Run your agent.

veil run claude

Or cursor, or any command that respects HTTP_PROXY. Veil starts the proxy, launches your agent, and begins logging all credential injections.

Step 5: Add prompt sanitization. Create a pre-commit hook or editor extension that detects credential-like strings in text before sending to the model. At minimum, strip patterns matching common API keys and any string matching your organization's credential prefixes.

Common Pitfalls and Limitations

Certificate trust issues are the most common problem. If your agent uses a bundled CA store, it will not trust Veil's per-session CA. The fix is configuring the agent to use the system trust store or the environment variables Veil sets.

Crucially, you must monitor local-first memory persistence. If an agent writes a credential to disk in a session checkpoint or memory file, Veil cannot intercept that because it is not an HTTP request. This is a real risk with Claude Code's "dreaming" feature, which writes notes to disk across sessions to build out contextual memory. Because of this local data architecture, you will still need filesystem-level monitoring or encrypted-at-rest policies for your agent's memory stores.

Likewise, Veil cannot protect against context window leakage to non-HTTP channels (like gRPC or custom TCP protocols) or stop model providers from utilizing injected text in their training data. Monitor your agent's network behavior and confirm all sensitive traffic routes through the proxy.

Takeaway

The Mini Shai-Hulud attack was the offensive wake-up call, and Veil is the defensive response. AI coding agents are a massive target, the attack surface spans millions of active workspaces, and credential leakage is accelerating faster than security teams can react.

If you are running Cursor, Claude Code, or Copilot in production without a credential proxy, your secrets are one prompt away from exposure. The fix takes 15 minutes and three commands. The npm attack proved the threat is real. Veil proves the defense is catching up. The gap between these two facts is where your exposure lives. Close it today.