First in a four-part series: ReBAC Meets BSS, A Practitioner’s Blueprint for AI-Native Role-Based Access in Telco
Originally published on LinkedIn as part of a four part series on AI-native authorisation architecture in telco.
There is a failure mode that I believe is quietly taking shape across enterprise AI deployments right now.
It has not fully announced itself yet. There is no widespread pattern of system outages, security alerts, or failed deployment pipelines attributed to it. AI agents are starting up, connecting to enterprise systems, and beginning to operate. On the surface, everything looks fine.
But the conditions for a specific class of authorization failure are being built into these deployments today, and I think the industry is not paying sufficient attention to them before they become production incidents.
After twenty-five years of designing authorization and integration systems for telco and enterprise platforms, I have learned that authorization is the layer every programme underestimates. It is unglamorous, complex, and deeply contextual. And with enterprise AI deployments accelerating faster than authorization thinking can keep pace, that underestimation has the potential to become a structural risk.
This is not a model quality problem. An AI agent can reason correctly given what it knows about permissions. The question worth asking before deployment is: what happens when what it knows about permissions is no longer current?
Over the next four weeks I want to walk through a specific architectural response to this problem, one that connects telco industry standards, modern open-source authorization primitives, and AI reasoning in a way that I believe closes the gap properly. This first article is purely diagnostic. I want to name the potential failure pattern precisely before proposing any solution.
Why Telco Authorization Is Uniquely Complex
In most industries, a user is a user. They have a role, the role has permissions, and the mapping is relatively stable.
In telecommunications, a party is rarely just one thing. The same legal entity can simultaneously be a consumer customer, a business account holder, a reseller partner, and a wholesale connectivity buyer. Their permissions are not just a function of who they are. They are a function of which role they are acting in, which product they hold, which market they operate in, and which regulatory framework governs that interaction.
This complexity is not incidental. It is the business model. And it manifests differently across the three commercial contexts that define modern telco operations.
How the Problem Could Manifest: Three Scenarios
B2C: The Consumer Whose Status Changed Yesterday
In a Business-to-Consumer context, authorization appears straightforward on the surface. A consumer has a subscription. The subscription grants access to certain services.
Except consumer status changes constantly and at volume. Subscriptions upgrade and downgrade. Trial periods expire. Credit limits are breached. Loyalty tiers shift. Premium add-ons are added and removed. In a large consumer operation, these transitions number in the thousands daily.
When an AI agent is deployed into this environment, a customer service agent, a self-service portal agent, or a personalisation engine, it needs to know not just what a customer’s current entitlements are, but that its view of those entitlements reflects the state as of this moment, not as of whenever its authorization context was last refreshed.
The potential failure mode here is subtle but commercially significant. An AI agent offering a premium service to a customer whose subscription lapsed yesterday is not a security incident in the traditional sense. It is a revenue leakage event. Multiplied across thousands of interactions, it becomes a measurable commercial problem with an authorization root cause that could be genuinely difficult to trace after the fact.
There is also a trust dimension worth considering. A consumer who is offered something they cannot have, or blocked from something they should have access to, does not conclude that the authorization system is stale. They conclude that the company’s AI does not know what it is doing. That perception risks damaging the very customer experience the AI was deployed to improve.
B2B: The Enterprise Account in Transition
Business-to-Business authorization is where the complexity multiplies significantly.
An enterprise account is not a single party. It is an organisation with multiple contacts, administrators, and users, each with different levels of access to different products and services across potentially multiple sites, cost centres, and geographies. The account itself may be in the middle of a contract renegotiation, a product migration, or a service transition that changes what the account and its users are permitted to do.
Consider a scenario where an enterprise customer is mid-migration from one connectivity product to another. For a period of several weeks, their authorization state is genuinely ambiguous. They have partial access to the old product and conditional access to the new one, governed by milestones in a migration plan that exists in a project management system no authorization layer has ever been connected to.
An AI agent deployed into this account, a network management assistant, an order management agent, or a billing enquiry handler, must navigate this ambiguous state. Without a dynamic, context-aware authorization layer, it risks either over-serving the customer based on an old entitlement, or under-serving them by blocking access they legitimately hold under the new arrangement.
The B2B failure mode carries higher commercial stakes than B2C. Enterprise customers have account managers, SLAs, and escalation paths. A mis-authorization event in a B2B context has the potential to generate a service complaint rather than a frustrated click. And if the AI agent is operating with any degree of autonomy, making configuration changes, raising orders, or processing requests without human review at each step, the downstream consequences of an authorization error could compound quickly.
B2B2C: The Reseller Relationship Nobody Modelled
The Business-to-Business-to-Consumer scenario is where authorization complexity reaches its highest point, and where I would anticipate the most significant gap between current deployment practices and what the architecture actually requires.
In a B2B2C model, a telco sells through an intermediary. The intermediary, a reseller, a retail partner, or a white-label operator, then serves end consumers. The authorization question is no longer simply what is this party permitted to do. It becomes: what is this party permitted to do, on behalf of which end consumer, within the boundaries that the intermediary relationship permits, subject to the constraints that the originating telco’s regulatory obligations impose?
This is a multi-layered authorization problem. The reseller has permissions. The end consumer has permissions. The relationship between them has permissions. And all three layers can change independently.
A reseller tier upgrade changes what products the intermediary can offer. An end consumer status change affects what the reseller can do on their behalf. A regulatory change in a specific market constrains what either party can access regardless of their commercial arrangement.
When an AI agent operates in a B2B2C context, a partner portal agent, a white-label customer service agent, or a commission management assistant, it would need to reason across all three authorization layers simultaneously. Without a foundation that models these relationships explicitly and keeps them current, the agent would be operating on an incomplete and potentially incorrect view of what is permitted.
The potential failure modes here range from commercially problematic to genuinely serious. An agent that allows a downgraded reseller to continue offering premium product tiers creates a revenue and compliance exposure. An agent that surfaces one reseller’s customer data within another reseller’s administrative context creates a data protection risk. Both have authorization misconfiguration as a plausible root cause.
Three Anti-Patterns Worth Anticipating
Based on my experience designing authorization systems for complex enterprise and telco environments, I want to characterise three anti-patterns that could plausibly emerge as AI agent deployments mature and scale. Enterprise AI deployment at the level of complexity described here is still in relatively early stages across the industry. These are not patterns I have seen fully play out in production. They are patterns that the current architectural trajectory makes possible, and that I believe are worth designing against before they become the incident that prompts a retrospective.
The over-permissioned agent operates with more access than the party it represents currently holds. This would typically arise when role transitions, downgrades, expirations, or relationship terminations are not reflected in the agent’s authorization context in a timely way. The commercial and compliance risk is real and could remain invisible until audited or until a downstream consequence surfaces.
The under-permissioned agent is blocked from actions the party it represents legitimately holds the right to perform. This would typically arise when new entitlements, upgrades, or relationship extensions have not propagated to the authorization layer. The immediate consequence is a degraded experience. The less visible consequence is eroded trust in AI-assisted processes that were supposed to make interactions faster and more capable.
The stale-permission agent is the most structurally interesting anti-pattern. The agent’s authorization context was accurate at the time it was established. It has simply not been updated to reflect subsequent changes. This is not a design flaw in the traditional sense. The authorization system worked correctly when it was populated. The failure is the absence of a dynamic update mechanism that keeps authorization state current as the business state beneath it evolves.
All three anti-patterns share a common structural cause: the gap between when a party’s role changes and when the authorization systems acting on behalf of that party reflect that change.
Why This Gap Exists, and Why It Deserves Attention Now
The gap exists because authorization policy has historically been written and maintained by humans. A role changes in the BSS. A policy analyst or architect reviews the implications. A change request is raised. An authorization update is deployed. Days or weeks pass between the business event and the policy change.
For human-operated systems, this lag was manageable. A human customer service agent could use judgment to bridge the gap. A human partner manager could apply context that the system lacked.
AI agents cannot do this in the same way. They operate on what they are given. If the authorization context is stale, they act on stale context, at speed, at scale, and without the contextual judgment that a human operator might apply to an edge case.
The deployment of AI agents does not create this authorization gap. It has the potential to expose a gap that already exists and make the consequences of that gap significantly more visible, more frequent, and harder to attribute after the fact.
This is why I believe the right moment to address the authorization layer is before AI agents are deployed at scale, not after the first incident prompts a retrospective.
What Belongs in the Gap
I am deliberately not proposing a solution in this article. I want practitioners reading this to sit with the problem for a moment, because in my experience the instinct is to reach immediately for tooling, a new IAM product, a policy engine, a synchronisation job, without fully appreciating why those approaches may fall short at the scale and complexity that telco authorization demands.
Next week I will introduce two specific technical primitives that I believe belong at the foundation of a proper solution. One from the telco standards world that most operators already have in production. One from modern authorization engineering that models the relationship complexity described here with the precision it requires.
The week after, I will show where AI reasoning enters the architecture, and why it needs to reason rather than simply route.
For now I want to ask a direct question to practitioners reading this: do you recognise these three anti-patterns as risks in your own AI deployment planning? And if you are already designing authorization layers for AI agents in complex multi-role environments, I would genuinely like to compare notes on what you are finding.
Soumit Saha is a Digital Platform and Technical Architect with 25 years of experience in telco, cloud, and enterprise integration. He has led the adoption of TM Forum Open APIs across multiple markets and holds TOGAF 9, ODA Practitioner, and AWS Cloud Architect certifications. This series represents his personal architectural thinking and does not reflect the views or systems of any employer.
Next: Article 2, ReBAC Meets BSS: Why TMF 672 and OpenFGA Belong Together
Originally published at https://www.linkedin.com.
The Authorization Problem Nobody Is Solving Before Deploying AI Agents was originally published in System Weakness on Medium, where people are continuing the conversation by highlighting and responding to this story.