The agents run the network now. The credentials were issued to people and boxes.

Start at three in the morning, because that is when the argument stops being abstract.

An alarm storm comes off a regional aggregation ring — a fibre cut, say, and the re-route logic underneath it doing something the capacity model did not expect. The assurance agent picks it up. It reads the fault manager, correlates a few thousand events down to a working hypothesis, checks the inventory system for what is actually deployed on the affected path, and begins executing: it re-homes traffic, adjusts thresholds on the elements that are now carrying the diverted load, and opens a change record describing what it did. Total elapsed time, a few minutes. The on-call engineer reads the summary over coffee at seven and agrees with all of it. This is the good outcome — the one the adoption numbers are about, the one the operators are right to want.

Now ask the question this practice always asks, which is not whether the agent behaved but what the agent presented. The agent instance held a workload identity minted at spawn — per-instance, short-lived, individually attributable, exactly as the platform team designed it. That identity authenticated to the agent platform. The platform authenticated to the orchestration layer with a service account provisioned at go-live. The orchestration layer reached the element managers with vendor service accounts provisioned under a managed-services contract. And the element managers talked to the network elements themselves with the credentials network elements actually understand: a management secret set at commissioning, shared across the element population, known to every system that has ever needed to reach those boxes and to every engineer who has ever worked on them.

Four hops. The identity at the top is hours old and names one agent instance. The secret at the bottom is older than the team that set it and names nothing, because the element cannot tell one caller from another — it knows one secret. Every distinction the platform team carefully constructed at the top of the chain is erased at the last hop.

The alarm storm, the agent workflow, the four-hop chain and the credential ages above are a constructed illustration, assembled from documented protocol behaviour, vendor documentation and published industry material. They describe no real operator, incident, network or engagement, and no part of this piece describes client work.

The inversion: fastest adoption, thinnest rulebook

Two facts about this sector have to be held at the same time, and each is usually cited by people who ignore the other.

The first is adoption, and the honest sourcing matters more than the number. In October 2025, Google Cloud published the second edition of its ROI of AI in telecommunications research, conducted by National Research Group. It reports that 56 per cent of telecom executives said their organisations were actively using AI agents in production, that 43 per cent said they had already launched ten or more, and that around 55 per cent planned to allocate at least half of future AI budgets to agents. That is a vendor-commissioned survey of executives' self-reports — a measurement of what leaders say, published by a company that sells the thing being adopted — and it should be read as exactly that. But the direction does not depend on the precision: no comparable survey in any other sector this practice tracks puts agents in production at a majority of respondents, and the operators' own public claims point the same way. Bharti Airtel has publicly attributed a 30 to 50 per cent reduction in mean time to resolution to AI-assisted network operations — a company claim, reported in trade press, not an audited measurement. Deutsche Telekom has announced, with Google Cloud, an agentic RAN Guardian whose company materials describe it working through roughly two hundred and thirty-seven thousand network events and cutting response times from hours to about a minute — a company announcement about a system built with the same vendor whose survey opened this paragraph, which is worth noticing and does not make it false. Whatever the exact figures, network automation agents are not a pilot category in this sector. They are in the operating estate, touching fault management, RAN optimisation and provisioning — the functions that hold the network up.

The second fact is the rulebook, and here precision matters even more, because the temptation in a piece like this is to gesture at regulation that does not exist. So, exactly what exists. In India, the instruments that govern anything adjacent to AI in telecom are the Telecom Commercial Communications Customer Preference Regulations, 2018 — TRAI's framework for commercial communications to subscribers — amended a second time in February 2025, with a draft third amendment in consultation as this piece is dated. Those regulations govern commercial messaging. They do not address network operations, automation, or anything an assurance agent does, and as of June 2026 India has no AI-specific telecom regulation at all. In the United States, the FCC's one consequential AI action in this sector is the declaratory ruling of February 2024 holding that AI-generated voices fall within the TCPA's restriction on artificial or prerecorded voices — a robocall ruling, protecting consumers at the network's edge. It says nothing about the network itself.

Put those beside each other and the shape is an inversion. In banking — the sector this practice has examined most closely — the April 2026 interagency model risk management guidance placed generative and agentic AI outside its scope and promised separate guidance: a deferral, with the obligation left in place and the specification withdrawn. Telecom does not even have the deferral. There is no framework from which agentic systems could be carved out, no promised consultation, no request for information on anyone's calendar. The sector deploying agents fastest is the sector where no supervisory document has ever contemplated them touching the network.

