AI Agent Permission Models in Network Operations

AI agents in network operations are starting to touch provisioning systems, billing platforms, and customer records without a clear answer to a basic question: under whose authority are they acting, and is there a record of it? That gap, not model accuracy or latency, is the real bottleneck standing between pilot programs and production deployment. The popular answer is also the wrong one: give the agent a broad service account and sort out the audit trail later. That approach is how operators end up with automation nobody can fully explain after the fact, and it should be treated as disqualifying, not as a rough draft to refine once the pilot works.

Network operations run on a fragile set of assumptions about access. Human operators work inside defined permission structures, with access controls, logging, and oversight mechanisms built around human decision cadence. Those controls were built around human decision cadence and human identity. A person logs in, does a task, and logs off, leaving a trail that maps cleanly to one accountable individual. Agentic AI does not fit that mold. Pretending it does is the mistake sitting underneath almost everything else in this piece.

How AI agents differ from traditional automation in ways that break legacy access control assumptions

Traditional network automation runs on scripts. A rule fires, a predefined action executes, and the system either succeeds or fails in a way that's traceable line by line. LLM-based agents don't work that way. They take a natural-language objective, break it into subtasks, choose which tools or APIs to call, and adjust based on what they observe along the way. That's a different category of system, not a faster version of scripted automation, and legacy access models were never built to constrain it.

Several behavioral traits make this concrete. Agents are non-deterministic: the same instruction can produce different tool calls on different runs, so access decisions can't be pre-validated the way a fixed script's can. Agents also carry persistent memory across sessions, so a permissions mistake isn't something a future patch quietly fixes. If an agent already pulled privileged data into its working context before access was revoked, that information doesn't un-happen just because the account gets locked down afterward. Add autonomous tool selection, where the agent decides which API to call rather than executing a predetermined one, and recursive delegation, where an agent spawns sub-agents or hands a task to another agent, and the result is an authorization chain that can extend indefinitely without anyone narrowing the scope at each link. The OpenID Foundation has flagged this exact risk in its work on agentic identity.

The failure mode this produces in legacy operational support systems (OSS) is familiar to anyone who has worked with service accounts: a single account with broad, application-wide access, created because it was the fastest way to get an integration working. Revoke a user's access and that service account keeps answering requests anyway, because it was never actually tied to the user in the first place. Research from identity infrastructure firm Oso found that employees ignore roughly 96% of the permissions granted to them, simply because they don't need them for daily work. Agents don't carry that restraint. An agent exercises whatever access it's been granted, every time, at machine speed, which turns a human's unused-permission problem into an agent's active liability the moment the same account structure gets reused.

This isn't hypothetical for the industry's existing footprint. Research firm Business Research Insights reported in 2026 that roughly 42% of telecom operators worldwide were still running OSS platforms more than fifteen years old, architected long before agentic AI was a design consideration. Those platforms have no native concept of agent identity as distinct from human identity, which is exactly why governance has emerged as one of the central obstacles to deploying agents alongside legacy OSS. Governance itself isn't hard to define. The architecture underneath it was simply never built to enforce it.

The core components of a sound AI agent permission model

The foundational rule is straightforward to state and hard to implement: an agent should never hold more access than the human it's acting on behalf of. Oso's research on this point is blunt. Agents should mirror the permissions of the user they serve, not operate under a shared service account with standing privileges wider than any individual employee's, and any design that starts from the service-account shortcut has already picked the wrong foundation.

That principle plays out across three layers. First, an agent identity layer: every agent gets a distinct, verifiable identity of its own, separate from the user it serves, so an audit log can tell the difference between "the operator did this" and "the agent did this on the operator's behalf." Second, a delegated access layer, where the agent inherits the user's permissions as they stand at the moment of the task, not a snapshot taken when the agent was first configured. If the user's access changes or gets revoked, the agent's access changes with it in real time, not on the next sync cycle. Third, a scope restriction layer, narrowing things further: even within what the user is allowed to touch, the agent gets only the subset its current task actually requires. A network assurance agent diagnosing a fault has no business holding provisioning write access, even if the operator it serves happens to hold that access for other parts of the job.

Four mechanisms make this workable. Just-in-time access issues credentials at the moment of invocation and discards them once the task completes, so there's no long-lived token sitting around after a role change or a departure. Human-in-the-loop gates require explicit sign-off before high-stakes actions like configuration changes or service deprovisioning, while leaving routine, low-risk actions to run without a human bottleneck. Context-aware restrictions tie access to what the agent is doing in that moment, not just who invoked it. Continuous permission checks re-verify access throughout a task's lifecycle rather than once at the start, closing the window where a mid-task revocation would otherwise go unenforced.

