Anthropic · CLI agent
Claude Code
Anthropic's terminal-based coding agent, and the most configurable — and therefore most governable — AI surface most engineering organisations run.
What you are actually governing
Claude Code is unusual among AI surfaces in that it was designed to be configured rather than merely used, which is good news for a security team. Settings resolve through a documented hierarchy — enterprise-managed policy, then project settings, then local overrides — and enterprise-managed settings are intended to be authoritative over what a user can change. That gives platform teams a real place to stand.
The extension surface is correspondingly wide. A session loads memory files, may load Agent Skills on demand, runs hooks at lifecycle events, connects to MCP servers, and can dispatch subagents. Each is a separate artifact class with a separate distribution story, and each changes agent behaviour. An organisation that has reviewed its MCP servers but not its hooks has reviewed the less dangerous half.
Hooks deserve specific attention because they are both the strongest native control and the sharpest supply-chain risk. A pre-tool-use hook can deterministically block an action before it happens — genuinely better than prompting — and it is a shell command running with the engineer's full permissions and no confirmation. The control and the risk are the same mechanism, which is why hooks are the artifact class most worth distributing centrally and pinning.
The honest limitation of native controls is not their power but their scope: they are per-machine. The settings hierarchy governs one laptop's configuration. It does not tell you what the other two hundred laptops are running, whether the skill an engineer installed last week was reviewed, or which asset versions were active in the session that touched production. Those are fleet questions, and the vendor's local configuration model does not answer them.
Artifact classes this surface loads
Each of these changes what the agent does, and each arrives through a channel with no dependency review. This is the inventory a governance programme has to cover — not a feature list.
- CLAUDE.md memory files
- Agent Skills
- Hooks
- MCP servers
- Subagents
- Slash commands
- Plugins
What Anthropic genuinely controls
Documented controls worth configuring fully before buying anything. Every one is cited to Anthropic's own documentation below.
- Managed settings hierarchy
Enterprise-level policy settings take precedence over project and user settings, so a platform team can set a floor that a local user cannot lower.
- Permission rules for tools
Allow, ask and deny rules govern which tools and which arguments are permitted, configurable per project and centrally.
- Hooks
Shell commands at lifecycle events. Pre-tool-use hooks can deny an action before it executes, which makes policy deterministic rather than advisory.
- Sandboxing
Filesystem and network restriction for agent execution, reducing what a misled session can reach.
- MCP server allowlisting
Which servers may be connected can be constrained through settings rather than left to each engineer.
What is still open once those are configured
Not criticism of the product — the honest boundary of a per-machine configuration model. These are fleet questions, and local settings were never designed to answer them.
- No fleet inventory
Settings describe intent on one machine. Nothing natively reports which skills, hooks and servers are actually loaded across every machine in the organisation.
- No artifact vetting
Permission rules govern what the agent may do. They say nothing about whether the skill or hook doing it was reviewed, or who published it.
- No version pinning across the fleet
Artifacts pulled from repositories or plugin sources track whatever is there now. There is no lockfile establishing that the reviewed version is the installed one.
- No cross-surface view
The same MCP server is probably also connected to other tools in the company. Claude Code's configuration cannot see or govern those.
- No session-to-artifact attribution
During an incident, mapping 'this session did that' to 'these artifact versions were active' requires joining data the local configuration does not retain.
Frequently asked
- Can enterprise settings stop an engineer installing their own MCP server?
- Managed settings are designed to take precedence over user settings, so a policy can constrain which servers are permitted. What it cannot do is tell you what was attempted, or give you an inventory of what every machine currently has — enforcement and visibility are separate problems.
- Are hooks a security control or a security risk?
- Both, via the same mechanism. A hook is the only way to deterministically block an agent action, and it is a shell command running with the user's full permissions. That is exactly why hooks should be centrally distributed, pinned to reviewed versions, and diffable against what each machine actually has.
- Does sandboxing remove the need to vet skills and MCP servers?
- No. A sandbox limits what a compromised session accomplishes; vetting stops known-bad artifacts arriving in the first place. Teams that rely on only one of the two are covered against half the problem.
Sources
Compiled from Anthropic's own documentation on 2026-07-25. Products in this category change quickly — verify against the source before a decision depends on a specific mechanism.