Agent settings secret leaks: contract clauses to demand

Agent settings secret leaks moved from a checklist item to a live exposure event this month. Researchers at Apiiro found thousands of secrets — database passwords, API tokens, root logins — sitting in Claude Code settings files committed to public GitHub repositories, as Ars Technica reported. The cause was mundane. A developer approves a shell command with "Yes, and don't ask again", and the command, password included, is written verbatim into `.claude/settings.local.json`.

The file is meant to stay local. The protection does not always travel with the code. For procurement and IT leaders, that is the point. The coding agent you bought as a seat behaves like a privileged supplier. Its configuration files, transcripts and instruction files now hold credentials. Those credentials reach repositories your security team never reviewed. The contract has to catch up.

Why agent settings secret leaks are a procurement problem

The volume puts this beyond a few unlucky developers. Apiiro counted 104,185 copies of the local settings file on public GitHub. Of those, 1,122 held a real secret. Counting git history, shared settings and saved transcripts, the figure reached 2,539 distinct secrets across 1,994 repositories, affecting 63 organizations, according to a team breakdown of the study.

Deleting the file does not close the gap. In 539 of 1,105 traced repositories, a commit co-authored by the agent itself changed the file. And 215 of the 1,122 exposed files were missed by gitleaks and TruffleHog. The secrets sat inside command strings those scanners do not parse.

This is not one vendor's quirk. Instruction files such as `CLAUDE.md`, `AGENTS.md`, `GEMINI.md` and Copilot instruction files are read by the agent at the start of every session. A Radware scan found that about 0.7% of one common file type checked contained a real credential (Radware). In more than eight of ten cases, a person had pasted the key.

Agent settings secret leaks also sit outside the usual supplier review. The agent was bought as a seat, installed as a privileged integration, and never put through the checks a contractor would face. The AI agent governance controls buyers must demand set out the runtime identity and monitoring language that fills that gap.

What the market data says about agent settings secret leaks

The trend line is not flattening. GitGuardian's 2026 report found newly leaked secrets on GitHub up 34% year over year to roughly 29 million. Leaks tied to AI services rose 81% year over year to 1,275,105. Claude Code-assisted commits leaked secrets at about 3.2%, roughly double the baseline (GitGuardian).

GitHub's own figures point the same way. One in three pull requests on GitHub involved an AI agent as of October 2026, up from fewer than one in ten a year earlier. A new secret appears in publicly visible code roughly once every two seconds (GitHub Blog).

The sources do differ on scale. Apiiro's 1,122 figure counts files with a confirmed secret in current copies. The 2,539 figure adds history and transcripts. GitGuardian's 3.2% is a leak rate per commit, a different measure entirely. Do not reconcile them into one number. Pick the definition that matches the clause you are writing.

The four contract clauses to put in writing

Agent settings secret leaks fail at the seams between your team, the tool vendor and the integrator who configured it. These clauses close the seams.

1. 1Repository hygiene obligations. Require a repo-level ignore rule for agent settings, transcripts, memory files and instruction files. Do not accept a setting that lives only on a laptop. Require push protection and secret scanning that parses command strings. Ask the vendor to name the tools.
2. 2Agent configuration controls. The vendor or integrator must document how standing approvals are stored. It must say what gets written to disk and how to disable literal command saving. Permissions should be expressed as patterns, not verbatim commands.
3. 3Breach notification with a clock. Specify hours, not weeks, from discovery of a leaked credential. The clock should start when the leak touches your repositories or agent configuration. Require notice of the model provider or downstream dependency if code or context reached it.
4. 4Change of control and subprocessor notice. The agent sits between your code and model providers, plugin registries and MCP servers. Require notice before any of those changes.

The wider buying pattern is familiar. Privileged suppliers need vendor risk review. The AI agent permissions guide covers the discovery, least-privilege and audit language to attach. It applies directly to coding agents.

How to verify a vendor's claims before you sign

Vendors will say they scan. Ask for evidence that maps to your repositories.

• Request a written description of every file the agent writes into a repository. Ask where each one lands by default.
• Ask whether the ignore entry is written to the repository or only to the user's global git excludes. Get the answer in writing.
• Ask which scanners run. Ask whether they detect credentials embedded in command arguments, not just standard token formats.
• Request the mean time to revoke a leaked credential. Treat anything measured in weeks as a finding. GitHub reported a mean of about 40 days for manual revocation, with roughly one in five taking more than 90 days.
• Ask for the last three incidents involving agent configuration files and how they were handled.
• Confirm who owns agent settings on your side and who owns them on theirs.

