# How to keep secrets out of AI agent commits
> Secret scanning for AI agent commits works in layers. Limit what the agent can read, block secrets at commit time with Droid Shield, scan again in CI, and rotate any credential that reached a remote. A practical setup for teams using coding agents.
URL: https://factory.com/articles/agent-generated-commit-secret-scanning
Published: 2026-09-22
Updated: 2026-10-23
To keep secrets out of commits written by a coding agent, limit which credentials and files the agent can read, scan added lines before every commit and push, run a second secret scanner in CI, and rotate any credential that reached a remote. Factory's Droid Shield covers the commit and push step for git operations that Droid performs.
Secret scanning for agent-generated commits protects a boundary that is easy to overlook. A coding agent may read configuration, test output, fixtures, or tool responses while solving a task. Credentials copied into source, logs, snapshots, or generated files can persist in Git history even after a later commit removes them.
The safest workflow limits exposure before editing and scans again before commit and push. OWASP’s [secrets management guidance](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html) recommends centralizing storage, limiting access, rotating credentials, and maintaining audit information across the secret lifecycle.
## Reduce secret exposure before work starts
Give the agent only the credentials and files required for the task. Prefer short-lived tokens, narrowly scoped service accounts, and environment injection over values written into repository files. Keep production credentials away from development and preview environments.
Repository instructions should identify sensitive paths and safe substitutes. Use placeholders in examples, sanitized fixtures in tests, and mock responses that preserve shape without preserving real values. Exclude local environment files, debug captures, database dumps, and downloaded support artifacts through both access policy and ignore rules.
Prompts and task descriptions deserve the same care as code. Reference the secret’s environment variable name or storage location rather than pasting the value. If a tool returns credentials in output, stop that output from becoming a test snapshot or issue comment.
Limit network destinations too. A narrowly scoped task should not send repository context to an unrelated endpoint, and diagnostic uploads should require the same review as source changes.
## Scan at the Git boundary
Factory’s [Droid Shield](https://docs.factory.com/autonomy-and-safety/droid-shield) scans added lines when Droid performs a Git commit or push. It looks for credential patterns and blocks the operation when it finds a likely secret. The documentation also states that manual Git commands outside Droid are not covered, so teams still need repository and hosting controls.
Run established secret scanners in CI as a separate deterministic gate. Hosting-provider scanning, pre-commit checks, and server-side push protection can cover changes created outside the agent workflow. Tune allowlists narrowly and review them like code. A broad exemption can hide a real credential behind a recurring false positive.
Inspect generated and binary-adjacent artifacts too. Source maps, notebook outputs, HTTP recordings, package archives, and encoded fixture data can carry secrets even when ordinary source files are clean.
## Respond as if exposure occurred
When a scanner finds a real credential, block the commit or push and remove the value from the working tree. If the credential reached any remote, log store, artifact service, or shared message, rotate or revoke it first. History rewriting alone cannot invalidate a copied credential.
The right first action depends on how far the value traveled. Rotation comes first whenever a copy may exist outside the working tree.
| Where the value reached | First action | Follow-up |
| --- | --- | --- |
| Working tree only | Remove it before committing | Add a fake-value fixture if the scanner missed the format |
| Local commit, not pushed | Remove it from the commit | Find how it entered the agent's context |
| Remote branch or pull request | Rotate or revoke the credential | Clean history, check provider access logs |
| Logs, artifacts, or messages | Rotate or revoke the credential | Remove copies under the retention policy |
Document the affected system, rotation result, and cleanup without repeating the secret. Check access logs when the provider makes them available. Then identify how the value entered the agent’s context and tighten that path.
Add a regression fixture with a fake value when the scanner missed a recognizable format. Confirm that the fixture cannot be mistaken for a usable credential.
## How Factory layers secret controls around Droids
Factory is a platform for running a software factory, where agents called Droids take work from a signal to a reviewed pull request. Factory places several controls around the agent, so a credential has to get past more than one check before it reaches Git history.
Agent context
sandbox deny lists, scoped tokens"]
B["Droid Shield
scans added lines on commit and push"]
C["PreToolUse hook
optional team scanner before git runs"]
D["CI secret scanner
deterministic required check"]
E["Host push protection
covers commits made outside Droid"]
F["Reviewer
approves and merges"]
A --> B --> C --> D --> E --> F
`}
/>
**Limit what the Droid can read.** [Agent Safety & Controls](https://docs.factory.com/enterprise/llm-safety-and-agent-controls) include a built-in sandbox with path deny lists, such as `denyRead` for `~/.ssh` and `~/.aws`, and command rules that allow, ask, or block matching commands. Admins configure these through managed settings, and they can also enforce Droid Shield for the whole organization.
**Block at commit time.** Droid Shield analyzes only the lines being added, blocks the `git commit` or `git push` when it detects a likely secret, and reports where it found it. Because it covers only git operations performed through Droid, the CI scanner and host push protection stay in place.
**Add a team-specific check.** A `PreToolUse` [hook](https://docs.factory.com/harness/hooks) runs before a tool call and blocks it when it exits with code `2`. A team can use one to run its own scanner rules before Droid executes a commit command.
**Review the pull request.** Factory's [security review](https://docs.factory.com/software-factory/security-review) lists a hardcoded production secret as a P0 finding. It complements the deterministic scanner, which should remain a required check.
## Frequently asked questions
### Why do coding agents leak secrets into commits?
A coding agent reads configuration, test output, fixtures, and tool responses while it works. A credential copied from any of those into source, logs, snapshots, or generated files can persist in Git history even after a later commit removes it.
### Is removing a secret from Git history enough?
No. If the credential reached any remote, log store, artifact service, or shared message, rotate or revoke it first. History rewriting cannot invalidate a copy someone already has.
### What does Droid Shield scan?
Droid Shield scans the lines being added when Droid performs a git commit or push, uses pattern matching to find likely credentials, and blocks the operation if it finds one. Manual git commands run outside Droid are not covered.
### What controls should sit alongside agent secret scanning?
Use scoped, short-lived credentials, sandbox deny lists for sensitive paths, a deterministic secret scanner in CI, and push protection at the Git host. Layered controls matter because no single scanner recognizes every format.
## Further reading
- [Least privilege](https://factory.com/articles/least-privilege-coding-agents)
- [Log redaction](https://factory.com/articles/log-redaction-coding-agents)
- [Test data privacy](https://factory.com/articles/test-data-privacy-coding-agents)
- [Droid Shield docs](https://docs.factory.com/autonomy-and-safety/droid-shield)