Your AI Agent Has Your Production Keys — Here's How to Find Out
An AI agent running in auto-approve mode on a machine with production credentials approves its own actions, with no human in the loop and no record. The switch is sitting in your repo. Here's how to read it.
Part of our AI Code Governance: A 2026 Field Guide series — the operating model for attributing, classifying, deciding, and proving AI-written code.
Here's a configuration that exists in more repositories than anyone would guess: an AI coding agent, running in auto-approve mode, on a developer machine that holds production credentials. The agent approves its own actions. No human confirms anything. And nothing, anywhere, records that this is the arrangement.
The unsettling part isn't that it's reckless. It's that it's invisible — the repository can look perfectly governed while the agent quietly holds the keys.
What does "auto-approve" actually mean?
Auto-approve (sometimes shipped as a "bypass permissions" or "YOLO"-style mode) is a setting that lets an AI agent execute actions — running commands, editing files, calling tools — without stopping to ask a human for confirmation. It exists for a good reason: constant approval prompts kill the flow that makes agents useful.
The problem isn't the setting. It's the combination. Auto-approve on a sandbox with throwaway data is fine. Auto-approve on a machine that can reach production — with credentials in its environment — means an agent can take consequential, irreversible actions with no human in the loop and no after-the-fact record that it could.
Why this is invisible today
A repository can broadcast every sign of good governance and still have the switch flipped:
• It ships a policy file and an allow-list of permitted commands — looks controlled.
• It passes your scanners — none of them grade an agent's permission mode.
• The one file that reveals the truth — the agent's own settings — is sitting in the repo, unread, because nothing was built to read it.
So the gap isn't hidden. It's in plain sight, in a structured file, that no tool in your stack currently opens.
Where to look: the config the agents write themselves
You don't need to scan source code to find this. Modern AI coding tools store their permissions in the repository, in structured settings files with a known meaning — allow-lists, deny-lists, and the auto-approve switch itself.
Read those files and the picture assembles itself:
• Is auto-approve / bypass mode on? A single flag, stated plainly.
• What's on the allow-list and deny-list? Is it deny-by-default, or effectively "anything goes"?
• Does this repo touch production? Cross-reference the permission mode with how sensitive the repo actually is.
The signal is high-confidence precisely because you're reading a machine-set switch, not interpreting prose.
Presence is a fact — don't ask a model to guess
The temptation is to point a language model at the repo and ask "is this agent configured safely?" Resist it. That produces an opinion, and an opinion can't be sealed, reproduced, or defended.
Reading the switch is different. "Auto-approve is enabled in a production-adjacent repository" is an observed fact — it turns a control red because a value was read, not because a model had a hunch. That's the kind of finding you can put in front of a board and stand behind. Keep the intelligence at the edges; keep the verdict deterministic.
What to do this quarter
1. Inventory the switch. Read the agent settings across your repos and list every one where auto-approve / bypass mode is on.
2. Cross-reference with sensitivity. The reds are the intersection: auto-approve and production reach. Those are the ones to fix first.
3. Set the rule. Deny-by-default command lists; no auto-approve where production credentials live; human confirmation for consequential actions.
4. Make it a live control. "No self-approving agents in sensitive repos" should be a row in your control matrix, evidenced continuously — not a line in a policy nobody re-checks.
Where Provenance fits
Diwo Provenance governs AI-written code by reading the signals your estate already emits — including the agents' own settings files. It reads the auto-approve switch, the allow-lists, and the deny-lists as observed facts, cross-references them against how sensitive each repository is, and rolls the result into a sealed control record you can hand to a board or an auditor.
Not another scanner. The one that finally opens the file where the agent wrote down how much power it gave itself.
Seeing your own estate takes about 15 minutes with a free, read-only connection: connect your estate free and find out which of your agents are approving their own actions today.
The keys were always there. Now you can see who's holding them.
Related reading
• The pillar: AI Code Governance: A 2026 Field Guide — the full operating model and the three risks to govern first.
• Who's Accountable When AI Writes the Code?
• Slopsquatting: The Supply-Chain Attack Your AI Agent Invites In
FAQ
Is auto-approve mode always dangerous? No. It's fine in isolated sandboxes with no sensitive access. The risk is the combination — auto-approve on a machine or repo that can reach production.
Do I have to scan source code to detect this? No. The permission mode lives in the agent's own settings file in the repo — a structured signal you read, not a source-code scan.
What's the difference between reading the switch and asking an AI to judge it? Reading the switch is an observed fact you can seal and reproduce. Asking a model "is this safe?" is an opinion that can't be defended in an audit.
Diwo helps organizations govern AI-written code: attribute it, classify it, decide against your controls, and prove it — as sealed evidence, mapped to the frameworks you already answer to.