For integrators deploying the tool, add two more checks. First, confirm that permissions are configured at the repository level. Second, ask for a handover document listing every agent-related file now in the codebase. The GitHub and Azure DevOps knowledge hub is a useful reference when writing repository controls into the statement of work.

Where the leak actually comes from

The origin is usually human, and that shapes the remedy. Radware found that in more than eight of ten cases the credential was typed in by a person. They pasted a working key so the tool would run (Radware). OWASP's guidance on secure coding with AI is blunt about the trust boundary. Agents running with auto-accept and full developer permissions carry the same blast radius as a compromised workstation. Rules files steer every future generation (OWASP).

That means a contract clause on scanning and notification is necessary but not sufficient. Your side needs a rotation owner. Your side also needs a rule that credentials travel as variable references, never as literals. A vendor can build the guardrail. Only your team can stop pasting keys into a file meant to be read by a model.

The exposure also outlives the fix. Secrets removed from a repository can persist in forks. Earlier versions of a settings file held 734 secrets in no current copy, per the study breakdown. Rotation is the only reliable response once a key has been public.

That framing helps set scope. Reduce what sits in the clone. Keep secrets out of the repository entirely. Treat agreements and monitoring as extra layers rather than the boundary itself. Contract clauses belong in the extra layers. They are the layers procurement can actually enforce.

Matching the contract to the engagement model

How you buy shapes what you can demand. A fixed-price build gives you a defined deliverable. It also gives you a clear point to inspect repository hygiene before acceptance. Time and materials lets you add security work mid-stream. You must still specify the scanning and configuration steps up front, or they will not appear on an invoice.

A dedicated team gives the most leverage. The vendor's engineers work inside your repositories daily. Agent configuration ownership and rotation duties belong in the team charter, not just the master agreement. The comparison of engagement models sets out where risk shifts in each.

Whatever the model, put the clauses in the schedule that covers tooling. Skip the general security appendix nobody reads. Name the files. Name the scanners. Name the notification window. Name the person who answers when agent settings secret leaks surface in a public fork.

Frequently asked questions

What are agent settings secret leaks?

They are credentials written into the files a coding agent uses to store approvals and instructions. A pasted password or key ends up in a settings file and is committed to a repository. The secret then reaches anyone who can read the repo, its history or its forks.

Are agent settings files a real leak risk or a one-off?

A measured one. Apiiro found more than 100,000 copies of Claude Code's local settings file on public GitHub. Over 1,100 held real secrets in current copies, and 2,539 across history, transcripts and shared files. Most affected 63 organizations, and many came from individual developers who did not realise the file had been committed.

Which contract clauses should buyers require?

Four earn their place. Ask for repository-level ignore rules for agent files. Require scanning that detects credentials inside command strings. Set breach notification measured in hours. Add notice of model provider or subprocessor changes. Add a named owner on each side for configuration and rotation. Vague commitments to "industry-standard security" will not survive an incident review.

Do secret scanners catch secrets in approved agent commands?

Not reliably. In the Apiiro study, gitleaks and TruffleHog together missed 215 of the 1,122 files that contained a real secret. The credential was embedded in a command string rather than a standard key format. Ask vendors specifically how their scanning parses command arguments.

What this means for buyers

The news gives you a reason to reopen agent tooling contracts now, before renewal. Start with an inventory. List which coding agents are installed, who approved them, and whether any were bought below the procurement threshold. The bank example in the CIO account is common. A seat bought on a corporate card became a privileged integration nobody reviewed (CIO).

Then act in this order:

1. 1Scan your public and internal repositories for agent settings, transcripts and instruction files, including git history and forks.
2. 2Rotate every credential found, and record who owns rotation.
3. 3Add the four clauses to the contract schedule covering tooling, with an hours-based notification window.
4. 4Require repository-level ignore rules and command-string scanning as acceptance criteria for any integrator deployment.
5. 5Assign one owner for shared agent configuration and review approval changes like code.

Vendors should expect these questions and answer them with artefacts, not assurances. A short written statement of the files the agent writes, the scanners in use and the revocation timeline is worth more than a security page. If you are selecting a security partner to run the scanning and remediation, the cybersecurity vendor directory lists providers by capability. You can also post a project describing the repository audit you need. The tools created a new file type that holds secrets. The contract is how you make sure nobody forgets it.