None of it means anything without the audit trail. Every agent action needs to land in the same log as human operator actions, timestamped and attributable, not routed into a separate system or reduced to a summary. When something breaks in the network, the person reconstructing what happened needs to answer the same question regardless of whether a human or an agent did the acting: who, or what, had the authority, and what did it do with it?

Why delegated access is safer than application-wide service accounts, and how it works in practice

The path of least resistance is also the most dangerous one. Standing up a single service account with broad access is quick, which is why so many agent integrations start there, and why so many of them are wrong from the first commit. Every agent interaction under that model runs with more reach than the task requires. That's the textbook definition of a least-privilege violation, not a gray area open to interpretation.

Delegated access fixes this mechanically, not just philosophically. The agent submits the invoking user's token to an identity provider, which returns a scoped, downstream token carrying only that user's current permissions for the specific API the task needs. The downstream service enforces the user's permission set, not some broader service-account permission set the agent happens to be running under. If the user loses access mid-session, whether through a role change, a suspension, or an offboarding event, the agent's access disappears with it, because there was never a separate standing grant to fall back on.

The protocols available today get partway there. OAuth 2.1 handles delegated access reasonably well inside a single trust domain, for cases like an enterprise agent calling internal OSS tools synchronously. It runs into trouble in cross-domain scenarios, in asynchronous workflows, and in cases where a single agent needs to enforce delegated permissions on behalf of several human users at once, according to the OpenID Foundation's whitepaper on agentic identity. The Model Context Protocol, an open standard for connecting agents to external systems, is emerging as an interface layer for linking agents to enterprise tools and broader IT systems. Enterprise single sign-on and SCIM-based provisioning round this out, giving operators a central point to manage an agent's lifecycle and permissions across every use case it touches instead of configuring access piecemeal per integration.

There's a subtler problem underneath all of this: agents today often act in ways indistinguishable from the user they're serving, which erases the accountability the whole model is meant to preserve. Genuine delegation requires an explicit on-behalf-of flow, where the agent proves the scope it's operating under while remaining identifiable as an agent, not a stand-in impersonating the human. When agents delegate to sub-agents, each link in that chain has to carry forward the original scope rather than quietly expanding it. A chain that widens at every hop defeats the entire purpose of scoping in the first place.

Governance at the orchestration layer: how multi-agent network operations require a control plane above individual agents

Individual agent permissions solve one problem. They don't solve what happens when dozens of agents, each correctly scoped on its own, start coordinating across network operations, customer care, billing, security, and service assurance toward some shared intent. This configuration has been described as an autonomous digital ecosystem, and the framing holds: an ecosystem needs an ecosystem-level view, not just well-behaved individual organisms.

The operational loop underneath a single autonomous network agent typically runs as intent, observation of network telemetry and configuration state, decision, and action, often validated against a network digital twin before anything touches the live network. That loop can be sound at the individual agent level and still produce an outcome nobody wanted, if the orchestration layer above it has no visibility into what the full agent ensemble is doing collectively. Correctly scoped agents acting in an uncoordinated swarm are still a swarm.

A governance control plane exists for exactly this: an enforcement layer sitting above the multi-agent system, responsible for observability, safety, and governance across every agent operating below it. Governance control plane architectures are designed precisely for this, providing the mechanism that makes a multi-agent deployment scalable and governed, rather than a collection of independently well-behaved parts with no shared oversight. A control plane built this way maintains a unified audit trail that captures not just individual agent actions but the chain of delegation and the orchestration decisions that connected them.

One problem here doesn't have a settled answer yet. When agents operate in shared, multi-user environments, such as a network operations center where several human operators with different permission levels are working toward the same objective, no widely adopted protocol cleanly reconciles those permission levels against a single shared agent action. This remains an open area, and the industry has since given it a name: the risk of identity and privilege abuse at the orchestration layer has been formally catalogued in emerging agentic AI security frameworks. When an agent acts on a user's behalf, it inherits that user's risk profile, and at scale, that risk has to be managed at the orchestration layer, not left to hope. A well-designed control plane keeps the ability to pause, roll back, or escalate any agent's action to a human at any point. Autonomy isn't a switch that's either on or off, it's a dial, and the governance layer is what turns it.

