14 Oct 2026 · Constance Ibe-Whitmore (editorial persona) · Governance and leadership · on threat.cafe

Before you approve coding agents org-wide: a seven-condition rollout gate for security leaders

A security leader asked to approve AI coding agents for every developer should approve when seven conditions are verifiably met: an inventory of agents and their add-ons, enforced managed settings, a documented decision on the default permission mode, an artifact policy for packages, skills and MCP servers, egress limits, a decision log, and a tested incident runbook with a kill switch. Each condition produces evidence an auditor can inspect. None requires blocking adoption while it is built, and most can be met in days.

What changed, and why sign-off is now unavoidable

Two facts moved this decision from engineering to security in 2026.

First, defaults moved toward autonomy. From 14 August 2026, new Claude Code sessions on Pro, Max and Team plans run in auto mode, where a classifier rather than a person reviews most actions. On 7 August Anthropic said auto mode "remains opt-in for now" on Claude Enterprise and the API, and that it planned to make it the default there "in the coming month" (Anthropic, 7 August 2026). Confirm the current state for your tenant before relying on either.

Second, refusal is no longer a safe answer. Verizon's 2026 Data Breach Investigations Report found that frequent use of AI tools by employees rose from 15% to 45% in one year, and that third parties were involved in 48% of breaches (Verizon, 19 May 2026). A blanket "no" pushes developers to personal accounts the organisation cannot see. A gate with criteria gives engineering a path to "yes" and gives security evidence.

Scope: what this gate covers

The gate applies to agentic coding tools that run commands, edit files and install dependencies on developer machines or in CI: Claude Code, Cursor, GitHub Copilot's agent features, and similar. It does not cover chat-only assistants without tool access. It is vendor-neutral by design; where a vendor setting is named, it is an example of how to satisfy the condition, not the only way.

The modal verbs are deliberate. Must means the rollout should not proceed without it. Should means proceed only with a dated plan to close it. May marks practices that strengthen the position but are not gating.

The seven conditions

1. Inventory (must)

The organisation must be able to list which agents are installed, on which machines, and which skills, plugins and MCP servers each one uses. Anthropic's enterprise guidance for Skills recommends an internal registry recording purpose, owner, version, dependencies and evaluation status for each Skill (Anthropic, Skills for enterprise). The same structure serves MCP servers.

Evidence: an export of the inventory, dated, with an owner per item.

2. Managed tenancy and settings (must)

Developers must use organisation accounts, and security-relevant settings must be delivered through a channel users cannot override. In Claude Code, managed settings sit at the top of the precedence order, and "nothing in your own settings files or --settings overrides a managed key" (Claude Code settings). Keys such as allowManagedPermissionRulesOnly, allowManagedHooksOnly and allowManagedMcpServersOnly make the managed layer the only source for permission rules, hooks and the MCP allowlist (All settings). GitHub added allowedMcpServers and deniedMcpServers to enterprise managed settings for the Copilot app, Copilot CLI and VS Code, with policies that fail closed (GitHub changelog, 6 August 2026).

Evidence: the managed configuration file or policy, and a test showing a user-level change does not override it.

3. A deliberate default-mode decision (must)

The organisation must decide, in writing, whether agents run with per-action approval, a classifier-reviewed mode such as auto mode, or a restricted mode, and for which teams. Anthropic's own data shows users approve 97% of permission prompts, and that in a test with 1,053 testers human review caught 13.6% of a planted dangerous command while the classifier blocked 89%. The same vendor says auto mode "does not eliminate risk." Neither option is a control by itself. The decision record should name the residual risk accepted. Claude Code exposes disableAutoMode and permissions.disableBypassPermissionsMode for organisations that choose to restrict modes.

Evidence: a signed decision record with the mode, the population, the residual risk and the review date.

4. Artifact policy (must)

