TL;DR: The move into code, Cowork, skills, MCP servers, and agent workflows creates a security gap unless teams can inspect prompts, tool calls, and tool outputs before action is taken, according to Cato Networks. The governing assumption is shifting from session visibility to runtime control over what an agent can see, request, and do.
At a glance
What this is: This is a Cato Networks analysis of why Claude security now has to cover prompts, skills, MCP servers, and tool execution, not just user access.
Why it matters: It matters because IAM and security teams need visibility and policy enforcement at the point where an AI system can see data, request actions, and execute work.
Context
Claude is shifting from a conversational assistant into an execution layer that can research, reason, build, and act across business workflows. That changes the security problem from protecting a chat interface to governing the tools, skills, and protocol connections that let the system take action.
For identity and access teams, the key issue is not whether the model is useful. It is whether the controls around Claude can still define what the system is allowed to see, request, and do once tool use, MCP servers, and agent workflows are part of the operating model.
The article is about AI security for Claude, but the governance question reaches across NHI, autonomous, and human identity programmes because the same runtime permissions, auditability, and lifecycle concerns now sit between users, agents, and the tools they invoke.
Key questions
Q: How should security teams govern Claude Enterprise agent access when MCP is involved?
A: Treat MCP as both a transport layer and an execution surface. Map local stdio and remote HTTP paths separately, classify tools by capability, and apply enforcement where the agent actually acts rather than where the session merely exists. Governance fails when teams assume one approval model covers every agent path.
Q: Why do legitimate agent tools become risky when combined?
A: Because the combined permission set can exceed the task boundary even if each tool is acceptable on its own. One tool may provide access to content, another may change files, and together they can create an unsafe path that no single approval review would have flagged.
Q: What are the signs that runtime AI controls are not enough?
A: Common warning signs include unexplained tool usage, policy drift across sessions, repeated dependency on broad inherited access, and incidents that can only be explained after the fact. If a team cannot see what data, tools, and permissions were active when an action occurred, runtime controls are too weak for production governance.
Q: How do Claude-style agent controls differ from traditional application security?
A: Traditional application security focuses on the app, the endpoint, or the network path. Claude-style controls have to govern a live interaction chain that includes prompts, model responses, tool input, and tool output, because the security decision happens while the system is acting, not only when it starts.
Technical breakdown
How skills and MCP servers expand the agent attack surface
Skills are reusable instruction packages that can connect an agent to tools, data sources, or workflows. MCP servers do something similar by standardising how a model or agent reaches external systems. The security issue is that these attachments are not neutral. A malicious or poisoned skill can shape instructions, while an MCP server can return data that nudges the agent into unsafe actions. Once tool access and model reasoning are linked, the attack surface becomes the combination of capability plus trust in the returned output.
Practical implication: treat every skill and MCP server as an access-bearing component with its own review, approval, and revocation path.
Why runtime inspection matters more than prompt-only controls
Prompt filtering alone is too shallow when an AI system can chain a prompt into tool calls, then into outputs that trigger further actions. Runtime controls inspect the interaction as it happens, which means policy can cover the user prompt, the model response, the tool input, and the tool output. That matters because unsafe behaviour often emerges in the handoff between steps, not in the initial request. In this model, protection is about governing the full action path instead of trusting the first turn of the conversation.
Practical implication: enforce policy at each interaction step, not only at the first prompt or login event.
How shared permissions can make legitimate tools unsafe together
The article points to a classic composition problem: individually legitimate components can become unsafe when their permissions are combined. An agent paired with a filesystem MCP and another tool may gain enough reach to alter files or execute code after a prompt-injection event. The failure mode is not that each tool is malicious on its own. It is that the combined permission set exceeds the task boundary the agent was supposed to stay within. That is a governance problem, not just a detection problem.
Practical implication: review the effective permission envelope created by tool combinations, not only each tool in isolation.
Threat narrative
Attacker objective: The attacker wants to steer the agent into unsafe tool use so it can exfiltrate data, alter files, or execute code under legitimate-looking access.
- Entry occurs when a user or internet-sourced package introduces a skill or MCP server into the agent environment.
- Credential or capability abuse follows when the agent trusts the tool or the returned content and accepts manipulative instructions.
- Escalation happens when multiple legitimate tools combine to grant actions beyond the intended task boundary, including file alteration or code execution.
- Impact is created when the agent performs unsafe work at business speed before a human can notice the composition risk.
Breaches seen in the wild
- Nx s1ngularity attack 2025: Attackers stole Nx's npm token via a GitHub Actions flaw and shipped malware that stole 2,349 secrets and abused developers' AI CLIs.
- Microsoft SAS token exposure 2023: An over-permissive Azure SAS token in a Microsoft AI GitHub repo exposed 38TB, including workstation backups and Teams messages, for 3 years.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Tool governance is now the control plane for Claude security: once an assistant can act through skills, MCP servers, and workflow tools, the primary security question shifts from conversation safety to delegated capability control. The problem is no longer only what the model says, but what it can reach and trigger through attached tools. Practitioners should treat tool governance as an identity and access problem, not a feature-management problem.
The effective privilege of an AI system is the sum of its connected parts: a single skill or MCP server may look harmless, but the combined permission envelope can exceed the intended task boundary. That is why composition risk matters more than isolated approval. The implication is that access review has to move from single-component checks to path-based analysis of what the agent can do end to end.
Runtime policy is the only realistic boundary when agents can chain actions quickly: static allowlists and pre-use review cannot keep pace with systems that inspect, call, and act in one interaction flow. Claude-style environments need enforcement that follows the prompt, response, tool input, and tool output as one governed session. Practitioners should assume the security boundary is now execution time, not configuration time.
Named concept: agent tool blast radius. The article points to a new blast-radius problem created when skills, MCP servers, and tools are granted to the same agent. That assumption fails when one agent can combine multiple benign permissions into a materially larger action surface. The implication is that teams must rethink how much outcome space they are delegating, not merely which tool names they approve.
AI security programmes now have to absorb NHI-style lifecycle discipline: skills and MCP servers behave like managed non-human capabilities, with onboarding, posture review, and revocation needs that look more like identity governance than classic app filtering. The governance gap appears when these artefacts are added quickly but never reassessed as the agent ecosystem changes. Practitioners should align AI security reviews with the lifecycle of the capabilities the agent can use.
From our research library:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
- Read next: Agentic AI Security Guide
What this signals
Claude-style environments move AI security into the same governance territory that identity teams already manage for non-human access. Once a system can combine tools, skills, and protocol connections at runtime, the practical question becomes who owns the capability, how it is reviewed, and when it is revoked.
Agent tool blast radius: the useful mental model is not whether a tool is approved, but how much extra reach the agent gets when approved tools are chained together. That is where policy, auditability, and revocation need to converge, because the security boundary is now the action path rather than the user prompt.
Enterprises that are already building NHI governance discipline should reuse the same instincts here: inventory, posture review, scoped access, and lifecycle offboarding. The difference is that Claude-like systems compress those steps into runtime, which makes pre-use governance incomplete on its own.
For practitioners
- Inspect the full tool chain Map every Claude-connected skill, MCP server, and workflow tool to the actions it can trigger, then compare that effective reach against the intended task boundary.
- Enforce runtime policy across the session Apply controls to the prompt, model response, tool input, and tool output so unsafe behaviour can be stopped after the first request but before action completion.
- Review combined permissions, not isolated approvals Validate whether two individually legitimate tools become unsafe when used together, especially when one tool can change files or execute code.
- Track skills and MCP servers as governed capabilities Create an inventory for agent capabilities with ownership, posture review, and revocation steps so added tools do not remain permanently trusted.
Key takeaways
- Claude now sits inside an action path that includes tools, skills, and MCP servers, so security has to govern what the agent can do as well as what it can read.
- The article’s core risk is composition, where individually legitimate capabilities become unsafe once combined in a single agent workflow.
- Runtime inspection, capability inventory, and permission boundary review are the controls most directly implied by this shift.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | The article warns that internet-sourced skills and MCP servers can manipulate an agent through external capabilities. |
| NHI-05 — Overprivileged NHI | The article shows how combined tools can give an agent more effective reach than its intended task boundary. | |
| NHI-08 — Environment Isolation | Claude runs across different workflows and endpoints, so protection has to preserve boundaries between sessions and contexts. | |
| Recommendation — Review third-party skills and MCP servers as trusted integrations and revoke any capability that changes agent behaviour unexpectedly. Limit the effective permission envelope of every agent by testing how tools behave in combination, not in isolation. Separate agent contexts and deployment scopes so one session cannot inherit trust or access from another. | ||
| OWASP Agentic AI Top 10 | ASI02 — Tool Misuse | The article centers on agents using tools in ways that can exceed the intended workflow boundary. |
| Recommendation — Constrain tool use so the agent cannot invoke actions outside the approved workflow or task context. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Malicious integrations and chained permissions can pivot from access to broader downstream action. |
| Recommendation — Map agent tool abuse to credential access and lateral movement paths, then monitor for unexpected downstream reach. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about governing entitlements across prompts, tools, and outputs. |
| Recommendation — Apply entitlement controls to agent toolchains so only approved capabilities can be exercised at runtime. | ||
Key terms
- Agent Tool Chain: An agent tool chain is the sequence of tools, APIs, and delegated actions an AI agent can invoke to complete a task. Security risk rises when the chain is long, poorly bounded, or able to cross data and privilege boundaries without intermediate checks.
- Runtime Policy Enforcement: Runtime policy enforcement evaluates a request at the moment it is executed instead of relying only on preconfigured permissions. For AI agents, this allows decisions to reflect current context, target sensitivity, and behavioural signals rather than static assumptions.
- Agent Tool Blast Radius: The amount of system reach an AI agent has through its callable tools, routes, and connected services. The blast radius grows when tool exposure is broad, policy is weak, or logs cannot reconstruct the execution path. Teams should treat it as a governance boundary, not a convenience metric.
- Skill Posture: The security state of a reusable skill or capability package, including who owns it, what it can access, and whether it has been reviewed for misuse. In agentic systems, skill posture is a governance signal, not a static approval label.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on August 14, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org