Design so the agent never holds the credential, because every control that assumes it does (scanning, masking, rotation) is a race that must be won continuously and it only has to lose once.

The mechanism

The default configuration is the problem. Take the agent workspace threat-modelled in the MATRA case study: source code, deployment scripts, and a .env file carrying production database credentials and third-party API keys, all sitting in a directory the agent’s own file tools can read. Credential exfiltration from that asset is rated high impact, and the profile is a solo developer on a personal workstation with a production database, which is to say the citizen developer. Nothing has to be hacked: the agent was given file access, and the secrets were in a file.

Scale first, so nobody argues about whether this is real. GitGuardian counted 28.65 million hardcoded secrets in public GitHub commits during 2025, up 34% year over year. Leaked AI service keys specifically reached 1,275,105 instances, up 81%, and eight of the ten fastest-growing detector categories were AI-service-related. The model API key is now its own class of secret, and existing scanners may not have a rule for it.

One widely repeated comparison from that data needs care. Commits co-authored by an AI coding assistant carried secrets at 3.2% against a 1.5% baseline. That baseline is all public commits, which already include plenty of AI-assisted work, so this is not a clean AI-versus-human measurement, and GitGuardian itself cautions against reading the gap as pure tool failure. It is evidence that assisted development leaks secrets at a materially higher rate, and not evidence that machines are careless and people are not.

Also retire a claim that circulates alongside it: that without review history a hardcoded credential cannot be found until it is abused. That is self-refuting: those 28.65 million were found by scanning artifacts, with no review history involved. What is actually true is narrower and still useful. Missing review history costs attribution and intent: who introduced the key, and whether it was ever rotated. And on platforms whose artifacts never land in a scannable repository, the scanner has nothing to point at. That second one is the citizen-development case exactly.

The sprawl is multiplicative rather than exponential, and the honest arithmetic is agents times integrations. One supply-chain agent may need credentials for a shipping provider, a warehouse system, a customs service and the ERP simultaneously. Ten such agents is forty secrets to store, rotate and eventually revoke.

What to do

Take the secret out of the agent’s reach. The architectural version: the orchestrator holds the key material and performs the privileged operation on request, so a compromised agent cannot exfiltrate a key it never had. OWASP states this for signing and attestation keys with HSM- or KMS-backed management; the pattern generalises. Microsoft’s product guidance says the operational equivalent for its platform: agents should not store secrets at all, credentials belong in managed connections and environment variables backed by a key vault so they resolve at runtime and never appear in the agent definition. That last clause is the test: if a secret is visible in the artifact, it will eventually be visible somewhere else.

Provision per action rather than per agent. The AI-control literature’s baseline posture keeps no durable credentials on the agent’s machine and issues them for each consequential action. Worth knowing that this is presented as the lowest control level in that framework, a floor rather than an aspiration.

Point the scanners where citizen developers actually work. Repositories are covered. Low-code exports, flow definitions, notebooks, agent configs and prompt stores usually are not, and what leaks there is access primitives rather than data alone. Independent scans of deployed vibe-coded applications found hundreds of exposed secrets across thousands of apps, dominated by auth tokens and misconfigured database row-level security; one launch shipped a database key in client-side JavaScript and exposed 1.5 million tokens within days.

Treat system prompts as managed assets. Vendor telemetry found hardcoded prompt templates in 4.4% of active accounts as of Q4 2025. That is a small number over an undefined denominator, so take the direction rather than the figure. Prompts under version control with access control is the practice; skip the vendor’s coinage for it.

Tier and rotate. A research architecture offers a usable template: ephemeral one-time keys per interaction, medium-term access-control keys rotated weekly or biweekly, long-term identity keys every 30 to 90 days. Attribute those cadences to that prototype rather than to NIST. SP 800-57 actually suggests one to three years for private signature keys and one to two for authentication keys, while noting that shorter cryptoperiods generally improve security and its own figures are order-of-magnitude guidance. The tiering idea is sound; the specific 30-to-90-day number is one research team’s choice.

Then, and only then, add detection. Scanning agent inputs and outputs for secrets with blocking or masking is worth having, and no source measures how often it actually catches anything. Rank it below the architectural controls above, which is also what its own proponents recommend for production.

How you’d know it’s working

Coverage, before hit rate. A falling scanner hit rate over 10% of the estate is a smaller sample rather than a result. Track what fraction of citizen-build surfaces — exports, flows, prompt stores, agent definitions — is actually scanned, and expect that number to be embarrassing at first.

Pick one agent and try to find a credential it can read. Success there means the control is absent, regardless of what the vault contains.

Rotation actually happens. A vault holding keys nobody has rotated in two years is a filing cabinet with better branding.

What this doesn’t solve

Vaulting stops credential leakage, not credential misuse. A properly stored, properly scoped key wielded by an injected agent is still an incident: the agent asks the orchestrator to perform the operation and the orchestrator complies, because that is what it is for. See prompt injection and human approval gates.

It says nothing about the data the agent legitimately reads. That is data access governance.

Detection on the data path is unmeasured. Nobody has published a catch rate for secret scanning of agent inputs and outputs, so treat it as defence in depth and not as a control that can be evidenced to an examiner.

And revocation remains the hard part. Knowing a key leaked differs from being able to retire it quickly across every agent, config and cached session that holds it. See kill switches and revocation.

See also

• Identity and access for agents — per-agent identity is what makes vault references, scoping and rotation workable at all.
• Kill switches and revocation — retiring what leaked, and why it is slower than expected.
• Shadow agents — the unregistered builds where leaked secrets concentrate and scanners never reach.
• Data exfiltration — a leaked credential is a durable exfiltration channel that outlives the app.
• Quality debt and orphaned apps — orphaned applications keep their embedded keys alive indefinitely.
• Sandboxing — bounding what the agent’s file tools can reach in the first place.