AI agent attack surface grows through MCP and Skill risk

At a glance

What this is: This is an analysis of AI agent attack surface that shows MCP servers and Skills create different governance layers, with the risk concentrated in capabilities, permissions, and invisible execution paths.

Why it matters: It matters because IAM, NHI, and agentic AI programmes need to govern what agents can do, what they can reach, and what they do without leaving an audit trail.

By the numbers:

• Noma Security analyzed 200+ of the most popular MCP servers and agent Skills in production.
• 76% of MCP servers carry high-risk capabilities.
• 1 in 4 expose arbitrary code execution.
• 62% of Skills carry risky characteristics with no audit trail at all.

👉 Read Noma Security's Lethal by Design research on MCP and Skill risk

Context

AI agent identity risk is not just about whether an agent exists. It is about how its permissions, tool access, and runtime actions are governed across the control points that software teams can and cannot see. In agentic AI environments, MCP servers and Skills can expand capability far faster than governance models can keep up.

The practical problem is that one layer may be visible to security tooling while another leaves almost no trace. That creates a split control plane for agentic AI risk, where authorization, logging, and containment are not aligned to the actual execution path. For identity teams, this is an autonomy and entitlement problem, not just an AI operations problem.

Key questions

Q: How should teams govern AI agents that use MCP?

A: Treat each connected agent as a non-human identity with an owner, a scope, and a review cycle. The practical control set is familiar: least privilege, secret rotation, access expiration, and auditability across the systems the agent can reach.

Q: Why do AI agents create a different access-risk profile than traditional applications?

A: AI agents can chain actions, call multiple tools, and change behaviour based on context, so one credential can enable more than one operational path. That means the risk is not just whether the agent authenticates, but how far it can move once inside. The key measure is privilege scope, not token count.

Q: What breaks when an agent capability has no audit trail?

A: Accountability breaks first, followed by detection and forensics. If a capability cannot show who accessed what, when, and through which action path, security teams cannot prove whether behaviour was authorised or reconstruct the sequence after an incident. That leaves the organisation unable to validate policy or explain harm.

Q: What is the difference between agent permissions and agent autonomy?

A: Permissions define what an agent is allowed to reach, while autonomy defines how independently it can choose actions and sequence them. A system can have broad permissions but little autonomy, or limited permissions with high runtime decision freedom. Governance must address both, because reducing one does not control the other.

Technical breakdown

Why MCP server risk is fundamentally different from Skill risk

MCP servers extend agents by connecting them to tools and data sources through a defined protocol layer. That makes them visible to governance teams in a way that can be inspected, policy-scoped, and monitored. Skills, by contrast, often operate as packaged capability extensions with far less observable runtime detail. When those layers are combined, the visible control surface can give a false sense of coverage because one layer may be logged while the other is effectively opaque. The result is not just more risk, but a governance split between what security teams can review and what the agent can actually execute.

Practical implication: map MCP-connected tools and Skill-level capabilities separately, because treating them as one control domain hides different failure modes.

How arbitrary code execution changes the agent identity model

Arbitrary code execution turns an agent integration from a bounded tool connection into a potentially uncontrolled runtime path. In identity terms, that means the permissions granted at onboarding may no longer describe the actual actions the agent can perform later. This matters because least privilege assumes the scope of action is knowable and stable enough to authorise. Once a connected component can execute code dynamically, the boundary between approved behaviour and unauthorised action becomes much harder to define, especially when the agent chain crosses systems with different logging and approval models.

Practical implication: classify any agent integration with code execution capability as a high-risk identity path and require explicit containment controls.

Why no audit trail is a governance failure, not a logging gap

A missing audit trail is not just an observability defect. In agentic systems, it prevents accountability, forensics, and policy verification after the fact. If a skill or extension can act without leaving traceable evidence, then the organisation cannot prove whether a decision was authorised, whether data was accessed appropriately, or whether a delegated action should have been blocked. That changes the governance model from reviewable access to unreviewable behaviour. The problem is structural, because an identity programme cannot certify what it cannot reconstruct.

Practical implication: if an agent capability cannot produce an attributable action log, do not treat it as governable at production scope.

NHI Mgmt Group analysis

Agentic AI risk is now a capability governance problem, not a model risk problem. The article shows that the highest-risk surface sits in the agent's connected capabilities, not in the language model itself. That shifts the control question from prompt quality to what tools, actions, and permissions can be exercised at runtime. Practitioners should treat capability scope as the first-line identity control for agentic systems.

