By NHI Mgmt Group Editorial TeamDomain: Agentic AI & NHIsSource: LEVOPublished October 5, 2025

TL;DR: Telecom MCP servers connect AI agents to billing, network operations, and fraud systems, creating direct exposure to subscriber data, service disruption, and unauthorized actions, according to LEVO. Legacy IAM and perimeter tools cannot reliably attribute or constrain these agent-to-tool flows, so runtime policy enforcement becomes the governing control layer.


At a glance

What this is: This is an analysis of why MCP servers are becoming a high-risk control point in telecom AI workflows, with runtime visibility and inline policy enforcement emerging as the key finding.

Why it matters: It matters because telecom security teams must govern agent access to sensitive systems and data without relying on human-centric IAM assumptions that break under dynamic tool use.

By the numbers:

👉 Read LEVO's analysis of runtime MCP security for telecom AI workflows


Context

MCP servers are turning AI agents into active participants in telecom workflows, which means access decisions now sit at the junction of subscriber data, operational control, and fraud operations. That is a governance problem, not just an architecture choice, because the same agent can touch billing, network monitoring, and compliance data in a single session.

Telecom operators already have IAM, SIEM, fraud controls, and perimeter tooling, but those controls were built around human users, static service accounts, and network boundaries. Once an AI agent is selecting tools at runtime, the core question becomes whether the enterprise can see, scope, and stop each action before it affects customers or critical infrastructure.

This is where MCP changes the identity discussion: it creates a delegated execution layer that is not a traditional API integration and not a simple chatbot. The article's starting position is typical for a fast-adopting industry, because telecoms are under pressure to automate while still protecting sensitive data and service continuity.


Key questions

Q: What breaks when MCP servers are not tightly scoped for AI agents in telecoms?

A: Workflow boundaries break first. An agent that can reach billing, CRM, and network tools from one session can move from harmless lookup to state-changing action without a clear governance checkpoint. That creates subscriber data exposure, unauthorized service changes, and audit gaps because the control model no longer matches the way the system actually executes.

Q: Why do AI agents create more authorization risk than static service accounts?

A: AI agents can vary their access needs by task, context, and timing inside the same workflow, which makes static entitlement assumptions weaker. If the control model assumes access is stable, it will either overgrant by default or block legitimate work. That is why fine-grained, real-time evaluation matters.

Q: How do security teams know whether MCP server governance is working?

A: They should be able to answer four questions at any time: what servers exist, which are official, what credentials they can use, and what systems they contact. If those answers are unclear, governance is not working. The signal is not just fewer alerts, but clear attribution and scoped access across the fleet.

Q: Should telecoms prioritise runtime enforcement or broader IAM cleanup first for MCP risk?

A: Runtime enforcement should come first wherever agents can touch production systems. IAM cleanup matters, but it will not stop a dynamic agent from overreaching inside an approved session. The immediate priority is to prevent sensitive data exposure and state changes at the point of action, then align the broader identity model behind it.


Technical breakdown

How MCP servers extend agent identity into telecom systems

MCP, or Model Context Protocol, gives an AI agent a standard way to call tools and data sources without hard-coded point-to-point integrations. In telecom environments, those tools can include billing engines, CRM platforms, network observability stacks, fraud systems, and regulatory reporting data. The security problem is that the agent is no longer just generating text. It is initiating actions that touch operational systems, often with temporary tokens or delegated roles. That makes the access path dynamic, stateful, and harder to attribute than a conventional service account flow.

Practical implication: Treat each MCP-connected agent as an identity subject with explicit scoping, logging, and revocation requirements.

Why legacy IAM cannot fully govern agent-to-tool flows

Traditional IAM works best when identities are stable, privileges are known in advance, and authorisation happens before a request is executed. MCP-driven agent flows break that model because the agent can decide which tool to call next based on the session context. That creates a moving entitlement surface where access may be valid for one step and excessive for the next. Perimeter tools also miss this because the risk lives inside the workflow, not at the network edge. The result is a control gap between authentication, authorisation, and action.

Practical implication: Add runtime authorisation and session-level policy checks wherever agent decisions can change tool usage mid-workflow.

What runtime MCP security changes in practice

Runtime MCP security is essentially inline governance for agent actions. It traces each agent-to-MCP request, evaluates the requested data and operation against policy, and can redact sensitive data or block unauthorized actions before they reach the target system. For telecoms, that matters because the same control layer must handle privacy, residency, fraud sensitivity, and service continuity. The important shift is from after-the-fact visibility to pre-action enforcement, which is the only point at which a misrouted credit, reroute, or data disclosure can still be prevented.

Practical implication: Require inline policy enforcement for any MCP workflow that can modify subscriber state or network operations.


Threat narrative

Attacker objective: The attacker objective is to use agent-mediated telecom access to steal data, manipulate services, or cause large-scale operational disruption.

  1. Entry occurs when an AI agent is granted MCP access to telecom systems such as billing, CRM, network monitoring, or fraud detection.
  2. Escalation happens when the agent receives broader task-scoped privileges than the immediate workflow requires, allowing it to reach sensitive subscriber data or operational controls.
  3. Impact follows when a compromised or misused MCP workflow issues fraudulent credits, reroutes calls, or exposes subscriber data at scale.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.


NHI Mgmt Group analysis

Runtime MCP security is becoming the identity control plane for agentic telecom operations. Telecoms are not just exposing tools to automation, they are delegating operational authority to runtime decision-makers. That shifts the control problem from API security to identity governance for non-human actors. The practical conclusion is that every MCP workflow should be treated as a governed identity path, not a convenience integration.