The comfortable reading of the silence is that it is a reprieve. The reading I will defend is that it is the opposite. A regulator that publishes a framework gives an operator two gifts: a specification to build against, and a defence — we met the standard. An operator in an unregulated lane has neither. Whatever credential lifecycle it runs is a choice it made, attributable entirely to it, and the record of that choice is what an incident inquiry, a security regulator acting under general powers, a cyber-incident reporting regime, or opposing counsel will eventually read. No regulator will tell an operator what the lifecycle should be. The operator that waits for the telling is not waiting for permission. It is writing its own future finding.

The estate the agents inherited

The credential problem in telecom is not that the estate is careless. It is that the estate is layered, each layer's credential model was correct for its era, and the agents are the first population that operates across all the layers at machine rate. Three species matter, and they are worth separating because they fail differently.

Species one: the shared secret on the box. Network elements authenticate their management plane with mechanisms standardised decades ago, and the standards are candid about what they are. RADIUS, per RFC 2865, rests on a secret shared between the network access server and the RADIUS server — recommended to be strong, in practice frequently reused across whole element populations because per-element secrets multiply the operational burden of every change. TACACS+, as documented in RFC 8907, protects its traffic with a mechanism the RFC itself is careful to call obfuscation rather than encryption, and the document's security considerations are frank that it does not meet modern standards without additional protection. SNMPv2c community strings travel in cleartext. NETCONF runs over SSH, per RFC 6242, which secures the channel — and says nothing about the lifecycle of the keys and accounts at either end. And beneath all of it sit the local break-glass accounts configured on the boxes themselves, for the day the AAA infrastructure is unreachable — accounts that never rotate, because rotating a credential whose entire purpose is to work when everything else is down is a change nobody will own. None of this is a scandal. It is the installed base, and the 2024 Blast-RADIUS disclosure — a chosen-prefix attack against RADIUS over UDP, industry-coordinated and publicly documented — was a reminder of how load-bearing that installed base still is.

Species two: the vendor service account. A large operator does not run its network alone. Element managers, network management systems and often whole network domains are operated under managed-services contracts, and every one of those arrangements is mediated by service accounts: the vendor's NOC into the operator's OSS, the vendor's engineers into the element managers, the integration accounts wired at project go-live. The accounts are provisioned per contract. Nothing deprovisions them per contract, because the deprovisioning event — contract end, renewal on different terms, transfer of a domain to a different vendor — arrives years after go-live, lands in a commercial team's inbox rather than an engineering queue, and no field on the credential says which contract it belongs to. Multi-vendor RAN makes this worse arithmetically: each vendor is a separate credential population with a separate lifecycle nobody owns end to end.

Species three: the agent fleet's own identities, minted on top. The newest layer is the one this practice has examined in general form elsewhere — a platform minting per-instance workload identities at machine rate, with issuance loud and deprovisioning silent, accumulating a residue of credentials whose owning workloads are gone. I will not re-argue that mechanism here; the companion analysis, written against the platform specifications, stands on its own. What telecom adds is the termination. In the general case, the machine-rate identity authenticates to APIs that can at least distinguish principals. Here, the fresh per-instance identity is the top of a chain whose bottom is species one and species two. The agent platform's beautifully attributable identity reaches the network through a vendor service account and a commissioning-era shared secret — so the attribution, the scoping and the short lifetime all terminate at the first hop that cannot honour them.

That termination is the specific telecom finding, and it is why importing a generic machine-identity programme does not answer it. You can run a flawless workload-identity estate at the top of the chain — short-lived, audience-bound, per-instance, everything the modern guidance asks — and the effective authority of every one of those identities is still the union of what the shared secrets at the bottom can reach. The blast radius of the fleet is set by the oldest credential in the chain, not the newest. And the oldest credential in the chain predates the fleet, usually by a decade.

Why rotation never happened, and why the reorganisation does not help

It is worth being precise about why the old species never rotate, because the reason is not negligence and treating it as negligence produces recommendations nobody can follow.

Five-nines availability is a budget of roughly five and a quarter minutes of unavailability in a year, and everything an operator does is shaped by that arithmetic. Rotating a secret shared across an element population is a coordinated change: every element and every system that authenticates to it must move together, or something is locked out. Lockout of a management plane is not a cosmetic failure — it is the loss of the ability to operate the very elements you would need to operate to fix the problem. So the rotation waits for a maintenance window. The window is contested, because every other risky change wants it too. The rotation is postponable and the alternative changes are not, so it is postponed. Each individual postponement is rational. The sum of the postponements is a secret that has outlived three network technology generations, and the sum was never anyone's decision.

