Telecoms operators are giving AI agents two of the most sensitive powers in the industry: changing who controls a phone number, and changing how the network itself is configured. A customer care agent that can process a SIM change or a port-out is a target for the same social engineering that drives SIM swap fraud, and a network operations agent that can push configuration holds the kind of device credentials that state-sponsored intruders spent years harvesting from carriers. This guide covers the three main families of telecoms agent (customer care, network operations and fraud or abuse handling), the identities and credentials they need, the rules that already bind them such as the FCC SIM change and port-out protections, and how to monitor and contain them. It is written for operator security architects, network automation leads, fraud teams and CISOs. General telecoms security is in the Telecom Network Security Guide; this page stays on agents.
Source note: legal and regulatory points on this page summarise the cited official texts and secondary analyses, with status checked on 11 November 2026. Confirm against the official text before relying on it.
Key takeaways
- Number control is a credential change. A SIM change or port-out moves every SMS code and voice call for that customer, so an agent must never decide on its own who owns a line.
- FCC rules already apply to agents. Authentication for SIM changes and port-outs must be reasonably designed to confirm identity and cannot rely on readily available biographical, account, payment or call detail information.
- Network agents inherit device credentials. The Salt Typhoon intrusions show what stolen device logins, SNMP strings and AAA keys enable; an automation agent holding them must be treated as privileged access.
- Autonomy levels need matching guardrails. Moving from assisted to closed-loop operation changes the agent from adviser to actor, and change control must move with it.
- Logs must tie every action to an agent identity. Customer changes, configuration pushes and fraud decisions should each show which agent, which policy and which human, if any, approved.
Three families of telecoms agent
| Family | Typical actions | Systems reached | Identity it needs | Worst plausible failure |
|---|---|---|---|---|
| Customer care agent (chat, voice, app) | Answers billing and plan questions, changes plans, orders eSIMs, handles SIM changes and port-out PINs, resets account passwords | BSS: CRM, billing, order management, number portability and SIM provisioning | Service identity in BSS, acting for an authenticated customer | Attacker talks the agent into a SIM change or port-out and takes over the victim's bank and email codes |
| Network operations agent (AIOps, closed-loop automation, RIC applications) | Correlates alarms, opens and closes tickets, proposes or pushes configuration, tunes radio parameters | OSS, inventory, controllers, element managers, devices through NETCONF, CLI or vendor APIs; Non-RT and Near-RT RICs in Open RAN | Service accounts, API tokens and device credentials, often with write access across many devices | A bad or manipulated change pushed fleet-wide, or stolen agent credentials used as a backbone foothold |
| Fraud, abuse and assurance agent | Scores SIM change and port requests, blocks suspicious calls and messages, investigates International Revenue Share Fraud | Signalling data, CDRs, fraud management, network APIs | Read access to subscriber and traffic data; write access to blocking lists | Over-blocking legitimate traffic, or broad CPNI access leaking from an agent's context |
Each family needs a separate identity design. Mixing them, for example letting a care agent call network tools or a network agent read customer records, merges two blast radii. See the Agent Identity and Access Guide.
Customer care agents and number control
The FCC's 2023 order on SIM swap and port-out fraud (Federal Register, 8 December 2023) sets rules for wireless carriers that apply whether a human, an app or an AI agent handles the request. As described in the Federal Register text:
- Secure authentication: carriers must use methods "reasonably designed to confirm a customer's identity" before a SIM change or port-out. For SIM changes, methods relying on readily available biographical information, account information, recent payment information or call detail information are not secure.
- Annual review and failed attempts: methods must be reviewed at least annually, with procedures for failed authentication attempts that prevent unauthorised access.
- Notification before completion: customers must be notified immediately of SIM change and port-out requests, before the change or port completes.
- Account lock: customers must be offered a free lock that blocks SIM changes and port-outs until removed.
- No CPNI before authentication: employees handling inbound contacts must not access CPNI until the customer is authenticated. Apply the same rule to an agent: no customer data in its context until authentication completes outside the model.
- Records: carriers must track SIM change requests, outcomes, fraud and remediation time, and keep records for at least three years.
Compliance dates for parts of the order were set separately and some were waived, so confirm current status with the FCC. The design consequences do not depend on the date:
- Authentication and ownership decisions run in deterministic back-end services. The agent can collect input and call the service, but cannot override a failed check or choose an unverified channel.
- SIM change, port-out PIN, eSIM transfer and adding a new contact email or number are high-risk actions that require step-up authentication on an existing verified factor, and honour the account lock without exception.
- One-time codes and port-out PINs are sent only to channels already on record, never to an address the requester supplies in the conversation.
- The agent's service identity in BSS can read and change only the authenticated customer's account, bound by customer ID from the authentication service, not by text from the chat.
- Escalation to a human is a normal path, not a failure, for anything outside the scripted high-risk flow.
The Meta AI support assistant account takeover of 2026 shows why. Attackers asked the assistant in plain language to link a new email address to target accounts, and it sent reset links to the attacker's address because the system did not properly verify that the email matched the account; 20,225 people were affected and accounts with two-factor authentication were not taken over. A telecoms care agent that can issue port-out PINs or eSIM transfers has the same shape with higher stakes, because the phone number is often the recovery factor for everything else. See the Customer Service AI Agents Security guide and the FCC CPNI and Telecom Data Breach Rule Guide.
Network operations agents and device credentials
Network agents are where telecoms differs most from other sectors. Operators describe their progress on TM Forum's autonomous network levels, a scale from 0 (manual) to 5 (fully autonomous); one industry report (RCR Wireless, May 2026, single source) placed the industry at roughly level 2, with at least one operator, Telefónica, targeting level 4 by 2030. Each step up moves more decisions from engineers into closed loops, and more credentials into automation.
What the agent should and should not hold
- No direct device logins where a controller exists: let the agent call the controller or orchestration API under its own identity, and let the controller hold device credentials. This keeps device secrets out of the agent's memory, prompts and tool outputs.
- No shared local accounts: the joint CISA, NSA, FBI and Five Eyes guidance of December 2024 asks for unique strong passwords, local accounts only for emergencies, centralised AAA with phishing-resistant MFA for administrators, and management only from dedicated administrative workstations in dedicated management zones. Give each agent its own AAA identity with command authorisation limited to its tasks.
- Configuration as the source of truth: the same guidance asks operators to store configurations centrally and push them, and to alert on changes made outside change management. An agent's change should arrive as a reviewed, versioned change, not as ad hoc CLI.
- Configuration files are secrets: device configurations contain SNMP communities, local account hashes and AAA keys. Do not give agents bulk configuration export rights, and never paste configurations into a general-purpose model.
- Open RAN applications: the O-RAN Alliance WG11 zero trust white paper (May 2024) lists the Near-RT RIC with its xApps and the SMO with the Non-RT RIC and rApps as elements to protect, with mTLS and OAuth on the A1 and R1 interfaces and NACM on O1. An AI-driven xApp or rApp is a workload identity; onboard it with signed artefacts and scoped tokens like any other.
The Salt Typhoon telecom intrusions are the reference case for what device credentials enable. Cisco Talos found that in all but one investigated incident the attackers used valid stolen device credentials, then exfiltrated configurations containing SNMP strings and weakly protected local passwords, captured TACACS and RADIUS traffic for shared keys, added local accounts and SSH keys, and in one case stayed more than three years. An automation agent with fleet-wide write access concentrates exactly those credentials. See the Network Automation Security guide and the Salt Typhoon Threat Actor Profile.
Threats mapped to controls
| Threat | Telecoms example | Control | Reference |
|---|---|---|---|
| SIM swap through an agent | Caller persuades a care agent to activate a new eSIM | Deterministic authentication, account lock, step-up on existing factor, notification before completion | ATT&CK T1451 (mobile); SP 800-53 IA-8 |
| Prompt injection via customer or ticket text | Instructions in a chat, an email or a trouble ticket steer a care or NOC agent | Treat customer and ticket text as untrusted; no high-risk tools in sessions holding it without approval | ATLAS AML.T0051; SP 800-53 SI-10 |
| Unsafe tool invocation | A NOC agent pushes a change to every edge router after misreading an alarm | Blast-radius limits, staged rollout, human approval above a device count, automatic rollback | ATLAS AML.T0053; SP 800-53 CM-3, CM-5 |
| Theft of agent or device credentials | Agent's controller token or AAA account reused from outside the management zone | Per-agent AAA identities, source restrictions, short-lived tokens, MFA for human admins | ATT&CK T1078; SP 800-53 IA-2, IA-5, AC-17 |
| Configuration and secret harvesting | An agent with export rights is abused to dump configurations | No bulk export for agents, alert on TFTP or FTP transfers and config dumps | ATT&CK T1602.002 |
| Persistence through account changes | New local accounts or SSH keys added by a compromised automation identity | Alert on new accounts, keys and AAA server changes; reconcile against the source of truth | ATT&CK T1098, T1098.004 |
AI voice, scams and fraud agents
Operators both deploy voice agents and fight scam calls made with them. The FCC has adopted a declaratory ruling recognising calls made with AI-generated voices as "artificial" under the TCPA, so an outbound voice agent calling consumers falls under the artificial or prerecorded voice rules. For fraud and abuse agents:
- Read access to CPNI and traffic data: scope to the data needed for the decision and keep outputs (case notes, explanations) out of systems with broad staff access.
- Write access to block lists: require a second signal or human review before blocking a range, a business number or an interconnect partner, and keep an expiry on automated blocks.
- Explainability for disputes: record the features and rule or model version behind each automated decision so the operator can answer complaints and regulators.
See the Scam Prevention in Telecoms Guide.
How to roll out a telecoms agent
- Classify: care, network or fraud family; list every tool, the systems behind it and whether each action is reversible.
- Design identity: one service identity per agent and environment; BSS access bound to the authenticated customer; network access through the controller with AAA command authorisation.
- Read-only shadow mode: the agent recommends, engineers or care staff act. Compare its recommendations with the human decisions for several weeks.
- Assisted actions: the agent prepares the change or the customer action, a human approves. Measure error and override rates.
- Bounded closed loop: allow unattended actions only for reversible, low-blast-radius tasks (one cell, one ticket class, one customer's non-number changes), with automatic rollback and rate limits.
- Never unattended: SIM changes, port-outs, eSIM transfers, lawful-intercept-adjacent systems and core routing changes stay behind human approval or deterministic checks.
- Rollback and kill switch: document how to disable the agent's identity, revoke its tokens and roll back its last changes in minutes, and rehearse it with the NOC. See the AI Agent Kill Switch and Containment Guide.
Decision guidance
| Question | Choose this | When |
|---|---|---|
| Agent calls devices directly or through a controller? | Controller | Always where a controller or orchestrator exists; direct device access only for legacy estates, with per-agent AAA accounts |
| Agent handles SIM change end to end or hands off? | Hand off to a deterministic flow | Always for SIM change, port-out and eSIM transfer |
| One agent for many tasks or many narrow agents? | Narrow agents | When tasks need different data or privileges; fewer identities only where privileges are identical |
| Vendor-hosted model or operator-hosted? | Operator-hosted or strict data terms | When prompts would contain CPNI, configurations or network topology |
Smaller operators and MVNOs often rely on a host network and a BSS vendor: focus on the care flow, account lock and vendor contract terms for agent data. Large operators run multiple domains and vendors: standardise agent intake, register every network agent in the same inventory as automation service accounts, and include them in quarterly access recertification. See the Telecoms Identity Security Guide.
Detection and measurement
Forward care agent actions (authentication results, SIM and port events, contact changes), network agent actions (AAA accounting, controller API audit, configuration diffs) and fraud agent decisions to the SIEM under each agent's identity. Alert on SIM changes or port-out PINs issued by an agent shortly after a contact detail change, configuration changes outside a change record, agent identities used from outside the management zone, new local accounts or SSH keys on devices, and spikes in automated blocks.
Metrics
- SIM changes and port-outs completed without a deterministic authentication pass: target zero.
- Fraudulent SIM changes involving an agent channel and mean remediation time: tracked monthly, matching the FCC record categories.
- Network changes by agents with a linked change record: target 100%.
- Agent identities with device-level credentials: trending down as controller access replaces them.
- Agent actions rolled back or overridden by engineers: tracked per agent as an early warning of drift.
Framework mapping
| Area | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 |
|---|---|---|
| Agent and device identity, least privilege | PR.AA-05 | AC-2, AC-6, IA-5 |
| Change control for agent pushes | PR.PS-01 | CM-3, CM-5 |
| Management plane isolation | PR.AA-05 | SC-7, AC-17 |
| Monitoring agent and device activity | DE.CM-03 | AU-2, AU-12 |
| Customer authentication for number control | PR.AA-05 | IA-8 |
For AI system security across the lifecycle, ETSI EN 304 223, released in January 2026, sets baseline cyber security requirements for AI models and systems as 13 principles across secure design, development, deployment, maintenance and end of life.
Common failure patterns
- Letting the model decide identity: the agent asks security questions and judges the answers, instead of calling an authentication service it cannot override.
- Sending codes to channels supplied in chat: the exact flaw behind the 2026 Meta support assistant takeovers.
- Giving a NOC agent a shared admin account: every action looks like the team, and a stolen token reaches every device.
- Configurations in prompts: engineers paste running configs into an assistant, moving AAA keys and SNMP strings into vendor logs.
- Closed loop without blast-radius limits: an automation that is safe on one cell is unleashed on a whole region.
- Agents absent from CPNI and SIM change records: care actions by agents are not tagged, so fraud reporting and the FCC record categories miss them.
Practitioner checklist
- Inventory every care, network and fraud agent with its identity, tools, systems reached and owner.
- Route SIM change, port-out and eSIM transfer through deterministic authentication the agent cannot override, honouring account locks.
- Send codes and PINs only to channels on record and notify customers before the change completes.
- Keep customer data out of agent context until authentication completes.
- Give network agents their own AAA identities with command authorisation, operating through controllers from the management zone.
- Deny agents bulk configuration export and keep configurations out of general-purpose models.
- Require change records, staged rollout and automatic rollback for agent configuration pushes.
- Forward all agent actions to the SIEM and alert on SIM events after contact changes and changes outside change control.
- Rehearse disabling each agent and rolling back its last changes with the NOC and care teams.
Standards and references
- Federal Register: Protecting Consumers from SIM Swap and Port-Out Fraud
- CISA: Enhanced Visibility and Hardening Guidance for Communications Infrastructure
- FCC: FCC Makes AI-Generated Voices in Robocalls Illegal
- O-RAN Alliance: Zero Trust Architecture for Secure O-RAN
- MITRE ATT&CK: SIM Card Swap
- MITRE ATT&CK: Network Device Configuration Dump
- MITRE ATLAS: AI Agent Tool Invocation
- TelecomTV: ETSI releases standard for securing AI (EN 304 223)
Related NHI Mgmt Group resources: Telecoms Identity Security Guide · Network Automation Security · Customer Service AI Agents Security · Telecoms Threat Actors Guide · Agentic AI Security Guide