Govern Claude Code: 5 answers before you approve the agent

Claude Code runs on your developer's laptop with their permissions, reaching source, secrets and cloud. Five answers, a three-column key inventory and the audit trail.

The agent runs on this desk, with the permissions of whoever sits at it

How to govern Claude Code in the enterprise: five answers before you approve it

On site the gate logs who came in. In software access only piles up

Before you let Claude Code, or any coding agent, inside your company, you need five answers. None of them is about the model:

1. Which machine the agent runs on, and with whose permissions it executes each command.
2. Which credentials that machine can already reach without anyone typing a password.
3. What gets logged per session: the prompt, the commands executed, the diff it produced.
4. Who approves what the agent wrote before it reaches your customer.
5. What each task costs, and who reads that bill at the end of the month.

CIO.com ran a piece two days ago on the five things a CIO has to understand to govern Claude Code. The first one is the one nobody raises in the approval meeting: the agent runs locally on the employee's workstation, executes commands with that employee's permissions, and from there it can reach source code, credentials, cloud environments and every connected system. The purchase looks like a productivity subscription. What you actually signed off was an access grant.

The badge you handed over without checking what it opens

I signed off on structural steel on construction sites before I shipped software. On a site, nobody walks past the gate without signing in, wearing a badge and having someone know why they are there. The key to the tool container has a named owner. If a welding cable goes missing, you know within the hour who had that key, because the list exists on paper.

Now look at the account of a senior engineer who has been with you for three years. It accumulated access the way access always accumulates: a payment provider key in the env file of a 2022 project, a CI token with write permission on every repository, read credentials on a database holding real customer rows because somebody once had to reproduce a bug, an admin role in a cloud console granted during a 2 a.m. incident and never revoked.

As long as a human is typing, each of those is used only when that human decides to use it. With an agent, the choice of which command to run comes out of a one sentence objective, and the path to the objective is assembled by the machine. That autonomy is the point of the tool, and it is also what rewrites the question on the table. It stops being "do I trust this engineer" and becomes "what can this workstation reach from a single sentence".

It gets worse on inherited systems. When we take over code our team did not write, and I have written about the first seven days inside inherited spaghetti code, the credential inventory is the one artefact that never shows up. Old keys sit in git history, still valid, waiting for someone to ask.

Key, owner, last rotation: the inventory that fits in a spreadsheet

In the files that hold the till, the approver still has a first and last name

Before wiring an agent into any repository, we answer three columns:

• Key: which credential exists, where it is written down, and exactly what it opens on the other side.
• Owner: which person answers for it today, not which team, because a team is not accountable at 3 a.m.
• Last rotation: the date that credential was last rotated, and by whom.

In the internal system I build for Revin, that table runs to thirty odd rows. It is not pretty. It is a spreadsheet. Column three is the painful one, because the honest answer is usually "never", and we have seen the same pattern across 31 broken codebases we audited.

Once the inventory exists, the decision gets easy. You do not need a ten page policy. You need to know which of those rows are within reach of the machine the agent will run on, and cut the ones that should not be there before the first session.

"My team is senior, this is paranoia"

We hear that on sales calls every week, and it is half right. Nobody is doubting your senior engineer. What changed is the volume and the origin of what enters the system.

Sonar surveyed more than 1,100 professional developers, and CIO.com reported the numbers: around 72% of those who tried AI coding tools now use them daily, roughly 42% of committed code already comes from them, with 65% projected for next year. In the same survey, 96% say they do not fully trust the output. So nearly half of the new code in your product starts life as a sentence, and the person who wrote the sentence did not control every step after it.

Bear with the word governance, which smells of consulting slides. In practice it means two tables and a fifteen minute meeting.

The audit trail someone will ask for on incident day

Picture a Tuesday where one of your customers opens a screen and sees another customer's order. It happens, and the model is rarely the culprit: a query lost its tenant filter. Your legal counsel will ask four things that same day. Which session produced the change, what the original prompt was, which command ran against the environment, and who approved the release.

If the answer to any of the four is "we do not keep that", you will reconstruct the story from human memory. I have watched that burn a week of three people's time. It is the same logic as who noticed the outage first, you or your customer: when instrumentation is missing, your customer becomes your monitoring.

Session logging is cheap to switch on and expensive to lack. Keep the prompt, the diff and the name of the approver. Six months, minimum.

Review still has a first and last name

Agents write fast, and they write plausible. Those are two different properties from correct. The boring half of review they handle well, and I went into detail on how far you can take the human out of the pull request. What does not change hands is the decision about business rules, about what happens on failure, and about anything that charges a customer's card.

What we actually do before enabling an agent in a repository is split the system into two kinds of place. Some files are the shop window, where a mistake is ugly and reversible. Some files are the till, where a mistake is money walking out. In the second kind, a human approves line by line, with tests that assert a result instead of merely running without throwing.

The bill that arrives without a line item

The fifth answer is the most mundane, and the quickest to blow up. Agent usage is consumption, and consumption with no per task allocation becomes an invoice nobody can explain in the cost review. Put the price of each request on the screen of the person pressing the button, before it runs, and read the bill next to the delivery. Same reasoning as measuring AI's return without counting lines of code: the numerator is change that stayed up in production, the denominator is everything you paid to get it there.

Where this rule breaks

I am not sure it holds for a two engineer team with no paying customer yet. At that size, building a key inventory before the first real user is optimising something that does not exist, and I would not do it either. It starts to matter the day third party data sits in your database and a confidentiality clause sits in a signed contract, which usually happens earlier than anyone notices.

There is also the case where the advice costs you money: a team already running on short lived credentials, access requested on demand and revoked after. There the inventory is redundant, and the whole conversation moves somewhere else.

Outside those two extremes, the question for your Monday is short. Open one engineer's laptop, list everything that workstation can reach without typing a password, and say out loud whether you would grant that same access to a vendor you hired yesterday. Because from your system's point of view, that is precisely what an agent is.