The organisational half is quieter and does at least as much damage. A person's access in a well-run operator is attached to a role, and the joiner-mover-leaver process — whatever its faults — fires on reorganisations: the person moves, the entitlements are re-derived, something is revoked. The agent fleet's access is attached to nothing that reorganises. It hangs off platform service accounts and vendor integrations, and when the automation team is split, merged, outsourced or renamed, no process fires at all, because no person moved. The fleet's access is therefore the most durable access in the estate: it outlives every reorganisation precisely because the lifecycle machinery was built to watch people, and the fleet is not people. After the second reorganisation, the question 'who owns the assurance agents' credentials' has no answer that an org chart can produce — the org chart that provisioned them no longer exists.

Now put the three species and the two failure modes together, at the adoption rate the survey describes. Agents are being added to the estate at the fastest rate of any sector. Each agent multiplies the traffic across the old chains — more sessions presenting the vendor account, more actions executed under the shared secret, more of the network's daily operation flowing through credentials that cannot distinguish, cannot expire and cannot be attributed. The estate's exposure is not growing because anything got worse. It is growing because the numerator — actions taken under unattributable authority — is scaling with the agent fleet while the denominator — what the credential layer can say about any of it — is fixed.

/** The credential species an agent chain can terminate in, ordered by era. */
export type CredentialSpecies =
  /** Per-instance workload identity: short-lived, audience-bound, attributable. */
  | "per-instance-workload"
  /** Platform service account provisioned at go-live. One principal, many instances. */
  | "platform-service-account"
  /** Vendor account provisioned under a managed-services contract. */
  | "vendor-service-account"
  /** Management secret shared across a network element population. */
  | "shared-element-secret"
  /** Local account on the element for AAA-unreachable days. Never rotates. */
  | "local-break-glass";

export type Hop = {
  readonly holder: string;
  readonly species: CredentialSpecies;
  /** How many systems or elements share this credential. 1 means unshared. */
  readonly sharedAcross: number;
  /** ISO-8601 expiry, or null where no expiry exists. Null is a fact, not a gap. */
  readonly expiresAtIso: string | null;
  /** Named accountable owner, or null. For species four and five this is usually null. */
  readonly owner: string | null;
};

export type EffectiveAuthority = {
  /** True only if EVERY hop can distinguish this caller from every other. */
  readonly individuallyAttributable: boolean;
  /** The chain is live until its longest-lived hop dies. Null: some hop never expires. */
  readonly effectiveExpiryIso: string | null;
  /** The widest sharing anywhere in the chain — the real blast radius multiplier. */
  readonly widestSharing: number;
  /** Hops with no accountable owner. Each entry is a question with no addressee. */
  readonly unownedHops: readonly Hop[];
};

export function effectiveAuthority(chain: readonly Hop[]): EffectiveAuthority {
  if (chain.length === 0) {
    throw new Error("A workflow with no credential chain does not exist; it is unmapped.");
  }
  const individuallyAttributable = chain.every((hop) => hop.sharedAcross === 1);
  const anyNonExpiring = chain.some((hop) => hop.expiresAtIso === null);
  const effectiveExpiryIso = anyNonExpiring
    ? null
    : chain
        .map((hop) => hop.expiresAtIso as string)
        .sort((a, b) => Date.parse(b) - Date.parse(a))[0];
  const widestSharing = Math.max(...chain.map((hop) => hop.sharedAcross));
  const unownedHops = chain.filter((hop) => hop.owner === null);
  return { individuallyAttributable, effectiveExpiryIso, widestSharing, unownedHops };
}

/** The report an operator should ask for: one line per agent workflow, worst hop first. */
export function report(
  workflows: readonly { readonly name: string; readonly chain: readonly Hop[] }[],
): string {
  return workflows
    .map(({ name, chain }) => {
      const authority = effectiveAuthority(chain);
      const expiry = authority.effectiveExpiryIso ?? "never";
      const attribution = authority.individuallyAttributable ? "attributable" : "NOT attributable";
      return (
        name +
        "  " + attribution +
        "  effective expiry: " + expiry +
        "  widest sharing: " + String(authority.widestSharing) +
        "  unowned hops: " + String(authority.unownedHops.length)
      );
    })
    .join("\n");
}

The objection that deserves full strength

