Agentic AI and MCP servers are expanding the API attack surface

At a glance

What this is: Salt argues that agentic AI and MCP servers expand the attack surface by pushing autonomous action and data access into APIs that many edge tools cannot fully observe.

Why it matters: This matters because IAM, NHI, and API governance now have to cover machine-driven actions, dynamic access paths, and policy enforcement inside the environment, not just at the perimeter.

Context

Agentic AI changes the control problem because software can now choose actions, call tools, and trigger workflows without a human approving each step. In that model, the API becomes the enforcement point for identity, authorisation, and data access, while traditional perimeter-centric tooling loses sight of where the action actually happens.

MCP servers intensify that shift by brokering instructions and orchestrating API calls across internal and third-party systems. For identity teams, the governance issue is not only who can log in, but what a machine identity, agent, or delegated workflow can do once it is inside the trust boundary.

Key questions

Q: What breaks when AI agents can reach exposed internal APIs?

A: The break point is governance, not just security tooling. Once an agent can call exposed internal APIs, it can chain permissions, query sensitive data, and trigger workflows at machine speed. That turns a single weak endpoint into a broad access path. Teams need to assume discoverability and chaining, then constrain each callable service with authentication, scoping, and runtime policy.

Q: Why do MCP servers create more risk than traditional APIs?

A: MCP servers create more risk because they centralize access, make tools discoverable at runtime, and often sit close to the secrets that authenticate downstream calls. Traditional APIs usually expose fixed interfaces; MCP adds a broker that can widen the blast radius if credentials or permissions are too broad. The danger is delegation without enough identity governance.

Q: What are the signs that API governance is failing at runtime?

A: Common signs include undocumented endpoints, duplicated ownership, inconsistent responses, rising retry loops, and frequent discovery of APIs that are not in the catalogue. Those signals show that the live estate and the formal control model no longer match. Once that happens, security and reliability teams are managing assumptions instead of actual behaviour.

Q: How should teams respond when an MCP server or agent behaves outside declared purpose?

A: Suspend the agent's connection path first, then revoke or narrow the credentials that allowed the unexpected access. The goal is to stop the action before it completes and preserve the audit trail for investigation. After containment, reclassify the server or agent as a high-risk integration until the control gap is understood.

Technical breakdown

Why API traffic becomes the control plane for agentic systems

Agentic systems are not merely generating text, they are selecting tools and issuing API calls that can change records, trigger workflows, or retrieve sensitive data. MCP servers sit in the middle of that chain by translating agent intent into tool use and downstream calls. That creates a new control plane where authorisation, logging, and policy enforcement must follow the request path rather than the user session. If visibility stops at the edge, the organisation cannot reliably distinguish routine automation from unsafe autonomous behaviour.

Practical implication: move governance and detection to the API layer where agent actions are actually executed.

Why edge controls miss internal and dynamic API use

WAFs, API gateways, and CDN-based protections are strongest when traffic flows through a known external boundary. Agentic AI and MCP patterns often route traffic deeper inside the environment, where internal services, partner APIs, and newly created endpoints may never traverse the same inspection points. Because many of these APIs are dynamic or undocumented, inventory drift becomes a security problem, not just an operations problem. Without continuous discovery, security teams cannot validate which services the agent is using or whether those calls stay within policy.

Practical implication: treat API discovery and runtime visibility as core controls, not optional instrumentation.

How rogue agents and compromised MCP servers become abuse paths

The article’s central risk is not the model alone, but the trusted orchestration layer around it. If an attacker hijacks an agent or compromises an MCP server, they inherit a path into the API fabric that can be used for data access, workflow abuse, or lateral movement across services. This is especially dangerous when policies are implicit, because machine-driven requests can be faster and more repetitive than human misuse. The security model must assume that autonomy can amplify a single compromise into broad operational impact.

Practical implication: bind agent and MCP permissions tightly to specific tasks and monitor for abnormal API behaviour patterns.

Threat narrative

Attacker objective: The attacker aims to turn trusted agentic automation into a high-speed path for data access, policy bypass, and system abuse through APIs.

1. Entry occurs when an attacker hijacks an AI agent or exploits an API path inside the MCP orchestration layer rather than attacking the model itself.
2. Credential or trust abuse follows when the compromised agent or server uses legitimate API permissions to reach internal or third-party data sources.
3. Escalation happens as the attacker leverages dynamic or undocumented APIs to move beyond the original workflow and trigger broader actions.
4. Impact is the unauthorised access, workflow manipulation, or downstream system abuse that results from trusted autonomous API execution.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
• Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.

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

