Governance & guardrails

The conversation to have once

You leave this lesson with governance deployed, not drafted: five decisions made, managed settings live on every machine, and a one-pager the team can actually read. Governance is not a document, it is a set of decisions - made once, written down, enforced by configuration. Teams that skip the conversation make the same decisions anyway, implicitly, one incident at a time. This lesson is the agenda for the one meeting that prevents that.

• What may Claude do without asking anyone? (the allowlist)
• What always requires a human approval, and whose? (asks plus side-effect skills)
• What may it never do, no matter who asks? (deny rules, hooks, sandbox)
• What data may it see, and what must stay out of reach? (boundaries)
• Who can change these answers, and how do changes ship? (the change process - which is just pull requests on the settings repo)

Managed settings: rules that reach every machine

Project settings govern people who clone the repo. Managed settings govern every machine in the org, regardless of folder, and users cannot override them. Four delivery mechanisms, in priority order:

• Server-managed via the claude.ai admin console - settings reach devices when users authenticate and refresh hourly. Zero infrastructure, Team and Enterprise plans only. The default choice if you are on claude.ai.
• OS policy: a macOS configuration profile (plist) or Windows machine-level registry keys - for orgs with device management (MDM) already in place.
• A managed-settings.json file in the system location (such as /Library/Application Support/ClaudeCode/ on macOS or /etc/claude-code/ on Linux) - simple, works everywhere, needs a way to place the file on machines.
• Per-user registry (Windows HKCU) - the weakest option; listed for completeness.

1. Pick the mechanism: claude.ai admin console if you are on Team/Enterprise; the file if not.
2. Start small: the org-wide deny rules, sandbox enforcement, and the managed CLAUDE.md content. Tighten later with evidence, not upfront with fear.
3. Verify on a machine: /status shows enterprise managed settings and which delivery method they arrived by.
4. Document who holds admin on the console and who reviews managed-settings changes - this is the one config that no pull request gates, so name its owners.

What admins can enforce

The managed layer can lock more than permissions. The controls worth knowing exist, even if you enable only a few:

• Permission lockdown: managed-only permission rules, disabling bypassPermissions mode org-wide, and, if your risk profile calls for it, turning auto mode off with permissions.disableAutoMode: "disable".
• Sandbox enforcement: sandbox on for everyone, fail if unavailable, with org-controlled network domain allowlists.
• A managed CLAUDE.md pushed to every session - org-wide behavioral guidance users cannot exclude.
• MCP allowlists and denylists - which servers may be added at all - plus managedMcpServers to push your reviewed HTTP servers to every machine.
• Marketplace controls: strictKnownMarketplaces allowlists plugin sources (the official one plus your-org/* is the common lockdown), blockedMarketplaces blocks sources, enabledPlugins force-enables or hides a plugin, disableSideloadFlags stops --plugin-dir, and strictPluginOnlyCustomization locks skills, agents, hooks, and MCP to plugin-or-managed sources.
• Hook restrictions: managed-only hooks, and allowlists for which URLs hooks may call.
• Model and effort policy: availableModels (with enforceAvailableModels so it also covers the Default option) and deniedModels decide which models anyone may pick, Enterprise admins can set an org default that shows as "Org default" in /model, maxEffortLevel caps /effort, and modelPricing makes /cost and telemetry use your contracted rates.
• Login restrictions: force the login method and the specific org, so work machines cannot run on personal accounts.
• Version floors: refuse to start below a minimum version, so security fixes actually deploy.

Anything that leaves the building gets a human

One rule outranks every setting on this page: Claude drafts, a human sends. Emails, LinkedIn messages, CRM writes a client sees, invoices, posts, shared pages - anything that leaves the building waits for a named person to approve it. Inside the building, let the agents run.

• Drafts are the deliverable. A skill that could send stops at the draft and says where it is.
• Any send path needs three things: a named target, an explicit --yes flag, and a typed confirmation. We wrote that rule after a bare --send flag sent 14 unapproved replies from real mailboxes.
• Fail closed on relationships: every script that pushes a list calls one shared guard that holds back anyone with an open deal, and refuses to run if the blocklist cannot be read or comes back empty. An empty blocklist is a broken read, not permission.
• Side-effect skills carry disable-model-invocation: true, so Claude cannot decide on its own to run them.
• Shared pages count as leaving: Artifacts on Pro and Max share by public link only, Team and Enterprise can share inside the org. Pages that call MCP connectors cannot be shared publicly at all. Decide who may publish what.

Data boundaries

Permissions decide what Claude may do; data boundaries decide what it can even see. Five boundaries cover most orgs:

• Secrets: never in a repo. Deny rules on .env patterns everywhere, keys from a shared vault, ${VAR} placeholders in any committed config. Plus sandbox denyRead on ~/.ssh and ~/.aws, which are readable by default otherwise.
• Sensitive folders: HR, legal, and finance data live outside the workspace Claude opens in, or behind explicit deny rules. The boundary is the folder line - keep it physical, not aspirational.
• Subprocess hygiene: enable the environment scrubbing setting (CLAUDE_CODE_SUBPROCESS_ENV_SCRUB) so credentials in the environment do not leak into commands Claude runs.
• Network: keep the sandbox domain allowlist short and reviewed - the proxy filters by domain and cannot inspect encrypted traffic, so a broad allowlist is weaker than it looks.
• External content: any connector that pulls web pages or emails into context is a prompt-injection surface. Pair read-external connectors with tight write permissions.

Audit habits that take an hour a month

Governance decays silently: allowlists creep, an experiment becomes permanent, the admin list grows. One scheduled hour a month catches all of it while it is still small.

1. Monthly, the named owner reviews: the permission allowlists (anything creep in?), the MCP server list on a sample of machines (/mcp), installed plugins, and who holds admin.
2. Review the skills library diff for the month - frontmatter first: any allowed-tools widened, any disable-model-invocation dropped, any model pin removed? Run /skill-doctor for each skill's context cost and how often it is used; prune what nobody runs.
3. Check /status on two random machines: managed settings present and arriving by the expected method.
4. Skim usage in the analytics dashboard for anomalies - a machine doing 10x the team average is either your best automator or a problem; both are worth knowing (next lesson).
5. Write five lines of findings where the team can see them. An audit nobody reads is theater.

Do this now

Sources and further reading

• Claude Code documentation
• Claude Code org admin settings
• Manage plugins for your organization
• Permission modes