Human-centric IAM assumptions collapse when an agent can select tools mid-session. Least privilege is designed for a known request path, but telecom agents can change tool choice as a conversation evolves. That means provisioning-time scoping cannot fully predict the privileges the workflow will actually consume. The implication is that access governance for MCP must account for runtime intent, not just static role assignment.

Data redaction and policy enforcement are now part of access governance, not separate privacy controls. In telecom, subscriber data, payment data, and network telemetry often move through the same agentic workflow. If the policy layer does not sit inline, privacy, fraud, and service controls all fail together. Practitioners should stop treating these as parallel disciplines and manage them as one access decision surface.

Telecom MCP adoption exposes a new identity blast radius. A single over-permissioned agent can now affect millions of subscribers through credits, rerouting, or regulatory exports. That is a stronger concentration of risk than a typical service account because the agent can sequence actions dynamically across multiple systems. Security leaders need to evaluate blast radius at the workflow level, not just at the credential level.

OWASP Agentic Applications Top 10 is relevant here because MCP risk is agentic by behaviour, not by label. The critical issue is tool misuse and privilege abuse at runtime, which maps directly to agent-governance concerns rather than traditional application security alone. Telecom teams should use that lens to separate safe orchestration from unrestricted execution.

From our research:

  • 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials, according to AI Agents: The New Attack Surface report.
  • 52% of companies can track and audit the data their AI agents access, which leaves 48% with a complete blind spot for compliance and breach investigation.
  • That same research is directly relevant to runtime agent governance, and OWASP Agentic Applications Top 10 helps practitioners frame the control failures around tool misuse and privilege abuse.

What this signals

With 80% of organisations already reporting AI agents that exceeded intended scope, the governance gap is no longer hypothetical. For telecom teams, that means MCP adoption should be treated as a policy design problem first and an integration problem second, because the failure mode is over-delegation inside live workflows.

Identity blast radius: when one agent can traverse billing, network, and fraud systems, the unit of control is the workflow, not the token. That forces security architects to measure how far a single session can move before policy stops it, and to anchor their review process in runtime evidence rather than static entitlements.

Telecom programmes should also prepare for stronger alignment between agent governance and external frameworks such as the NIST Cybersecurity Framework 2.0 and the OWASP Top 10 for Agentic Applications 2026. The pressure point is not whether AI is used, but whether the organisation can prove that data access, action scope, and audit evidence are controlled at runtime.


For practitioners

  • Map every MCP-connected workflow to an owner and a business purpose Catalogue which AI agents can reach billing, network, fraud, CRM, and compliance systems, then assign a named control owner for each workflow. If no owner can approve the data scope and action scope, the workflow is not ready for production.
  • Enforce inline policy on data access and state-changing actions Block or redact subscriber data, call records, and payment data before the agent receives it, and require separate policy checks for credits, rerouting, subscription changes, and report generation.
  • Scope agent privileges by task and revoke mid-session when behaviour drifts Issue the minimum privileges needed for the current task, then terminate or narrow them when the agent requests unrelated tools or higher-risk actions than the original intent justified.
  • Log agent-to-tool activity with audit-ready detail Capture the agent identity, target tool, requested object, decision outcome, and policy reason so compliance teams can reconstruct what happened without relying on application logs alone.
  • Test blast radius using telecom-specific failure scenarios Simulate fraudulent credits, rerouting, and subscriber data disclosure to verify that controls stop the action before it reaches live network or customer systems.

Key takeaways

  • MCP servers turn telecom AI from a support layer into a high-impact identity plane, because they let agents reach sensitive operational systems directly.
  • The evidence points to a familiar pattern: agent scope creep, weak tool scoping, and poor runtime visibility are the conditions that turn automation into risk.
  • Telecom teams need inline enforcement, session-level scoping, and audit-ready traceability before MCP-based automation can be considered governable.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Agentic AI Top 10A3Agent runtime tool use and privilege abuse are central to the MCP workflow risk.
OWASP Non-Human Identity Top 10NHI-03MCP workflows create non-human access paths that need scoped identity governance.
NIST CSF 2.0PR.AC-4Telecom MCP access control depends on least privilege and managed authorisation.
NIST Zero Trust (SP 800-207)5.2Zero Trust is relevant because trust must be re-evaluated for each agent action.
NIST SP 800-53 Rev 5AC-6Least privilege is the clearest control family for over-scoped agent access.

Treat each AI agent as an NHI and enforce least privilege, rotation, and revocation at session level.


Key terms

  • 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.
  • 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.
  • Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
  • Agent-to-tool path: The agent-to-tool path is the full chain an AI agent follows from decision to tool invocation to resulting action. For governance teams, it is the unit that must be authorised, logged, and reviewed because the risk sits in the live path, not just the endpoint inventory.

What's in the full article

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

  • Workflow examples for billing, network operations, fraud detection, and compliance reporting.
  • Runtime enforcement details for visibility, redaction, scoped permissions, and inline policy blocking.
  • Implementation discussion for privacy-preserving telemetry and low-overhead deployment in telecom environments.
  • Compliance handling for subscriber data, residency rules, and audit evidence generation.

👉 LEVO's full article covers telecom MCP use cases, runtime controls, and compliance detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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.
NHIMG Editorial Note
Published by the NHIMG editorial team on September 3, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org