The strongest response to all of this comes from the people who actually run these networks, and it deserves stating properly, because operators are among the least naive infrastructure owners in the world and a piece that pretends otherwise deserves to be ignored.

The response goes like this. Telecom networks are attacked constantly, by well-resourced adversaries, and have been for decades; the sector's security engineering reflects it. Management planes are segregated onto dedicated networks that never touch the internet. Access to element managers runs through hardened jump infrastructure with session recording. Command authorisation restricts what an authenticated session can actually do, box by box. Vendor access is tunnelled, time-boxed and watched. And — the sharpest point — the industry did not stand still on credentials: when it designed the 5G core, it specified the modern answer into the standard itself. The service-based architecture in 3GPP TS 33.501 has network functions authorise one another with OAuth 2.0 client-credentials tokens, issued by the NRF acting as the authorisation server — short-lived, audience-scoped service authorisation, between machine principals, at carrier scale. The most modern part of a telecom network is arguably ahead of most enterprise IT on exactly the axis this piece complains about.

All of that is true, and I would go further: the SBA token architecture is the strongest evidence available that this sector knows precisely what good machine-to-machine authorisation looks like, because it wrote one into a standard when it had the chance to start clean. The concession is genuine. Here is what it does not cover.

The modernisation stops at the island's shore. The SBA governs network functions talking to network functions inside the 5G core. It does not govern the OSS that orchestrates across domains, the BSS that touches subscriber data, the element managers, the 4G and transport estates that will carry traffic for another decade, or the vendor integrations stitched across all of them — and those are precisely the layers an agent fleet operates in. An assurance agent does not live inside the SBA; it reaches into it, and into everything else, from the orchestration layer above. Its chain crosses the shoreline on every workflow, and the moment it does, the token discipline of the island is behind it and the shared secrets of the mainland are in front of it.

And the hardening, real as it is, answers a different question. Jump hosts, segregation and command authorisation constrain where a session can go and what it can do. They do not supply ownership, expiry or attribution for the credentials themselves. A vendor account reached through a recorded jump session is still a vendor account with no contract binding and no expiry; a shared element secret used from a hardened management network is still shared. The controls the sector built are containment controls, and they are good ones. The lifecycle — who owns this credential, when does it die, what happens to it when the contract ends or the team dissolves or the agent that used it is retired — is the layer nobody built, because until the agents arrived, the population moving through the containment was small enough, human enough and slow enough that the question rarely forced itself.

No one is coming to specify the lifecycle

The regulatory half of the argument has to be handled with the same discipline as the technical half, because the temptation to conjure an instrument is strong and the record here is an absence.

So, stated as findings. India's telecom regulator has produced no AI-specific regulation as of June 2026; the TCCCPR framework and its amendments, including the draft third amendment in consultation, govern commercial communications — the unsolicited-messaging problem — and nothing in that lineage addresses AI in network operations. The FCC's February 2024 declaratory ruling governs AI voices in robocalls under a consumer-protection statute from 1991. Across the Gulf, national AI strategies and sovereign-cloud programmes are reshaping where telecom infrastructure runs and who operates it, but no Gulf telecom authority has published an instrument specifying operational controls for AI agents in networks that this practice has been able to verify — and I am stating that as a verified absence rather than citing anything, because there is nothing to cite. Anyone who tells an operator that a telecom AI compliance regime requires this or that control is, as of the date on this piece, describing a document that does not exist.

The pattern in the adjacent sector is instructive for what it implies about sequencing. When the US banking agencies revised their model risk guidance in April 2026, they explicitly placed generative and agentic AI outside its scope and promised separate guidance — which means that whenever that guidance is written, it will be written against the practices institutions have built in the interval. Telecom is further back on the same road: not only is the specification unwritten, the intention to write one is unannounced. The interval is therefore longer, and everything built in it is built without a reference point. When a reference point eventually arrives — and after the first sufficiently public agent-driven network incident, one will — the material it is drafted from will be whatever the operators of 2026 and 2027 actually did. The operators deploying fastest are, whether they mean to or not, writing the first draft.

That is the sense in which the waiting operator is writing its own future finding. Not because a regulator will arrive with retroactive rules, but because the two documents that get written after an incident — the inquiry report and the eventual guidance — are both written from the record of what existed. An operator whose record shows per-domain credential ownership, measured rotation and a tested revocation path has written one kind of first draft. An operator whose record shows a vendor account from a contract that ended in 2023 executing changes on the RAN has written the other kind, and no amount of post-incident work rewrites it.

