The modern telecom sector is actively deploying intelligent agents to optimize radio networks and automate BSS/OSS. However, this technological leap is accompanied by a critical increase in cyber risks. According to the ENISA Threat Landscape 2025 report, digital infrastructure and services accounted for 27.7% of all data breaches among 4,875 incidents analyzed between July 2024 and June 2025. This indicates an unprecedented vulnerability in modern digital supply chains.
For telecom operators, the situation is complicated by intense regulatory pressure. The NIS2 directive requires critical infrastructure entities to maintain uncompromising security control over software suppliers. Integrating third-party AI components without architectural isolation is becoming a major threat to compliance and data integrity.
AI agents as a "black box": why perimeter defense no longer works
The traditional cybersecurity model has been built around the concept of a protected perimeter for years. It was assumed that if critical systems—such as the signaling core or billing—were isolated in internal circuits, the threat was minimized. However, the introduction of third-party AI modules destroys this paradigm. AI agents are "black boxes" by nature: the operator receives a finished solution whose decision-making algorithms are opaque.
When such a third-party module is integrated into the network core or BSS/OSS, it requires access to real data. Without strict control, a compromised AI component becomes an ideal vector for supply chain attacks. Traditional firewalls are unable to detect malicious activity within legitimate API traffic from an authorized AI module.
The financial consequences of such vulnerabilities are significant. According to the CFCA Global Fraud Loss Survey, global losses from telecom fraud in 2025 are estimated at approximately $41.82 billion (compared to $38.95 billion in 2023). Implementing algorithms without proper isolation allows attackers to manipulate tariffs, bypass fraud monitoring, or steal personal data.
NIS2 requirements: regulatory pressure on the supply chain
The NIS2 directive turns supply chain security from a recommendation into a strict legal requirement. Operators are obligated to assess the cybersecurity level of all software suppliers. In the context of AI, this means that a telecom company must technically prove to the regulator that it has full control over data processing by third-party models.
Declarative guarantees from a vendor are no longer sufficient. Tools are needed that allow for real-time auditing of AI component actions, limiting their access rights, and blocking atypical requests.
Architectural isolation based on TM Forum ODA principles
To solve the integration problem, the industry uses the Open Digital Architecture (ODA) methodology from TM Forum. ODA replaces monolithic BSS/OSS with a componentized, API-first architecture. In parallel, the 5G core architecture (service-based), defined by 3GPP standards, brings telecom closer to cloud-native principles.
The main principle of AI integration within ODA is the rejection of trust by default (Zero Trust). Any third-party AI module is considered potentially dangerous. Architects focus on micro-segmentation and the protection of individual API endpoints. However, it is important to understand that the ODA architecture itself does not automatically guarantee security without additional access control lists (ACL) and encryption.
Practical protection mechanisms: gateways, containers, and RLS
To ensure NIS2 compliance, technical teams implement three tiers of defense:
- API gateways for request validation: All requests between the network core and the third-party AI module pass through an API Gateway. The gateway verifies that requests comply with strict data schemas, limits frequency (Rate Limiting), and blocks unauthorized access.
- Containerization with privilege restrictions (ACL): AI modules are deployed in isolated environments with minimal network rights. This narrows the attack surface, although containerization does not make AI agents completely secure against application-level code threats.
- Row-Level Security (RLS) and data masking: Instead of direct database access, an RLS policy is implemented at the platform or DBMS level. The AI module only receives access to the data rows necessary for its specific task, in an anonymized form.
Building a secure integration circuit in practice
Implementing a Zero Trust architecture requires the use of platforms that support Security by Design. For building high-performance integration gateways and middleware, the low-code platform UnityBase (a joint development of the Intecracy Group alliance, where InBase is a key developer) can be used.
Thanks to a unified Domain metadata model, the platform allows for flexible configuration of access policies. For telecom projects with high loads, the official UnityBase documentation recommends the commercial Enterprise (EE) or Defence (DE) editions. They provide built-in row-level security (RLS) and attribute-level access control (ACL), as well as detailed transaction auditing (Audit Trail), which is a direct requirement for NIS2 reporting.
An example of a telecom solution in the Intecracy Group portfolio that combines softswitch and real-time billing is the carrier-grade VoIP platform DooxSwitch. Integrating third-party routing optimization (LCR) or fraud detection modules into such systems requires strict API gateways to minimize the risks of compromising the tariff core.
Furthermore, AI integration requires mature lifecycle management of models. Softengi (also a member of the alliance) holds international certification for artificial intelligence management, ISO/IEC 42001:2023. This allows for the design of custom AI solutions and consulting, taking into account strict requirements for the security and transparency of models, which is critical for European operators.
Matrix of architectural control for third-party AI modules in telecom networks
| Integration level | Risk without control | Isolation and control method (ODA / NIS2) |
|---|---|---|
| BSS / Client data | Unauthorized access to personal data and payment information leakage. | Implementation of Row-Level Security (RLS) and dynamic data masking at the integration platform/gateway level. |
| OSS / Network monitoring | Leakage of network topology and infrastructure vulnerability data. | Containerization of AI agents with strict NetworkPolicies and access control lists (ACL). |
| Network core (5G Core) | Routing disruption or denial of service due to incorrect AI commands. | Asynchronous interaction via secure message queues with mandatory data schema validation. |
FAQ
How do NIS2 directive requirements affect the integration of third-party AI services in telecom?
The NIS2 directive requires telecom operators to ensure the security of the entire supply chain (Supply Chain Security). This means the operator is responsible for risks associated with the use of third-party AI code and must implement technical means for access control and auditing.
How does Open Digital Architecture (ODA) help protect telecom infrastructure from vulnerable software?
TM Forum's ODA replaces monolithic systems with a componentized, API-first architecture. It allows for the isolation of third-party AI modules from critical processes, limiting their interaction with the network core exclusively through strictly controlled API gateways.
What is Row-Level Security (RLS) and why is it needed for AI modules?
Row-Level Security is a mechanism for restricting access at the level of individual database records (e.g., implemented in UnityBase EE). It ensures that a third-party AI algorithm only gains access to anonymized data directly relevant to its current task, preventing mass data leakage.