Rotation at five nines, revocation mid-incident

Start with the same three in the morning, because the design has to survive it. The alarm storm comes off the aggregation ring, the assurance agent correlates it down to a working hypothesis, and it needs to re-home traffic and adjust thresholds on the elements now carrying the diverted load. That much is unchanged and should be: this is the agent doing exactly what the operator bought it to do, and any design that makes this slower has failed before it is deployed.

What changes is the chain underneath. The agent instance presents a grant that names one domain — transport, in this case — and one verb set, and it presents it to a broker that sits in front of the element managers for that domain and nothing else. The broker holds the credential the elements actually understand. The agent never does, never has, and cannot be induced to: there is no code path by which the grant is exchanged for the underlying secret, because the broker performs the action rather than issuing the means to perform it. Total elapsed time is unchanged, because the broker adds a hop measured in milliseconds to a workflow measured in minutes.

At seven the on-call engineer reads the summary and agrees with all of it. But the second question — what did this agent actually present, and what else could that credential have reached — now has a short answer instead of a walk. It presented a transport-scoped grant, valid for the duration of the workflow, exchanged at the transport broker, recorded against the incident. It could not have reached the RAN, the core or the BSS, not because nobody asked it to but because a grant naming transport is not a value the other brokers will accept.

The alarm storm, the agent, the domains, the broker behaviour and every operational detail below are a constructed illustration, assembled from documented protocol behaviour, public specifications and published industry material. They describe no operator, network, incident, product or engagement, and no part of this piece is drawn from client work. The code listings are written to be read and argued with rather than deployed.

The three constraints that rule out the obvious answers

The companion teardown, The agents run the network now. The credentials were issued to people and boxes., establishes the termination walk and the arithmetic that a chain's properties are its worst hop's properties. I am taking that as established. What I want from it here is the negative space: the reasons the standard machine-identity playbook does not apply, because a design that ignores them is a design an operator will read politely and never build.

The estate cannot be taken down. Five nines is roughly five and a quarter minutes of unavailability across a year, and every operational decision in an operator is shaped by that budget. This rules out, immediately and permanently, any design whose first move is a coordinated cutover — every element and every caller moving together, in a window, with a rollback that requires moving them all back. Not because operators lack the discipline, but because the change competes for a contested window against changes that are not postponable, loses, and is postponed. The design has to be composed of steps each of which is individually reversible and none of which requires simultaneity.

The elements cannot be changed. The installed base authenticates the way it authenticates. RADIUS rests on a shared secret between the network access server and the server; TACACS+ obfuscates rather than encrypts, as its own RFC is careful to say; SNMPv2c community strings travel in the clear; NETCONF over SSH secures the channel and says nothing about the lifecycle of what is at either end. None of that is going to learn a new protocol because an operator adopted agents, and a large fraction of it will still be carrying traffic in a decade. So the design has to work in front of those endpoints as they are. Anything that requires the element to change is a ten-year programme wearing a one-year proposal's clothing.

The agents are part of the machinery keeping the estate up. This is the constraint unique to this sector, and it is the one that breaks designs imported from elsewhere. In a bank, revoking an agent's authority during an incident degrades a service. In a network, the agent under suspicion may be the thing correlating the alarm storm that the responders are working. A revocation plane whose only setting is off will be offered to an incident commander exactly once, declined, and thereafter not offered — and an unusable control is indistinguishable from an absent one, except that it appears in the register.

Those three constraints determine the whole design. Per-domain scoping follows from wanting the blast radius bounded without changing any element. Two-generation rotation behind a broker follows from wanting rotation without a cutover. The degrade tier follows from wanting a revocation plane that survives the incident it exists for. None of the three is clever; each is the only thing left standing after the constraints are taken seriously.

First move: three blast radii instead of one

The teardown's arithmetic is that the effective authority of every agent identity is the union of what the shared secrets at the bottom of its chain can reach. The cheapest way to change that arithmetic is not to fix the secrets — which the second constraint forbids — but to cut the union into pieces, so that a compromise or a misbehaviour in one domain does not arrive in another with credentials in hand.

So the estate is partitioned into domains — RAN, core, BSS, with transport commonly a fourth — and each domain runs its own credential broker in front of its own element population. An agent grant names exactly one domain. A grant scoped to RAN is not a weaker credential elsewhere; it is not a credential elsewhere, because the core broker will not accept a value that names another domain. The three-way split is the one most operators' organisational structure already implies, which matters more than it sounds: a partition that cuts across how the operator is actually run will be routed around by people trying to do their jobs.