Visible controls only cover part of the attack surface when Skills leave no audit trail. Security teams cannot govern what they cannot reconstruct, and unlogged execution breaks the normal assumptions behind review, detection, and incident response. That is especially damaging for identity programmes, which rely on traceable access histories to certify privilege and prove containment. The implication is that unobservable agent behaviour is effectively outside governance.

No Excessive CAP names the right unit of control for agentic identity. Capabilities, Autonomy, and Permissions are the three variables that determine how far an agent can move from intended behaviour to harmful action. That framing is stronger than treating all agent security as one permission problem, because it separates runtime independence from tool reach and authorisation scope. The practical conclusion is that agent governance must be designed around these three dials, not around generic AI controls.

Least privilege becomes weaker when runtime behaviour is negotiated dynamically. The assumption that access can be fixed at provisioning time works poorly when agents chain tools, invoke Skills, and shift execution paths as tasks evolve. That does not mean least privilege is obsolete, but it does mean the control boundary has moved. Identity teams need to decide which parts of agent behaviour can be pre-authorised and which must remain continuously constrained.

Identity blast radius: agentic systems can turn one risky capability into a cross-system failure domain within a single workflow. Once credentials, CRM data, and production systems are all reachable through connected agent layers, a local capability issue becomes an enterprise-wide governance problem. That is why agent security cannot sit only with AI engineering. Identity and security teams must treat agent capability chains as an access architecture problem, not a model deployment detail.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• For the broader control model, see OWASP Agentic AI Top 10 for the threat patterns that align with capability misuse.

What this signals

Agentic AI governance will move from policy writing to runtime containment. The organisations that keep expanding agent deployments without separating visible and invisible control layers will find that access reviews do not tell them what the agent actually did. With 52% of companies able to track and audit agent data access, the operational gap is already large enough to affect breach response and compliance evidence. Teams should align agent controls to OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework before scope expands further.

The next programme decision is not whether to adopt AI agents, but whether to govern them as identities with bounded capability chains. That means separating tool access, execution authority, and logging coverage into different control layers. If those layers are collapsed into one approval process, the agent's real operating range will exceed the identity model built around it.

For practitioners

• Separate MCP and Skill governance Inventory MCP servers and Skills independently, then assign different approval, logging, and containment rules to each layer because they do not expose the same level of runtime visibility.
• Block arbitrary code execution paths Treat any agent integration that can execute code as a privileged pathway and require containment, explicit approval, and tighter runtime monitoring before production use.
• Require attributable action logs Do not allow production agent capabilities that cannot produce a traceable record of tool use, data access, and action timing because unlogged behaviour cannot be certified or investigated.
• Rebase controls on Capabilities, Autonomy, and Permissions Use the No Excessive CAP framing to map which agent functions are permitted, which are autonomous, and which are merely available but should remain blocked by policy.

Key takeaways

• MCP servers and Skills create different agentic AI risk layers, and the visible one is not the whole problem.
• Noma Security's analysis shows high-risk capabilities are already common, with 76% of MCP servers carrying risky features and 62% of Skills lacking an audit trail.
• Identity teams should govern AI agents through capability scope, autonomy, and permissions, because that is where practical containment now begins.

Key terms

• MCP Server: An MCP server is a tool endpoint that connects an AI agent to external systems and data sources through Model Context Protocol. Because it extends what the agent can reach, it becomes part of the identity and access surface and must be reviewed like any other privileged connector.
• Skill: A skill is a modular instruction package that teaches an agent how to perform a task at runtime. It can include a markdown instruction file, metadata, scripts, and supporting documents. In agentic environments, a skill is not passive documentation. It is an active control input that can shape behaviour, tool use, and execution.
• Capability Governance: Capability governance is the discipline of controlling what an AI agent can do, not just what system it can access. It covers the permissions, action boundaries, and runtime constraints that determine whether agent behaviour stays within the organisation's intended risk appetite.
• No Excessive CAP: No Excessive CAP is a governance frame for agentic AI that focuses on Capabilities, Autonomy, and Permissions. It is useful because it separates what an agent may reach, how independently it may act, and how much room it has to expand beyond intended behaviour.

What's in the full report

Noma Security's full research covers the operational detail this post intentionally leaves for the source:

• The production sample methodology used to assess 200-plus MCP servers and agent Skills
• The capability breakdown behind the 76% high-risk MCP server figure and the one-in-four code execution finding
• The No Excessive CAP framework applied to continuous governance of Capabilities, Autonomy, and Permissions
• The full attack-chain examples showing how credentials, CRM records, and production systems were weaponised

👉 The full Noma Security research covers the attack chains, capability mapping, and No Excessive CAP framework in detail.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.