Where this argument is weakest

An argument that cannot name its own failure conditions is advocacy, so here are mine.

The adoption numbers are executive self-reports, commissioned by a vendor. The 56 per cent figure is what telecom executives told a research firm working for a cloud vendor with an agent product to sell, and 'agents in production' was defined by the respondents, not audited. Actual production adoption could be materially lower, and 'agents' in some answers is surely rebadged automation. I have attributed the figure exactly and built nothing on its precision. But honesty requires the converse concession too: if adoption is overstated, the exposure argument weakens in degree — fewer chains crossing the shoreline — while the structure of the argument is untouched, because the estate's credential species are what they are at any adoption level.

An operator that can produce the list falsifies this for itself. If an operator can produce, on demand, a census of every credential its agent workflows can present — species, sharing width, owner, expiry, contract binding — and can show a rotation performed on a shared element secret within the past year and a revocation observed as an actual refusal at an element manager, then for that operator this piece is a description of other people. That is directly testable, unannounced, with a clock running. My prediction, made without access to any operator's estate and falsifiable by any of them, is that the census arrives as a query somebody writes over several days rather than a record somebody holds, and that the last observed refusal predates the agent fleet.

The containment may genuinely be enough. The strongest technical counter is that segregation plus command authorisation plus session recording bounds the practical risk so well that credential lifecycle is a second-order concern — that an unrotated shared secret on a segregated management network with hardened jump access is, in expectation, safer than a rotated one on a flatter network. Within a single failure domain, that can be true. Where it fails is at the seams the agents create: an agent platform is by design a bridge across domains, reachable from the IT estate, holding standing paths into the management estate. The containment model assumed the two estates met at a small number of guarded crossings staffed by people. The fleet is a new crossing, wide, fast and permanent — and it is exactly at crossings that lifecycle, not containment, is the binding control.

The regulatory absence could end abruptly, and from an unexpected direction. Nothing prevents a telecom authority, a cyber-security agency acting under critical-infrastructure powers, or a licensing condition from imposing credential requirements with a short compliance window — India's regulatory metabolism in particular can be fast once engaged, and the draft third amendment shows the machinery is active, albeit pointed at commercial communications. If that happens, the 'no one is coming' framing was wrong in timing. It would also make the piece's recommendation cheaper, not dearer: everything argued here is what an operator would wish it had already built on the day such an instrument landed.

And one limit stated plainly: I know of no published incident in which an agent's inherited credential chain caused a network outage or a breach at an operator, and I am not claiming one has occurred. The argument is about what an operator can demonstrate when asked — by its own board, by an insurer, by a security regulator with general powers, or by the inquiry after the incident that has not happened yet. That is a narrower claim than a prediction of disaster, and it is the only claim the evidence supports.

Three measurements before any strategy

If the argument is right, the next useful hour is not a governance workshop. It is three measurements, each cheap, each currently unknown at most operators, and each convertible into a number a board can be shown.

1. The census. For each agent workflow in production, walk the credential chain to termination and record the species, sharing width, owner and expiry of every hop. The deliverable is the worst-hop report — one line per workflow. The prediction under test is that a majority of workflows terminate in species three or four, and that the owner field is null at the hop that matters.
2. The rotation rehearsal. Pick one shared element secret on a small, low-consequence population and rotate it, in a window, with the overlap and rollback machinery you would want at scale. Time it. The prediction is not that it fails; it is that it has never been done, and the first performance surfaces every reason it was always postponed — which is the real finding, because a rotation you have never performed is a revocation you cannot perform.
3. The refusal test. Revoke one vendor service account that a contract no longer justifies, and observe — at the element manager, not at the identity provider — the actual refusal. Measure the interval between the decision and the observed refusal. If the account cannot be revoked because nobody can enumerate what would break, that inability is the number: record it as infinite, and put it in front of the board as such.

None of the three requires a regulator's permission, a vendor's roadmap or a budget cycle. Together they convert this piece's argument from an essay into three rows of an operator's own data — and whichever way the rows come out, the operator knows something it did not know this morning.

What they do not do is tell the operator what to build. The construction — how to scope credentials per domain so the RAN, the core and the BSS are separate blast radii; how to rotate at five-nines without a cutover, by putting a broker in front of the species that cannot rotate; and what a revocation plane looks like when the agent being revoked is part of the machinery that responds to incidents — is a design with trade-offs that deserve full length, and it is the companion piece: Rotation at five nines, revocation mid-incident: a credential lifecycle for network agents.