The scoping is a refusal in the minting path, not a policy in a document. The broker either mints a grant naming one domain or fails. There is no multi-domain grant, no wildcard, no break-glass scope that spans everything, and no configuration flag that produces one. This matters for a specific reason: the multi-domain grant is exactly what someone will ask for at three in the morning, with a good reason, under pressure, from a person senior enough that the answer is yes. A policy is what gets waived in that conversation. A code path that does not exist is not waivable without a pull request, which is a slower and more visible event, and that difference is the entire value of stating it this way.

A cross-domain workflow becomes several scoped exchanges, not one broad credential. Plenty of real work spans domains — a provisioning flow that touches BSS and core, an optimisation that reads RAN and writes transport. The design does not forbid those; it forbids doing them with one credential. The agent holds a grant per domain, each obtained separately, each recorded separately, each revocable separately. The cost is more grants and more bookkeeping. The benefit is that the workflow's failure in one domain does not carry authority into the next, which is precisely the property the teardown says is absent today.

The core domain is where the modern island meets the mainland, and the broker is the shoreline. The 5G service-based architecture already specifies token-scoped, short-lived authorisation between network functions, with the network repository function acting as authorisation server. That is genuinely good and this design does not replace it. What the core broker does is front the parts of the core estate that are not inside the service-based architecture — the legacy elements, the signalling adjuncts, the transport interconnects — so that an agent reaching into the core through the orchestration layer meets one discipline rather than two. The island's rules stay the island's rules; the broker is what stops the mainland's rules being the ones that govern the whole workflow.

Second move: rotation that has a reverse gear

Rotation does not happen in this estate for a reason that is neither negligence nor ignorance. Rotating a secret shared across an element population is a coordinated change: every element and every caller must move together or something is locked out, and lockout of a management plane means losing the ability to operate the elements you would need to operate to fix the problem. So it waits for a window, loses the window to changes that cannot wait, and waits again. Each postponement is rational. The sum is a secret older than the team.

The broker dissolves the coordination requirement, and the dissolution is the whole trick. Because callers present grants and the broker presents the underlying secret, the number of parties that must know the secret drops to one. And because the broker is software rather than an element, it can hold two generations at once.

The sequence has five steps and the element experiences four of them as nothing at all.

1. Mint. Generation N+1 is created and configured on the element alongside N, where the element supports two — most AAA configurations and most element managers do, because the capability exists precisely for vendor transitions. Where the element genuinely supports only one, the broker holds both and the element change is deferred to the final step, which is the only step that touches it.
2. Accept both. The broker accepts either generation from any caller and counts presentations of each. The count is the migration dashboard, and it is a real number rather than an inventory belief.
3. Migrate. Callers move one at a time, each on its own schedule, with no simultaneity anywhere. A caller that fails to migrate does not break; it continues presenting N, and it appears in the count as a caller that has not moved. This is the step where the operator discovers the systems nobody knew were calling.
4. Drain. Wait until the presentation count for N is zero and has been zero for a defined period longer than the longest plausible dormant workflow. Zero is not the same as zero-for-an-hour, and the difference is the batch job that runs monthly.
5. Retire N. A broker-side change first, then the element-side removal. Everything before this point is reversible by continuing to accept N, which costs nothing and requires no coordination — that is what makes the whole operation schedulable.

The property worth naming explicitly is practisability. A rotation that has never been performed is a revocation that cannot be performed, because revocation under pressure is rotation with the overlap window set to zero. An operator that runs this sequence quarterly on a low-consequence population is not doing hygiene theatre; it is keeping alive the only muscle that the compromise scenario actually requires. Everything else in a credential programme can be documented. This one has to be exercised.

Third move: a revocation plane that survives the incident it exists for

Every credential design ends with a revocation section and almost all of them are one sentence long: withdraw the credential. In this sector that sentence collides with the third constraint, and the collision is not an edge case — it is the most likely circumstance in which revocation is ever contemplated. The reasons an operator wants to revoke an agent's authority are, disproportionately, reasons that arise during an incident, and during an incident the agent is frequently part of the response.

