Agentic AI and MCP servers are expanding the API attack surface

At a glance

What this is: This is an independent analysis of how agentic AI and MCP servers shift risk from the model to the API layer, with visibility and policy enforcement becoming the core control problem.

Why it matters: It matters because IAM, PAM, and security teams must govern AI-driven actions that can access systems, move data, and trigger workflows without a human in the loop.

By the numbers:

• 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate.
• 53% of MCP servers expose credentials through hard-coded values in configuration files.

👉 Read Salt's analysis of agentic AI, MCP servers, and API security

Context

Agentic AI changes the security problem because the system deciding what to do is no longer the same thing as the system carrying out the action. In practice, MCP servers broker tool access, API calls, and data movement on behalf of agents, which means the control point shifts from the model to the application and API fabric. For IAM and NHI programmes, that creates a new governance layer where credentials, delegation, and policy all need to be enforced at runtime.

The article argues that edge-only controls do not provide enough visibility into these interactions because many calls happen deep inside the environment or through dynamic APIs that appear as agents take new actions. That is a genuine identity bridge issue: when AI agents act through API-based access, the question becomes who or what is authorised, under which policy, and how those privileges are observed and revoked. This is an emerging pattern rather than a mature operating model.

Key questions

Q: How should security teams govern AI agents that call APIs instead of using a UI?

A: Security teams should govern AI agents by treating each callable action as a scoped entitlement, not as a general application login. The key control is to limit which APIs, data sources, and write actions the agent can chain together in one session. That keeps machine-paced behaviour inside a reviewable boundary instead of relying on human-style session assumptions.

Q: Why do MCP servers create new risk for IAM teams?

A: MCP servers can collapse the boundary between human intent and machine execution. If they use shared credentials or broad permissions, the agent may act with more privilege than the user should have, which weakens least privilege, complicates audit trails, and increases blast radius when the server is compromised.

Q: What breaks when AI agent traffic is only monitored at the edge?

A: Edge-only monitoring misses the internal API calls where most agentic action occurs. That leaves teams unable to see shadow APIs, hidden delegation chains, or data access that happens deep inside trusted environments. The result is weak detection, incomplete audit evidence, and slow containment when an agent goes rogue.

Q: Who is accountable when an AI agent exceeds its intended scope?

A: Accountability should follow the delegation chain, not stop at the agent label. The human requester, the policy owner, and the team that granted underlying access all matter, because the agent acts within a permission model someone designed. If the chain is unclear, the governance model is already too weak.

Technical breakdown

Why MCP servers become the control plane for agentic AI

Model Context Protocol servers act as intermediaries between an AI agent and the tools, APIs, or data sources it needs to use. That makes them more than integration plumbing. They broker instructions, expose callable functions, and often determine which resources the agent can reach. In security terms, MCP becomes a delegation layer, which means any weakness in policy enforcement, secrets handling, or authorization logic can convert a useful workflow into an abuse path. The architectural shift is from human-triggered requests to machine-triggered, context-aware action chains.

Practical implication: treat MCP servers as high-value identity and access enforcement points, not just application middleware.

Why API visibility is the real blind spot in agentic environments

Traditional web and API security tooling often focuses on perimeter traffic, static endpoints, or known request patterns. Agentic systems break that assumption because they can generate dynamic, undocumented, or short-lived API calls as they reason and act. Those calls may happen inside trusted networks, between internal services, or across third-party integrations that are invisible at the edge. Without telemetry at the API fabric level, teams cannot reliably answer whether a call was legitimate, whether it stayed within policy, or whether an attacker redirected the agent’s behaviour through a compromised path.

Practical implication: inventory and inspect internal API traffic, not just externally exposed endpoints.

How policy needs to follow the action, not just the user

In agentic environments, policy cannot stop at human identity or session login. The effective control boundary is the action itself, including which API operation the agent can invoke, which data it can read, and whether it can chain one tool into another. That is why runtime authorisation matters more than static approval alone. If a policy engine does not evaluate intent, context, and downstream effect at the point of execution, an agent can stay within narrow technical permissions while still violating business policy.

Practical implication: enforce least privilege at the API and action layer, with runtime checks for every delegated operation.

Threat narrative

Attacker objective: The attacker wants to turn delegated AI access into unauthorized system control, data theft, or workflow manipulation without raising human review in time.

1. Entry occurs when an attacker abuses exposed or poorly governed API pathways used by an AI agent or MCP server to reach internal tools and data sources.
2. Escalation happens when the attacker hijacks an agent, exploits dynamic API behaviour, or uses weak policy enforcement to expand what the agent can access and execute.
3. Impact follows when the rogue agent or compromised MCP server alters data, triggers workflows, or exfiltrates sensitive information at machine speed.