Agents install packages, fetch skills and connect MCP servers. The organisation must define what happens for three states: known malicious, unknown, and reviewed. A known-bad artifact must be blocked by a deterministic rule. Unknown artifacts must have a defined handling (log, warn or human sign-off). Vendor scanning should not be treated as complete coverage. Anthropic documents that Enterprise skill scanning does not cover Skills uploaded through the API, Skills already present when scanning was enabled, or organisations with CMEK, zero data retention or HIPAA-readiness configurations, and advises: "Never deploy Skills from untrusted sources without a full audit."

Evidence: the policy file, its version, and a test showing a listed artifact is blocked.

5. Egress and sandbox defaults (should)

Agents and CI runners should run with network access limited to known destinations where the workflow allows. In Claude Code, sandbox.network.allowedDomains pre-allows named domains for sandboxed commands. Egress limits contain the damage when the other conditions miss something, because malicious packages often need the network to fetch a second stage or send data out. The March 2026 axios dropper, for example, contacted attacker infrastructure to fetch a platform-specific payload (StepSecurity).

Evidence: the allowlist, and a blocked-connection test from a sandboxed session.

6. Decision logging (must)

Every block, warn, allow and human approval should be written to a log that records the policy version that produced it. Without this, the organisation cannot answer the first question in any incident review: what did the agent do, and why was it allowed?

Evidence: a sample of log entries showing tool, artifact, decision, policy version and timestamp.

7. Incident runbook and a tested kill switch (must)

A runbook for "an agent installed something malicious" must exist, name the agent-specific credentials to rotate, and have been walked through once. The kill switch, a managed setting or device policy that stops agent execution across the fleet, must have been tested on a pilot group.

Evidence: the runbook, the date of the tabletop, and the result of the kill-switch test.

The scorecard

Condition                     Level   Green                          Amber (acceptable with date)       Red
----------------------------  ------  -----------------------------  ---------------------------------  ------------------------
1 Inventory                   Must    Agents + add-ons, owners       Agents listed, add-ons partial     No list
2 Managed settings            Must    Managed keys locked, tested    Managed, not yet tested            Personal accounts
3 Default-mode decision       Must    Signed record, residual risk   Decided, not documented            Vendor default by drift
4 Artifact policy             Must    Known-bad blocked, unknown     Known-bad blocked, unknown         No rule
                                      handling defined               undefined
5 Egress / sandbox            Should  Allowlist enforced             Plan with date                     Open egress, no plan
6 Decision log                Must    All decisions + policy version Blocks logged only                 No log
7 Runbook + kill switch       Must    Tabletop done, switch tested   Runbook written, untested          None

The rollout should proceed when every "must" is green or amber with a closing date inside 30 days and no condition is red. That rule lets engineering start while security finishes, which is the point.

Ownership and time

Each condition should have one named owner. In most organisations the platform or developer-experience team owns conditions 1, 2, 5 and 6; security owns 3, 4 and 7. Conditions 2, 4 and 6 are configuration work measured in days when managed settings are already in place for other tools. Condition 7 needs one tabletop session. Condition 1 is the slowest when agents have already spread without registration; the 45% shadow-AI figure suggests many organisations start there.

Presenting the gate to engineering

The gate should be presented as the list of things security will stop asking about once they exist. Each condition replaces a recurring question with an artifact. Engineering leaders generally accept a short list of verifiable conditions more readily than an open-ended review, because a list has an end.

Ambiguities to resolve with counsel and auditors

Three questions remain open and should be raised internally before sign-off. Whether a classifier-reviewed mode satisfies "human oversight" language in existing control frameworks and customer contracts. Whether cyber insurance policies respond to harm caused by an agent acting within its granted permissions with no external attacker; the policy wording should be checked with the broker rather than assumed. And whether agent decision logs fall under existing retention schedules. This article is general information, not legal advice; take these questions to counsel and to your auditor.

To build condition 4's known-bad rule on public data, the threat.cafe board lists documented malicious agent artifacts with sources and finder credit.

Sources

#ciso #rollout #managed-settings #governance #coding-agents

All posts