Tier one, revoke, and the metric is the interval to observed refusal. The grant is withdrawn at the broker. The part that matters is where the refusal is observed: not at the identity provider, which will report success instantly and mean nothing, but at the element manager, where the action is actually attempted and denied. The number to record is the interval between the decision and the first observed refusal, and it is the single most useful figure this design produces, because it is the one an operator currently cannot state at all. If the answer is that nobody can enumerate what would break, that inability is itself the number — record it as unbounded and put it in front of the board in those terms.

Tier two, degrade, and it is the default for the awkward case. Withdraw the write verbs and retain read and propose. The agent goes on correlating the alarm storm, goes on producing the hypothesis, goes on drafting the change — and executes nothing. The responders keep the analytical capability they are leaning on and lose the autonomous action they are worried about, which is the actual shape of the concern in almost every real case. This tier is the reason the plane gets used, and a design that omits it because it is inelegant has optimised for the diagram over the incident.

Tier three, sustain, and its expiry is automatic rather than decided. Sometimes the agent is genuinely load-bearing for restoration and stopping its writes would extend the outage. That case is real and pretending otherwise produces a control nobody uses. So it is admitted, and fenced: named, time-boxed, approved by two people, with every action recorded against the sustain decision rather than the original grant, and with automatic fallback to tier two at expiry. Automatic matters more than time-boxed. A sustain that requires a decision to end will not be ended, because the person who would end it is busy with the incident that caused it.

One consequence of the three tiers is worth stating as a risk rather than a feature, and it belongs here rather than in the objections. Tier two is comfortable, and comfortable options get chosen. An operator that reaches for degrade every time is running a control that never actually stops anything, and the tier distribution is therefore a thing to report on: if tier one is never used, either the estate has had no genuine compromises or the plane has quietly become a single setting again, and only the first of those is good news.

/** The estate's partition. Adding a domain is a deliberate act; there is no wildcard. */
export type Domain = "ran" | "core" | "transport" | "bss";

/** What an agent may cause to happen. Reads are separate and deliberately permissive. */
export type NetworkVerb =
  | "read-state"
  | "propose-change"
  | "apply-config"
  | "rehome-traffic"
  | "adjust-threshold"
  | "provision-subscriber";

/** A grant names exactly one domain. There is no multi-domain variant of this type. */
export interface DomainGrant {
  readonly grantId: string;
  readonly principal: string;
  readonly domain: Domain;
  readonly verbs: readonly NetworkVerb[];
  readonly issuedAtIso: string;
  readonly expiresAtIso: string;
  /** The incident, change record or workflow this grant was minted for. Never null. */
  readonly purposeRef: string;
  /** A named accountable owner. Not an authoriser of any individual action. */
  readonly accountableOwner: string;
}

export type MintResult =
  | { readonly ok: true; readonly grant: DomainGrant }
  | { readonly ok: false; readonly refusal: string };

export function mintGrant(input: {
  readonly principal: string;
  readonly domains: readonly Domain[];
  readonly verbs: readonly NetworkVerb[];
  readonly purposeRef: string;
  readonly accountableOwner: string;
  readonly issuedAtIso: string;
  readonly expiresAtIso: string;
}): MintResult {
  if (input.domains.length !== 1) {
    return {
      ok: false,
      refusal:
        "A grant names exactly one domain; " + String(input.domains.length) +
        " were requested. Obtain one grant per domain, so that each is separately revocable.",
    };
  }
  if (input.purposeRef.trim() === "") {
    return { ok: false, refusal: "A grant with no purpose reference cannot be reviewed later." };
  }
  const [domain] = input.domains;
  return {
    ok: true,
    grant: {
      grantId: "g-" + domain + "-" + input.principal + "-" + input.issuedAtIso,
      principal: input.principal,
      domain,
      verbs: input.verbs,
      issuedAtIso: input.issuedAtIso,
      expiresAtIso: input.expiresAtIso,
      purposeRef: input.purposeRef,
      accountableOwner: input.accountableOwner,
    },
  };
}

export type ExchangeResult =
  | { readonly ok: true; readonly performed: { readonly verb: NetworkVerb; readonly target: string; readonly atIso: string } }
  | { readonly ok: false; readonly refusal: string };

/**
 * The exchange. The return type is the entire argument: a performed action, never a
 * credential. There is no function in this module that hands an underlying element secret
 * to a caller, which is why the caller never holds one and why rotation never involves it.
 */
