Claude Code security for CISOs: govern developer authority before it becomes production authority

Start with the authority map, not the acceptable-use policy

A policy that permits Claude Code for development tells employees what the organization intends. It does not establish which cloud account a terminal can modify, whether a package script reads outside the repository, or where an MCP tool sends a document. Before approving a rollout, ask the platform team to show the effective permissions of a representative developer session. Include inherited environment variables, credential helpers, mounted directories, shell startup scripts, and authenticated command-line tools.

Make the inventory specific enough to support a decision. Record the repository, data classification, operating system, Claude Code surface, model route, installed extensions, and owner of each connected service. A repository containing synthetic fixtures and no production credentials is a different deployment from a payments monorepo on an administrator's laptop. They should not receive the same autonomy because they use the same agent brand.

For the CTO, the useful output is an approved development lane with known boundaries. For the CISO, it is a record of which consequences remain possible inside that lane. For the CIO, it is a manageable fleet configuration rather than hundreds of individually negotiated exceptions. This inventory also creates the denominator for coverage reporting: the number of in-scope sessions, not the number of purchased seats.

Understand what Claude Code's native controls actually govern

Anthropic documents tool permissions, permission modes, managed settings, and the relationship between permissions and sandboxing. It also distinguishes instructions in a prompt or CLAUDE.md from permissions enforced by the application. These controls should remain part of the baseline. A behavioral instruction is useful context, but it is not a substitute for a denied tool operation or a constrained operating-system environment.

Hooks are another trust decision. Claude Code can run configured programs at lifecycle events, including before supported tool operations. A security hook is executable software with its own file permissions and update path. Review where it comes from, who can edit it, and how the installed agent version handles its result. Do not let an agent modify the control that is supposed to govern its next action.

A failure scenario: a test repair crosses into production

Consider a hypothetical exercise, not a reported customer incident. Claude Code is asked to repair a staging integration test. A log recommends refreshing credentials. The agent finds a cloud profile on the workstation, invokes an account-management command, and proposes deleting what it describes as a stale resource. The profile happens to point at production. Every step can look locally plausible while the final consequence exceeds the original task.

The first prevention point is credential scope: the session should not possess a production deletion capability. The second is environment identification: tooling should make the resolved account and resource explicit. The third is a decision before execution on a supported action path. The approval question is not whether the developer trusts Claude Code. It is whether this particular resource should be deleted for this particular task, with a tested recovery path.

Use a disposable cloud project or local stand-in for the exercise. Make the names deliberately similar enough to expose target confusion, while ensuring no real production authority is present. A successful result is an interrupted action and a legible record of the target. Merely receiving an agent apology after a mutation is evidence that the control arrived too late.

Where OpenLeash helps, and where the boundary remains

OpenLeash's published coverage lists Claude CLI and Claude Code for VS Code with installable hooks and automatic routing for supported provider traffic through the local proxy. On an instrumented action path, OpenLeash can evaluate the proposed operation against configured protections and rules, block a clear threat, or request a human decision when the action is risky or ambiguous. The operational value is a common decision layer across supported agents, instead of relying only on each developer's accumulated approvals.

That statement has a boundary. A configured hook does not prove every subprocess, unofficial extension, remote runtime, or network request is intercepted. Provider-traffic visibility and pre-execution tool control are different capabilities. A test of a file operation does not establish coverage for a cloud API mutation. Verify the exact operating system, agent release, launch path, and action family before calling a workflow protected.

Business Leash Cloud is the shared management surface; the Desktop client remains the employee's local agent connection. Use the organization view for rollout ownership and policy review, then test enforcement on the actual endpoint. Keep native restrictions, endpoint management, short-lived credentials, and repository protections in place. OpenLeash adds an action checkpoint; it does not repair an overprivileged cloud role or guarantee that generated code is correct.

A practical pilot the engineering team can execute

Begin with one team and a repository whose data you can safely use for testing. Select a task that developers already perform frequently, such as adding a unit test or updating an internal API client. Agree on an acceptable completion criterion before introducing security prompts. Otherwise, every interruption will be blamed on the control even when the underlying task was underspecified.

Install the supported OpenLeash protection, restart the relevant agent session if configuration changed, and exercise the exact entry point employees use. Record a permitted harmless operation, a deliberately prohibited operation against disposable data, and an operation that requires a decision. Confirm that denial prevents the side effect; do not settle for a notification. Repeat after a fresh session and after the configuration is reapplied through device management.

A two-week pilot is a reasonable planning example, not an OpenLeash deployment requirement. Let observed workflow coverage determine the pace. If the agent uses a tool that does not emit the expected event, keep that workflow restricted and investigate the integration rather than expanding the allowlist to make the warning disappear.

• Permit: read a synthetic fixture and edit a disposable source file inside the approved repository.
• Deny: attempt to read a designated test secret or remove a protected test directory.
• Ask: propose an external publication or repository push using a harmless test destination.
• Recovery: revoke the test credential, terminate the session, and restore the fixture from a known copy.

Design approval ownership before increasing autonomy

The CISO should define consequence classes; the engineering owner should define who understands each resource. A developer may be able to approve a local refactor without being the right person to approve a production database change. Use existing change-management and service ownership records to decide who must review an action. Verify what the installed approval workflow can enforce, and use the existing deployment gate where a separate approver is required.

An approval should expose the operation, target, environment, destination, and expected side effect. If those facts are unavailable, the operator lacks enough information to accept the risk. Narrow the requested action or require a manual workflow. Avoid treating a broad natural-language promise as equivalent to approval of resolved arguments. Recheck changed parameters and retried operations during the pilot rather than assuming the first decision covers them.

Set an exception expiry and a review owner. A temporary grant for a migration can become an unnoticed permanent capability when it is stored in a developer configuration. Closing the exception means removing the permission and testing the removal. It is not complete when the ticket says the migration finished.

What to report to the board and what to investigate

Report protected workflows against an explicit inventory, approval turnaround for consequential actions, attempted boundary crossings, configuration drift, and recovery-test results. Present developer cycle time alongside those measures. An increasing block count can reflect a broader pilot, a bad rule, or a real threat; it is not automatically a security improvement. Sample decisions and explain what each metric can actually establish.

When something goes wrong, first stop the affected session and revoke the authority it used. Preserve the relevant action record, agent version, configuration, task context, and target-system logs with appropriate access restrictions. Determine whether the operation crossed a supported interception point and whether the policy matched the resolved action. Investigate both the agent's reasoning path and the organizational permission that made the consequence possible.

Executive questions before the next rollout cohort

Can we approve Claude Code without granting access to production? Usually the architectural goal should be yes: separate coding work from deployment authority, then make any escalation deliberate. If a team says production access is indispensable, ask it to identify the exact operation and explain why a narrower service workflow cannot perform it.

Does OpenLeash replace Anthropic's permissions? No. Native permissions and sandbox boundaries reduce what the agent can reach; OpenLeash adds policy evaluation and approval controls where its integration supports the action. Evaluate the layers together with a reproducible fixture, rather than disabling one layer to demonstrate another.

What should happen next week? Name a pilot owner, select the repository and endpoint cohort, document three consequential action classes, and schedule the denial and recovery demonstrations. Expansion should follow evidence that the real workflow is both useful and bounded. That is a more defensible leadership decision than declaring every coding assistant either safe or forbidden.