Claude Code Features in 2026: What Each One Adds to Your Attack Surface

Claude Code features now extend well past a chat window and a file editor. Each release adds another extension type - skills, subagents, agent teams, plugins, hooks, MCP server definitions, and code intelligence - and every one of them is two things at once: a capability for the developer, and an AI artifact that security has to see. The gap between those two views is the whole problem. A developer installs a plugin to save time; the security team inherits a bundle of skills, subagents, hooks, and MCP servers it never reviewed, on a machine it cannot inspect.

There is one place where all of this becomes enforceable rather than merely observable: the PreToolUse hook, which can return a decision before a tool call runs. That single mechanism is why the feature list below matters to a defender and not only to a power user. This post walks the current and expanded Claude Code features one at a time, and for each names the security implication and what to govern. The underlying rules are covered in how Claude Code permissions actually work and the configuration in the permissions and hooks hardening guide; this piece is about the surface those controls now have to cover.

Every capability here is real and documented. None of it is a flaw. The point is that each addition widens the set of artifacts a security team needs to inventory across a fleet, which is the problem Anomity's endpoint inventory exists to solve. Facts first; we close on making them verifiable everywhere.

What do skills add, and what do you govern?

A skill is a SKILL.md markdown file of knowledge and workflows. It can be invoked explicitly with /name, or auto-loaded by Claude when it judges the skill relevant to the task. Bundled skills include /code-review, /batch, and /debug. A skill can run in the current context or in an isolated subagent via context: fork, and disable-model-invocation: true hides a skill until it is invoked manually.

The security implication is supply chain. Auto-loading means a skill can shape behavior without a developer typing anything, and a skill delivered inside a plugin can carry instructions and behavior that the person who installed it never read. This is the surface behind skill scanning and skilljacking, covered in the agent skills security primer and in the work on the NVIDIA Skillspector agent skill scanner. What to govern: which skills exist on each endpoint, whether each is set to auto-load or held behind disable-model-invocation, and where it came from - not the fact that skills are enabled in the abstract.

How do subagents change the actor count?

A subagent runs in an isolated context window and returns only a summary to the parent session. It can preload skills of its own through a skills: field, and its scope follows a precedence of managed, then CLI flag, then project, then user, then plugin. That isolation is useful, but it also means every subagent is another autonomous actor making tool calls under its own context.

The governance implication is that the number of actors to inventory is no longer one per session. A subagent that preloads a skill is a place where both a subagent artifact and a skill artifact combine, and only the summary comes back, so what it did in its own context is not visible upstream. What to govern: enumerate subagents as first-class actors and the skills they preload. The broader question of which skills are worth trusting is one we take up in the top AI agent skills of 2026.

What about agent teams?

Agent teams are multiple independent Claude Code sessions that message each other and share a task list. The feature is experimental and disabled by default, so it is not something most fleets are running today. It is worth naming anyway, because the direction is clear: coordination between sessions multiplies both the number of autonomous actors and the paths by which one actor's output becomes another's input.

What to govern when it is enabled: treat each session in a team as its own actor with its own configuration, and watch the messaging surface as a place where instructions cross between contexts. Answering "how many agents are actually running, and in what configuration" across a fleet is precisely the question in auditing Claude Code across a fleet.

Hooks: attack surface and enforcement point

Hooks fire on lifecycle events, including PreToolUse, PostToolUse, and SessionStart. A hook can run a shell command, an HTTP request, an LLM prompt, or a subagent, and its output can enter the model context. Crucially, a PreToolUse hook can block an action: it returns a decision before the tool call runs. That is enforcement, not a request for confirmation.

This makes hooks the most double-edged feature in the list. As an attack surface, a hook runs code automatically on a lifecycle event, and because hook output can enter context, an untrusted hook is also an injection path. As a control, the same PreToolUse mechanism is the one reliable place to inspect a resolved tool call and stop it. That is why it is the point Anomity's runtime governance is built around. What to govern: inventory every registered hook, treat the hook script and the settings file that registers it as audited artifacts, and confirm the PreToolUse hook you rely on actually returns a deny on the cases you care about. The exact mechanics of writing that hook are in the permissions and hooks hardening guide referenced above.