export function exchange(
  grant: DomainGrant,
  brokerDomain: Domain,
  request: { readonly verb: NetworkVerb; readonly target: string },
  nowIso: string,
): ExchangeResult {
  if (grant.domain !== brokerDomain) {
    return {
      ok: false,
      refusal: "Grant names domain " + grant.domain + "; this broker serves " + brokerDomain + ".",
    };
  }
  if (Date.parse(nowIso) > Date.parse(grant.expiresAtIso)) {
    return { ok: false, refusal: "Grant expired at " + grant.expiresAtIso + "." };
  }
  if (!grant.verbs.includes(request.verb)) {
    return { ok: false, refusal: "Verb " + request.verb + " is not in this grant." };
  }
  return { ok: true, performed: { verb: request.verb, target: request.target, atIso: nowIso } };
}

Building in a lane with no instrument

The regulatory frame for this construction has to be stated as the absence it is, and the discipline matters because the temptation to conjure a requirement is strong and the reader will check.

As of June 2026, India has no AI-specific telecom regulation. The instruments in that lineage are the Telecom Commercial Communications Customer Preference Regulations of 2018, amended a second time in February 2025, with a draft third amendment in consultation — and they govern commercial communications to subscribers, which is the unsolicited-messaging problem and not this one. In the United States, the FCC's declaratory ruling of 8 February 2024 holds AI-generated voices to be artificial or prerecorded voices under the TCPA: a robocall ruling, at the consumer edge, saying nothing about network operations. Across the Gulf, national AI strategies and sovereign-cloud programmes are reshaping where infrastructure runs, and I have not been able to verify any Gulf telecom authority instrument specifying operational controls for AI agents in networks. That is a verified absence and I am stating it as one rather than citing something adjacent.

Which means this design is not compliance work and I am not going to sell it as such. Nothing here is required by anything. The argument for building it is the inversion the teardown draws out: this sector reports the fastest agent adoption of any — a vendor-commissioned survey of telecom executives published in October 2025 put agents actively in production at 56 per cent of organisations, which is a self-report to a research firm working for a company selling agents and should be read as exactly that — while operating with no instrument that will specify the lifecycle. Operators' own claims run the same direction: 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 rather than an audited measurement, and Deutsche Telekom has announced an agentic RAN Guardian whose company materials describe response times falling from hours to about a minute. Every one of those is an organisation describing itself.

The consequence for a design decision is sequencing rather than obligation. When an instrument eventually arrives — and after a sufficiently public agent-driven network incident, one will — it will be drafted against what operators have already built, by people reading what operators actually did in the interval. That interval is open now and it is the only period in which an operator's own choices influence what it is later measured against. The same record does double duty: the inquiry after an incident and the guidance drafted afterwards are both written from what existed on the day.

The objections, at full strength

Four, and the first two come from people who run these networks and are right to raise them.

"You have built a new single point of failure in the one place we cannot afford one." This is the strongest objection and it is correct as stated. A broker in front of the management plane is a broker that, if unavailable, takes the management plane with it — and losing management access is the failure mode operators fear most, because it removes the ability to fix whatever else is wrong. Three things reduce it and none removes it. The per-domain split means the broker is four smaller components rather than one estate-wide one, so a failure is a domain outage rather than a network one. The design leaves the elements' own local break-glass accounts in place precisely as the path that does not depend on the broker, which is the same reason they exist today. And the broker is a stateless exchange in the request path, which is the easiest shape of component to run redundantly. But a reader who says this trades a credential risk for an availability risk has described the trade accurately, and an operator that cannot run the broker at the availability of the plane it fronts should not build it.

"Our containment already bounds this: segregated management networks, hardened jump hosts, command authorisation, session recording." All of that is real and this design does not replace any of it. The concession the teardown makes stands: those are good controls and they answer a different question. They constrain where a session can go and what it can do; they do not supply ownership, expiry or attribution for the credential itself, and they were dimensioned for a population of crossings that was small, human and slow. What this design adds sits underneath them rather than beside them — a vendor account reached through a recorded jump session is still an account with no contract binding, and the broker is what gives it one. Where the objection genuinely bites is on priority: for an operator with weak containment, containment first, obviously.

"The degrade tier will become the answer to everything, and you will have built a control that never stops anything." Likely, and I said so above rather than waiting to be pushed. The mitigation is measurement rather than architecture: report the tier distribution, and treat a period with no tier-one revocations as a question rather than a result. There is a harder version of this objection that I cannot answer — that offering a comfortable middle option changes what incident commanders choose even when the hard option is correct — and that is a claim about human behaviour under stress that I have no measurement of. If it is true, the right design has two tiers and a harder conversation, and I would want to know.