The regulatory pressure that makes governed agent access a compliance requirement, not just a best practice

None of this is optional for much longer, and in some jurisdictions, it already isn't. Europe's AI Act, in force since August 2024 with material obligations phasing in through 2025 and 2027, classifies AI systems used as safety components in the management of critical digital infrastructure as high-risk under Annex III. Telecom networks fall squarely inside that definition.

High-risk classification isn't a label, it's a checklist: a documented risk management system, auditable governance over training data, automatic event logging, and defined human oversight mechanisms that an operator has to demonstrate to a national regulator on request, not merely describe in a policy document. South Korea's AI Basic Act, which took effect January 22, 2025, represents another comprehensive AI law to land globally, and telecom operators with cross-border footprints now have multiple comprehensive regimes to satisfy rather than one. ETSI's Securing Artificial Intelligence committee added a concrete technical reference point in December 2025, publishing a European Standard for securing AI systems against cyber threats, giving operators something specific to build toward rather than a general principle to interpret.

Standards bodies are moving the same direction from the network side. 3GPP began embedding AI and machine learning directly into the network architecture with Release 18, the first release of 5G-Advanced, meaning AI is now treated as a native network component rather than an external add-on, with governance obligations following accordingly. Layer that against the obligations telecom already carries: lawful intercept, NIS2 in Europe, retention requirements, E112 and 911 emergency services access. Line those up against agentic deployment and the exposure is unambiguous: any agent touching a regulated function has to produce records an auditor can actually use, not a best-effort log that mostly explains what happened.

The industry's readiness for this doesn't match the pressure, and that gap is the real story here, not a footnote to it. Industry research has found that most companies lack a mature model for governing autonomous AI agents, even as agentic deployment is growing. That gap has a specific consequence for network operators: when something goes wrong on a regulated function and an operator can't reconstruct which agent did what, under whose authority, with what access, that's not an operational failure. It's a regulatory one, and it's the exact failure mode the rest of this piece has been describing.

Why legacy OSS architectures cannot retrofit governed agent access and what that means for operators modernizing now

Legacy OSS platforms were built for a different world, one where change moved on a four-to-six-month cycle even for something small, and where "identity" meant a human logging into a terminal. Retrofitting agent identity onto that foundation isn't a matter of adding a new field to a user table. The architecture has no place to put the concept, and operators keep underestimating that by treating this as a configuration problem rather than a design one.

The numbers around legacy OSS performance make the stakes concrete. Order fallout above 30% is common on legacy platforms even before any AI agent enters the picture, meaning these systems already struggle to attribute failures reliably among human-driven processes alone. Layering agents on top doesn't close that accountability gap, it compounds it: more actors, less clarity about which one did what. The budget reality compounds the architectural one further. A large share of OSS spending at most operators goes toward maintaining and upgrading the legacy systems already in place, leaving little room for a clean rip-and-replace even where one might be architecturally preferable.

The realistic path for most operators has been described as gradual decomposition: agents and lightweight microservices growing up around the legacy core rather than replacing it outright. That approach can work, but only if the new layer is designed with governed permission architecture from day one, not layered on after the fact as an afterthought. Bolt AI tooling onto a legacy system without that discipline, and the likely outcome, per analysis from networkoss.com, is shadow automation: agents operating outside the existing permission and logging framework entirely, invisible to the human operators and auditors who are supposed to be watching.

AI-native OSS design takes the opposite approach, treating governance as a constraint baked into the architecture rather than a feature patched in after deployment. Agents move through the same APIs, land in the same audit trails, and answer to the same permission structures as human operators, because the system was built that way from the ground up rather than adjusted toward it later. The investment window for getting this right is now. The 2025 IDC-Ericsson Report projects $211 billion in global OSS and BSS modernization spend between 2025 and 2028, and the decisions operators make about their next-generation platforms over the next few years will determine whether governed agent access is structurally possible or permanently retrofitted.

Three questions cut through the noise faster than any vendor feature list. Does agent access flow through the same API layer human operators use, or a separate pathway built for speed instead of accountability? Does the audit log attribute actions to agents as distinct, identifiable entities, or does it blur them into whatever account invoked them? And does the permission model support just-in-time scoping at the level of the individual task, rather than granting access for the duration of a session and hoping nothing goes wrong in between? An operator that can't answer all three cleanly isn't ready to put agents anywhere near a regulated network function, no matter what the roadmap slide promises.