What Claude Code can reach on its own
Claude Code reads and edits files, runs shell commands, fetches from the web and calls tools over the Model Context Protocol. Its documentation describes a permission system of allow, ask and deny rules, matched against the tool being used and what it is being used on, and layered across several settings files. The user’s own file, the project’s shared file and a developer’s local overrides are joined by organisation-managed settings that nothing lower can override.
That is a good local control, and a team should use it. It is not a team control. The shared rules sit in a file the developer can edit or bypass, the prompts are easy to turn off once they get in the way, and the record of what happened stays on the machine that did it.
What a team gets to decide
Under KPATH, what a Claude Code session may reach stops being a per-machine setting and becomes a policy the team writes once.
- Which developer is acting. Every governed call carries the identity of the developer it acts for, with an owner and a risk tier behind it. Your identity provider decides who exists. KPATH enforces at the moment the harness acts.
- What that developer may reach. Which repositories, which internal systems, which web destinations, and which tools, written per developer and per team rather than as one flat rule for everyone. The decision is made on each call, not signed off once at onboarding.
- What it may spend. Budget is checked on the call itself and attributed back to the developer and the originating request.
- When a person has to agree. Policy can require a human to approve before a high-risk action goes through.
- What stops. An agent, or a whole chain it set off, can be stopped and stays stopped.
The harness holds one credential and nothing else. KPATH adds the real credential each system needs on an allowed call, so a developer’s machine never holds a key that opens a door somewhere else.
What gets recorded
Every call, allowed or refused, is written to a signed, tamper-evident record: who acted, which tool, which target, what was decided and why. It streams to your SIEM and is ready for write-once retention. It never contains a secret, a prompt or a message body. An auditor can verify it has not been altered without trusting KPATH or its console.
That record is the part the harness cannot give a team on its own. Local permission rules leave logs where the developer is; evidence has to live somewhere else. KPATH governs the request envelope: identity, target, action, size, delegation chain. Of the payload, it reads only the values you declare for a rule, such as a payment amount. Source, prompts and tool results pass through unread.
What does not change
Claude Code still runs, the model is the same, the prompts are the same, and its own permission rules keep doing their local job. Deploy in monitor mode: observe only, enforce no policy, rewrite no agents. Flip to enforce by repointing egress. The inventory of tools and destinations fills in from real work first, so policy gets written against what the team actually does.