"Per-domain scoping is an org-chart artefact and our estate does not divide that cleanly." Often true, particularly where a single vendor operates across domains under one managed-services arrangement, or where transport and core have been consolidated. The design's requirement is not that the boundaries be these four; it is that there be boundaries, that they be few enough to be operable, and that they line up with how the estate is actually run rather than how it is drawn. An operator with two meaningful domains should build two brokers. An operator that concludes it genuinely has one domain has learned something significant about its blast radius and should say so out loud.

What it costs, with the unmeasured parts marked unmeasured

• Latency, per action, small. A broker hop on the management path. Milliseconds against workflows measured in seconds to minutes. This is the cost operators worry about first and it is the one that matters least.
• Availability engineering on the broker, substantial. The first objection is the real bill. The broker has to run at the availability of the plane it fronts, which means redundancy, health checking, and a tested path that does not depend on it. This is the line item that decides whether the design is affordable for a given operator.
• A grant per domain per workflow, permanently. More objects, more bookkeeping, more things to expire. The benefit is that each is separately revocable; the cost is that somebody has to run the thing that issues and reaps them.
• The quiet-period discipline. Retirement gated on observed presentations rather than plans means somebody has to determine and periodically re-determine the longest dormant workflow in the estate. Get this wrong low and a retirement locks out a monthly batch job at the worst moment.
• Rotation cadence, unmeasured. I do not know how long a full two-generation rotation takes across a real element population, because no operator has published one and I have not run one. That is the single most decision-relevant number for anyone scheduling this, and an operator can produce it in one rehearsal on a small, low-consequence population — which is why the build order below starts there.
• Interval to observed refusal, unmeasured and worth measuring first. Likewise unknown, likewise cheap to measure, and likely to be the most uncomfortable number in the programme.

If you had a week

The order is chosen so that the first two days produce findings whether or not anything else is built, because those findings are what get the rest funded.

1. Days one and two: measure, do not build. Walk one agent workflow's credential chain to termination and record every hop's species, sharing width, owner and expiry. Then revoke one vendor service account that a contract no longer justifies and time the interval to a refusal observed at the element manager. Two numbers, both currently unknown at most operators, both board-audible.
2. Day three: one domain, read-only broker. Stand the broker up in front of one domain's element managers, carrying read traffic only. Read-only first is not timidity; it is how you discover the callers nobody knew about without risking anything.
3. Day four: the scoped grant and the refusal. Mint domain-scoped grants for the agents in that domain and confirm, by attempting it, that a grant naming one domain is refused by another domain's broker. An enforcement you have not seen refuse is an enforcement you are assuming.
4. Day five: the rotation rehearsal. Run the five-step sequence on one low-consequence shared secret, end to end, including the retirement. Time it. The point is not that it succeeds; it is that the first performance surfaces every reason it was always postponed, and those reasons are the actual programme plan.
5. What to leave out this week: the other three domains, the degrade and sustain tiers, and any attempt to bring the 5G service-based architecture under the broker. Building the revocation tiers before the interval-to-refusal number exists produces a plane whose effect nobody can state.

What would falsify this design

An operator that can already produce the census and the refusal. If an operator can produce, on demand and unannounced, 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 an interval to observed refusal measured at an element manager, then this design is a description of something that operator has already built, and the piece is about other people. That is directly testable by any operator against itself, with a clock running.

Evidence that the broker's availability cost exceeds the exposure it removes. The first objection could win on the numbers. If broker-induced management-plane unavailability across a population of operators exceeded the losses attributable to unattributable credential use, the trade would be bad and the correct advice would be to invest in containment and attribution instead. Neither side of that comparison is published, I have not measured either, and I am not going to assert the direction. An operator that runs the broker for a year and measures its own contribution to management-plane unavailability would hold the most useful datum in this argument.

A vendor default that solves it at the element manager. If element manager vendors shipped per-caller credentials with owner, expiry and contract binding as the default — not as a capability that exists, but as what an operator gets without asking — then the broker is unnecessary middleware and the right move is to upgrade rather than to build. I have not found that default in vendor documentation, which is not proof of absence, and if it is shipping I would rather know than be right.

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