The 12 artefacts a Claude Code security review asks for
A Claude Code security review asks for evidence, not a demonstration. Pexon produces the 12 artefacts that answer that review: a managed permission policy developers cannot override, an OS-enforced sandbox with filesystem and network isolation, an MCP server inventory, an identity binding, and a written prompt injection exposure statement.
The starting point
The review does not ask whether it works. It asks what stops it.
A demonstration answers the wrong question. What the security review wants is the list of things the agent cannot do, the mechanism that enforces each one, and evidence that a developer on a laptop cannot undo it before lunch.
Most rollouts arrive with a screenshot of a permission prompt and an assurance that the team is careful. In our own configuration the first two rules are deny rules — Read(./.env) and Read(./secrets/**) — written before any allow rule exists, because an allow-first policy is how a repository ends up granting more than anyone approved.
The review is not hostile. It is asking for documents nobody produced.
What we build
What we build, and what each layer actually enforces
- A permission policy that holds under precedence. Claude Code evaluates rules in one order — deny, then ask, then allow — and a broad deny rule cannot carry an allowlist exception. We write the deny set first, ship it as managed settings so it outranks command line arguments and every project file, and set allowManagedPermissionRulesOnly so a checked-out repository cannot add rules of its own. Allow rules in a project file only apply once the workspace trust dialog is accepted; deny and ask rules apply immediately. Restrictions are not opt-in. Grants are.
- An OS-enforced boundary, not a prompt. Permission rules are decided from the command string before it runs. The sandbox is enforced by the operating system on the running process — Seatbelt on macOS, bubblewrap on Linux and WSL2 — so it holds regardless of what the model chose to run and even when an allowed command does more than its name suggests. We enable both layers, set failIfUnavailable, and set allowUnsandboxedCommands to false. Native Windows has no sandbox, so a Windows fleet gets WSL2 or a container, stated as a scope decision rather than discovered later.
- Egress, credentials, and the exfiltration path. The sandbox pre-allows no domains and its default read policy still allows ~/.aws/credentials and ~/.ssh — there is no built-in credential deny list, only the one you write. We write it, lock the domain list with allowManagedDomainsOnly, and put the residual risk in the same document: the proxy decides from the client-supplied hostname without inspecting TLS, so Anthropic's own warning about domain fronting through a broad entry like github.com applies to your allowlist too. A short allowlist is a control. A convenient one is a story.
- The prompt injection exposure, written down rather than implied. Claude Code ships real mitigations: web fetch runs in an isolated context window, curl and wget are not auto-approved, suspicious commands require manual approval even when previously allowlisted, and unmatched commands fail closed. Anthropic also states plainly that no system is completely immune to all attacks. A review that records the first half and not the second is not a review. We write both halves against your repository content, your MCP surface and the tools your policy actually grants.
- The blind spots a pilot never reaches. Trust verification is disabled when Claude Code runs non-interactively with -p, which is exactly how it runs in CI. claude setup-token and /install-github-app enforce forceLoginMethod but not forceLoginOrgUUID, so those paths can mint a token in another organisation. excludedCommands has no managed-only lock, so a developer can always append a command that runs outside the sandbox — which is why that list stays short and gets reviewed. Each blind spot gets an owner and a compensating control, not a footnote.
The evidence pack
The 12 artefacts, and what each one closes
- 01 The managed settings file itself, in version control, with the deployment path for every operating system in the fleet: /etc/claude-code/ on Linux and WSL, /Library/Application Support/ClaudeCode/ on macOS, C:\Program Files\ClaudeCode\ or the HKLM\SOFTWARE\Policies\ClaudeCode registry key on Windows.
- 02 Proof the policy cannot be lifted locally: managed settings outrank command line arguments, local project settings, shared project settings and user settings, and allowManagedPermissionRulesOnly stops user and project scopes defining allow, ask or deny rules at all.
- 03 The deny and ask rule set with one line of rationale per rule, exported from /permissions, which names the settings file each rule came from. That export is usually the first time anyone sees that three different files are contributing rules to the same session.
- 04 A permission-mode decision covering all six documented modes — default, acceptEdits, plan, auto, dontAsk and bypassPermissions — with disableBypassPermissionsMode and disableAutoMode set to "disable" wherever the answer is no.
- 05 The sandbox configuration with both layers on, failIfUnavailable set to true so a missing bubblewrap package cannot silently downgrade a machine to unsandboxed execution, and allowUnsandboxedCommands set to false so a failing command cannot be retried outside the boundary.
- 06 A credential deny list under sandbox.credentials. Anthropic documents that there is no built-in one and that the sandbox's default read policy still allows ~/.aws/credentials and ~/.ssh, so this list is written or it does not exist.
- 07 The network egress allowlist, locked with allowManagedDomainsOnly, plus the residual risk in writing: the built-in proxy decides from the client-supplied hostname and does not terminate or inspect TLS by default.
- 08 An MCP server inventory with a named human reviewer against each entry, because Anthropic states it reviews connectors against its listing criteria but does not security-audit or manage any MCP server.
- 09 The identity binding: forceLoginMethod and forceLoginOrgUUID in managed settings, with the documented exceptions listed rather than glossed — claude setup-token and /install-github-app enforce only forceLoginMethod, and cloud provider sessions are restricted through cloud IAM instead.
- 10 The CI answer. Trust verification is disabled when Claude Code runs non-interactively with the -p flag, which is how it runs in a pipeline, so the CI path is governed by deny rules and a PreToolUse hook rather than by a trust dialog nobody will ever see there.
- 11 The audit trail: OpenTelemetry cost and token metrics exported to a collector you run, plus ConfigChange hooks so a settings change during a session is recorded, and blocked at every scope except managed policy settings.
- 12 The prompt injection exposure statement: what the built-in protections cover, what they do not, and Anthropic's own sentence that no system is completely immune to all attacks, quoted rather than paraphrased away.
Start with the two-week Readiness Blueprint.
Two weeks, €4,900 fixed price. We read your current settings files, run the policy against one real repository and one real CI pipeline, and hand back all twelve artefacts with the gaps named and owned — platform, security or finance against each one.
Twelve documents, three owners, two weeks: that is the unit, not a maturity score. The pack is yours to keep, whoever implements it afterwards. All prices are net and exclude VAT.
Questions a security review opens with
What is in a Claude Code security evidence pack?
Twelve artefacts: the managed settings file and its deployment path per operating system, proof the policy cannot be overridden locally, the deny and ask rule set with rationale, a permission-mode decision, the sandbox configuration, a credential deny list, the network egress allowlist and its residual risk, an MCP server inventory with a named reviewer, the identity binding, the CI answer, the audit trail, and a written prompt injection exposure statement. Twelve documents, three owners — platform, security and finance.
Do permission rules stop prompt injection?
They constrain the blast radius; they do not stop the injection. Anthropic's documentation is explicit that permission rules are enforced by Claude Code and not by the model, so instructions in a prompt or in CLAUDE.md shape what Claude tries to do but never change what Claude Code allows. That is exactly why they help: an injected instruction still has to pass a deny rule that the model has no ability to argue with. What they cannot do is prevent the model from being persuaded in the first place.
Does the Claude Code sandbox stop data exfiltration?
Only as far as your domain allowlist is narrow. The sandbox routes egress through a proxy, pre-allows no domains, and enforces the boundary at the operating system level for every child process. But Anthropic documents that the proxy makes its allow decision from the client-supplied hostname and does not terminate or inspect TLS by default, and warns that allowing a broad domain such as github.com can create a path for data exfiltration through domain fronting. A short allowlist is a control. A convenient one is not.
Who is responsible for auditing the MCP servers our developers add?
You are, and the vendor says so. Anthropic states that it reviews connectors against its listing criteria before adding them to the Anthropic Directory, but does not security-audit or manage any MCP server. An evidence pack therefore needs an inventory of every server in scope with a named human reviewer against each one. Where that list has to be short, allowManagedMcpServersOnly in managed settings makes the allowlist the only one that counts.
What is the CI blind spot in a Claude Code security policy?
Trust verification. Anthropic documents that it is disabled when Claude Code runs non-interactively with the -p flag, which is precisely how it runs in a pipeline. A policy validated by a developer accepting a workspace trust dialog on a laptop therefore proves nothing about the CI path, because that dialog never appears there. Deny and ask rules still apply, so the CI answer is written in deny rules and a PreToolUse hook rather than in trust.
Is forceLoginOrgUUID enough to stop a session authenticating into another organisation?
Not on every path, and the gap is documented. Anthropic states that terminal, VS Code extension and Agent SDK logins enforce both forceLoginMethod and forceLoginOrgUUID, while claude setup-token and /install-github-app enforce only forceLoginMethod and can therefore mint a token in a different organisation. Cloud provider sessions such as Amazon Bedrock authenticate against your cloud provider and are not blocked by either key, so those are restricted through cloud IAM policy instead.
Where do these configuration names come from?
Anthropic's own Claude Code documentation, read on 4 August 2026: code.claude.com/docs/en/security for the prompt injection safeguards and the MCP statement, /permissions for rule precedence and the six permission modes, /sandboxing for the filesystem and network layers and the TLS caveat, /settings for the managed settings paths and precedence, /hooks for ConfigChange, and /authentication for the forceLogin behaviour. Vendor documentation changes, so every name is re-verified against the current release in the engagement rather than trusted from a page.
Next step
Not a sales call. An architecture call.
Thirty minutes with the architect who would actually run the engagement.