API fabric governance is now the real boundary for agentic systems. Once software can choose actions and call tools, the security question shifts from whether the model is safe to whether every downstream API call is authorised, visible, and revocable. Perimeter tooling was built for known ingress and egress patterns, not for dynamic machine-driven orchestration across internal services. Practitioners should treat API governance as the operational centre of agentic AI security.

Agentic AI creates API inventory debt. New, ephemeral, and undocumented endpoints appear as agents discover new tools or workflows, which means the control failure is often incomplete discovery rather than weak intent. That inventory debt quickly becomes authorisation debt when security teams cannot prove which APIs an agent used, what data it reached, or whether its behaviour stayed within policy. The practical conclusion is that continuous discovery must accompany every agent rollout.

Model-centric security is the wrong abstraction for this risk. The article is right to separate the thing that reasons from the thing that acts. Identity governance has long assumed that policy can be enforced around a bounded user or service context, but agentic systems fragment that assumption across orchestration, delegation, and API execution. The reader takeaway is that identity and access teams need policy enforcement at the action layer, not just at login.

Machine identity and delegated access controls become decisive as MCP adoption grows. MCP servers effectively mediate machine-to-machine privilege, which means service credentials, tokens, and delegated scopes must be governed with the same discipline once reserved for privileged human access. This is where NHI governance intersects with API security: the agent is only as safe as the permissions behind its tool calls. Practitioners should align agent permissions to tightly scoped, task-bound access models.

Agentic AI security will be measured by containment speed, not by model confidence. Once a rogue agent or compromised MCP server starts issuing API calls, the meaningful question is how quickly the organisation can identify, isolate, and revoke that path. That makes runtime policy enforcement, API anomaly detection, and rapid offboarding of agent credentials the controls that matter most. The field is moving toward action containment as the defining control pattern.

From our research library:

• 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to the 2026 Infrastructure Identity Survey.
• Half of companies using generative AI will deploy agentic AI by 2027, according to Deloitte's 2025 Technology Predictions.
• Read next: AI Agent Authorisation Guide

What this signals

Agentic API governance debt: organisations are accumulating a gap between what their models can do and what their runtime controls can still see. That gap matters more than model capability alone, because autonomous actions only become risky when visibility, authorisation, and revocation lag behind execution. Teams should assume every new agent workflow expands the policy surface until proven otherwise.

Machine identity for API execution is becoming a first-order control problem. Agent permissions, service tokens, and delegated scopes now determine whether autonomous systems remain bounded or drift into overreach. NHI governance has to reach the tool layer, because that is where agent intent becomes operational change.

For practitioners

• Inventory every API used by agents and MCP servers Build a live map of internal, partner, and dynamically created APIs that autonomous systems can reach, then reconcile it against approved business use cases.
• Apply task-scoped authorisation to agent tool use Constrain each agent and MCP server to the narrowest set of APIs, methods, and data objects required for a specific workflow.
• Move monitoring to the API execution path Instrument runtime visibility for requests between agents, MCP servers, and downstream services so policy violations are observable inside the environment.
• Define containment steps for rogue agent behaviour Pre-stage revocation, isolation, and blocking workflows so a compromised agent or MCP server can be cut off before it expands access across systems.

Key takeaways

• Agentic AI shifts the main security question from model behaviour to API-layer control over actions, data access, and workflow execution.
• The hardest governance problem is not the existence of new agents, but the growth of dynamic, undocumented API paths that bypass edge visibility.
• Practitioners need continuous discovery, task-scoped authorisation, and rapid containment for rogue agent behaviour to keep autonomy within policy.

Key terms

• Agentic AI: Autonomous AI systems capable of planning, deciding, and taking actions, including calling APIs, writing code, and orchestrating other agents, with minimal human oversight. Agentic AI introduces new NHI risks as agents must authenticate to external services.
• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• API Fabric: API fabric is the connected layer that lets applications, services, and data exchange information through APIs in a coordinated way. It typically includes API gateways, service discovery, policy enforcement, authentication, observability, and lifecycle controls, so teams can manage traffic, access, and dependencies across distributed systems consistently.
• Machine Identity: The digital identity of a machine, device, or workload, such as a server, container, or VM, used to authenticate it within a network. Sometimes used interchangeably with NHI, though NHI is the broader category.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and identity lifecycle control. It is designed for practitioners who need to govern delegated access, service credentials, and autonomous systems with clearer discipline.