Why are service accounts risky for AI agents in telecom networks?

Service accounts are risky for AI agents in telecom networks because an agent running on one can do everything the account can do, on every run. In a telecom estate a single account often reaches billing, customer data and network settings, which is far more than any one agent task needs. Prompt instructions do not narrow that access, because agents follow access, not instructions.

How can an AI agent’s access be limited to what the person it acts for is allowed to do?

An AI agent’s access can be limited to the delegating person’s permissions by evaluating both identities in the same authorization policy check. The policy receives the agent’s identity and the person’s role and attributes, then allows the action only when the combination is permitted. Cerbos Synapse can add that person’s details from the identity provider before the check, so the calling system only sends IDs. For agents that call other agents, the same check has to repeat at each step, as covered in per hop PBAC.

How do you authorize AI agents that reach telecom systems through gateways, service meshes and Kafka?

You authorize AI agents that reach telecom systems through gateways, service meshes and Kafka by having those enforcement points call the same policy layer as your applications. Cerbos Synapse turns Envoy, Istio and Kafka requests into authorization policy checks, so one set of policies covers API calls, mesh traffic and topic reads and writes. The Kafka integration shows how topic authorization works with policy.

What should a telecom operator log for every AI agent decision?

A telecom operator should log, for every AI agent decision, the agent, the person it acted for, the resource, the action and the result. That record is what auditors and regulators ask for after an incident. Decisions made through one authorization layer produce it in one format, instead of scattered logs in each system. Cerbos Hub audit log exports let your security team pull those records into its own tooling for archiving or compliance.

Can a telecom operator restrict an AI agent without taking it offline?

A telecom operator can restrict an AI agent without taking it offline by changing the authorization policy the agent is checked against. Examples are read only access to customer records, a narrower set of network elements, or denying plan changes above a set value unless an approval is attached. The new policy applies on the next request, so the agent keeps working inside the tighter boundary.

Cerbos Named a Sample Vendor for Authorization and Entitlement in the Gartner® Agentic AI Trust Fabric for Secure Control and Scale of Agentic AI in CSPs

Q: How should a telecom operator authorize AI agents?

A telecom operator should authorize AI agents per action, with a policy check before every call an agent makes to billing, customer records, network configuration or partner APIs. The check looks at the agent, the person it is acting for, the resource and the action, rather than trusting whatever a service account allows. Keeping those policies outside the systems themselves means the security team can read, test and change them in one place.

Cerbos has been named a Sample Vendor for authorization and entitlement in the Gartner® Agentic AI Trust Fabric for Secure Control and Scale of Agentic AI in CSPs, published on 15 October 2026.

If you run identity or security at a communications service provider, AI agents are starting to do real work in your network operations, customer care and billing. An agent that changes a customer’s plan, opens a fault ticket or adjusts a network setting is acting for someone, and each of those actions needs its own answer on whether it is allowed.

Telecom AI agents need permissions per action, not per account

When an agent runs on a service account, or on the credentials of the person who started it, it can do anything that account can do, on every run. In a telecom estate that can mean billing, customer records, network configuration and partner APIs, all reachable from one token. Nobody chose to give the agent that much. The account simply allowed it.

Agents follow access, not instructions. Telling an agent in its prompt to stay away from production network settings is a request. What actually stops the action is a policy evaluated before the call goes through, against the agent, the person it is acting for, the resource and the action. That is the gap dynamic authorization closes for non-human identities, and why authorization works better as its own layer than as code inside each system.

cerbos-gartner-agentic-ai-trust-fabric-csp - agent request through a policy check.png

Each AI agent action should carry the identity of the person who delegated it

Most agent requests arrive with very little identity context, often an agent ID and a token. To evaluate a refund, a plan change or a configuration push, the policy also needs to know who the agent is working for, what that person’s role is, and which account or network element is being touched.

The Cerbos authorization management platform evaluates the agent and the person behind it in one policy check. Cerbos Synapse, the platform’s data layer, adds identity data from your identity provider, along with resource and relationship data from your databases and APIs, before the policy is evaluated, so the application or gateway only has to send IDs. When one agent calls another, the same check has to hold at every hop, and the audit trail has to survive the handoff to a sub agent.

In a telecom network many of these calls never reach an application. They go through API gateways, service meshes and event streams. Synapse turns Envoy, Istio and Kafka requests into policy checks, so the same policies cover an agent calling a customer API and one writing to a network operations topic. We’ve written up how this works for agents behind an AI gateway.

Policy in one place gives telecom security teams evidence for every AI agent decision

After an incident, an auditor or a regulator asks the same question. Show me the policy that was in effect at the time. If the answer lives in prompts, scripts and Slack threads, there is nothing to show. With policy in one place, every decision is logged with the principal, the resource, the action and the result, and the audit logs give your team the evidence its own audits need.

The same policies are how you tune what an agent may do over time, a dimmer switch rather than a kill switch. Put an agent in read only mode on customer records, narrow it to a known set of network elements, or deny plan changes above a set value unless an approval is attached to the request. The change applies everywhere the policy is checked, without redeploying the agent or the systems it calls, and the work keeps moving.

cerbos-gartner-agentic-ai-trust-fabric-csp - dimmer switch for agent access.png

The platform handles more than 2 billion authorization checks a month. Utility Warehouse, which supplies energy, broadband, mobile and insurance to UK households, uses it across more than 4,500 internal services, making millions of non-human identity access decisions a day.

AI agent permissions belong in policy, not in the credentials each agent holds

Most operators are still choosing how agents get their permissions. If those permissions live in policy, they can be read by the security team, tested before release, changed at runtime and shown to an auditor. If they live in the credentials each agent happens to hold, every new agent adds another set of permissions nobody reviewed.

Try Cerbos *to see how one set of policies governs what every agent can do and records each decision, or book a call to talk through agent authorization across your network and customer systems with our team.

Gartner, Agentic AI Trust Fabric for Secure Control and Scale of Agentic AI in CSPs, By Peter Liu, Sylvain Fabre, Jon Dressel, Ajit Patankar, 15 October 2026.

GARTNER is a trademark of Gartner, Inc. and/or its affiliates.

Gartner does not endorse any company, vendor, product or service depicted in its publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner publications consist of the opinions of Gartner’s business and technology insights organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this publication, including any warranties of merchantability or fitness for a particular purpose.