NHI Mgmt Group analysis

API visibility debt is now an identity governance problem. When AI agents and MCP servers issue actions through hidden or dynamic APIs, organisations lose the ability to prove who or what accessed data, which policy applied, and whether the action stayed inside scope. That creates governance debt because access review, audit, and incident response all depend on a reliable trail. Practitioners should treat API telemetry as part of identity control, not a separate monitoring concern.

MCP servers create a new delegation boundary that IAM teams cannot ignore. The article describes a world where machine decisions are translated into API calls across internal and third-party systems. That means the governance model must extend beyond login events to include session-level authorization, service-to-service trust, and revocation of machine-granted privileges. IAM and PAM teams should assume that a valid credential can still produce invalid behaviour if the delegation chain is not constrained.

Shadow AI becomes harder to see when the control plane is dynamic. If agents can create new API interactions on demand, then undiscovered tooling, undocumented integrations, and hidden credentials can multiply faster than governance teams can classify them. This is the same structural problem that makes shadow infrastructure hard to control, but with higher privilege density and faster execution. Practitioners should map agent activity to exposed APIs before they can govern the environment reliably.

Action-centric policy is the named concept this topic surfaces. The security model has to move from identity-only controls to controls that evaluate the specific action an agent is trying to perform, the data it will touch, and the downstream systems it can reach. That is a practical extension of least privilege for machine actors. Security teams should design controls around callable actions, not just authenticated principals.

AI-driven API abuse will pressure governance teams to close the gap between policy and telemetry. If a team cannot observe the action, it cannot enforce or investigate the action. That means GRC, IAM, and application security must share a common evidence model for machine access. Practitioners should expect audits to ask for proof that agent actions are logged, scoped, and reversible.

What this signals

Agentic AI is pushing security teams toward a control model where identity, authorization, and observability must converge at the API layer. That is a material change for programmes built around perimeter monitoring or static access review, because machine actions can now occur faster than human approval loops can react. For teams working to align with the NIST AI Risk Management Framework, the first signal is whether API telemetry can prove what an agent touched and why.

Action-centric policy drift: this topic shows how quickly governance can lose contact with runtime behaviour when machine decisions are translated into dynamic API calls. The practical response is to treat agent action logs as evidence, not just operational telemetry. Teams that already track delegated access and service identity should use that data to detect whether AI systems are extending beyond their intended boundaries.

For identity and security leaders, the next planning question is whether current NHI controls can absorb agentic workloads without creating a second, inconsistent authorization model. The answer will depend on whether the organisation can scope tools, revoke access cleanly, and see machine-to-machine traffic across internal services. Where that capability is missing, agentic adoption should be slowed until control coverage catches up.

For practitioners

• Inventory every agent-facing API path Build a live inventory of the APIs, internal services, and third-party endpoints that AI agents and MCP servers can call. Include undocumented and shadow interfaces, then tag each path by business function, privilege level, and data sensitivity.
• Move policy enforcement into the API layer Apply authorization and policy checks at the point of API execution so machine actions are evaluated in context. Static allowlists are not enough when agents can chain calls or generate new behaviours at runtime.
• Instrument agent activity for audit and response Log which agent invoked which API, with what context, against which data source, and whether the request was approved, denied, or modified. Use that evidence to support incident triage, compliance review, and revocation decisions.
• Constrain delegated machine privileges Limit what MCP servers and agents can do through scoped credentials, narrow tool permissions, and explicit revocation paths. Where possible, separate read, write, and workflow-triggering capabilities so compromise does not cascade across systems.

Key takeaways

• Agentic AI moves the main security question from model safety to API governance, because APIs are where autonomous actions actually happen.
• Dynamic, internal, and undocumented API calls create a visibility gap that edge tools alone cannot close.
• IAM and PAM teams need action-level policy, auditability, and revocation paths before agentic systems can be trusted at scale.

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.
• Action-centric policy: Action-centric policy means authorizing the specific operation an AI system is trying to perform, not only the identity that authenticated. This approach is useful when agents can chain tools, generate dynamic requests, or move between systems faster than human review can keep up.
• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.

What's in the full article

Salt's full article covers the operational detail this post intentionally leaves for the source:

• The vendor's five CISO questions for mapping AI agent and MCP server API exposure.
• Real-time visibility considerations for API traffic between agents, MCP servers, and internal or third-party data sources.
• Guidance on applying governance and policy controls at the API layer for AI-driven actions.
• Containment priorities for stopping a rogue agent or compromised MCP server before data or systems are affected.

👉 Salt's full post covers the API visibility, policy, and containment questions in more operational detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and agentic AI identity. It is designed for practitioners who need to connect identity controls to modern access patterns across cloud and enterprise environments.