Plugins and marketplaces: the supply chain in one install

A plugin is a versioned bundle that can contain skills, subagents, slash commands, hooks, output styles, and MCP server definitions. Plugin skills are namespaced, for example /my-plugin:review, and plugins are distributed through marketplaces. One install can therefore add several artifact types at once.

The security implication follows directly: a plugin is a single trust decision that expands into many artifacts, each of which you would otherwise review on its own. A marketplace is a distribution channel, which is a supply-chain surface in the same sense a package registry is. What to govern: expand each installed plugin back into the skills, subagents, hooks, and MCP servers it contributes and inventory those individually, rather than trusting the bundle wholesale. This sits inside the wider practice of securing AI coding agents and CLIs.

MCP and tool search

MCP connects Claude to external services. Tool search is on by default, so idle MCP tools cost little context even when many are configured. That is good for usability, and it also means the visible context cost of adding an MCP server no longer signals how many tools are present. A fleet can accumulate MCP servers without the friction that used to make them noticeable.

What to govern: each MCP server is an artifact to inventory in its own right, including where its definition came from (often a plugin) and what it connects to. Because different agents expose MCP and permissions differently, the cross-tool picture matters, which is the subject of Claude Code versus Codex versus Cursor permission models.

Code intelligence and managed settings

Code intelligence adds language-server navigation and diagnostics through a code-intelligence plugin. It is a capability upgrade, and because it ships as a plugin it inherits the same governance surface as any plugin: it is one more bundle to expand and inventory.

Managed settings are the other end of the story. Features layer across managed, user, and project settings, and managed policy can override user and project settings. That precedence is what makes managed settings the enterprise control point: a policy set once applies everywhere it is received, and no lower level can loosen it. The catch is the same one that shadows every per-machine control, including the loosest permission modes discussed in what dangerously-skip-permissions really does - the policy only exists on machines that actually received it. Getting managed settings onto every endpoint is a rollout problem covered in deploying Claude Code across a fleet.

How Anomity governs the Claude Code extension surface

Every feature above is per-endpoint by design. The skills live in files on a laptop, the subagents and their preloaded skills are local configuration, the hooks live next to the settings that register them, the plugins were installed from a marketplace onto individual machines, and the managed policy only applies where it was received. No single one of these gives security a view across more than one endpoint, and that is the blind spot the whole feature set keeps widening.

Anomity is the layer that closes it. A lightweight, unprivileged Endpoint Sensor runs on every managed endpoint across Windows, macOS, and Linux and discovers and inventories eight AI artifact types: AI agents, MCP servers, extensions, plugins, skills, secrets, hooks, and CLIs. That maps directly onto the Claude Code feature surface, so a plugin is expanded into the skills, subagents, hooks, and MCP servers it actually contributes. The sensor sends metadata only over HTTPS to Anomity Cloud, never source or prompts, and secrets are redacted on the endpoint before anything leaves it. Where an agent exposes a hook, such as the Claude Code PreToolUse hook, Anomity returns an allow, deny, or log decision before the tool call runs. Every change and every decision becomes a queryable 90-day audit trail routed to your SIEM, Slack, email, or Jira, and the platform is SOC 2 Type II. It complements EDR, XDR, DLP, network, and GRC controls rather than replacing them. See how it works for the deployment shape and where it sits next to your existing stack.

You can't govern what you can't see.

Each new Claude Code feature is a genuine improvement for the developer and a new artifact for the security team, and the two views only reconcile when the artifacts are inventoried and the hook is where enforcement lives. The same pattern is playing out across the ecosystem, which is why we tracked it separately in the new OpenAI Codex features and their security implications, and why the program-level framing matters as much as the per-feature detail - see the AI security framework for that framing. If you want to see the Claude Code extension surface inventoried and governed across your fleet instead of guessing at it, book a 30-minute demo.