Machine-learning platforms collect powerful keys faster than almost any other system: model registries, feature stores, GPU clusters, training buckets, prompt configurations, and the service accounts that tie them together. AccessOps, the practice of deciding how and when elevated permissions are granted, deserves a place in any AI team’s runbook. Here are eight practical rules, written for people who run models in production and would rather not read a policy novel.

1. Separate “who may look” from “who may change”

Most teams give data scientists broad read access, and that is fine. The trouble starts when the same standing role also lets them overwrite a production model or edit a serving configuration. Keep write access to anything customer-facing out of the everyday role. Make it something a person asks for, for a stated task, for a limited time.

A useful test is to imagine your most trusted engineer having a bad day with a stolen laptop. Whatever the thief could change in production from that machine is what your everyday role really grants, regardless of what the policy document claims.

2. Write down five facts per grant

One write-up worth bookmarking is the Atlas page that defines AccessOps, which argues that every elevated grant should record who holds it, what it covers, why it exists, when it ends and who or what approved it. Apply that to a GPU admin role or a registry-publish permission. If any field is blank, the grant is not finished. Anyone who has tried to explain an unexplained admin binding during an incident knows how useful five filled-in boxes are.

3. Prefer expiry dates over reminders

Think about how many notebooks, pipelines and experiment dashboards one engineer touches in a month, and you will see why memory is a poor control.

A calendar nudge to “remove access later” fails the first busy week. Let the system expire the grant itself. The Atlas suggests short windows for the most sensitive tier, roughly an hour or two, a few hours for the next tier, and longer ones for routine requests, with ordinary requests defaulting to a quarter or half a year. For a training run that needs elevated access to a cluster, a four-hour window matched to the job is easier to defend than an open-ended role, and it makes the audit trail obvious to whoever reads it later, whether that is a teammate or a customer’s security reviewer.

4. Remember that a grant is not a session

Time-boxing sounds airtight until you read the footnotes. The Atlas lab showed a remote shell surviving about twenty seconds past the certificate that created it, since the check happens only at login. Cloud role sessions can remain valid until their own expiry, and permission changes may take minutes to spread. For AI platforms where long notebook sessions are normal, ask the awkward question: what actually terminates a running session when the grant ends? If the answer is “nothing,” shorten the session lifetime too.

5. Do not let a model approve its own kind of access

This one is specific to our field. The Atlas notes it knows of no documented safe design in which a language model approves privileged requests at the top tiers; at most it may summarise a request for a human reader. It also reminds readers that any automated approver is itself highly privileged, because whoever can influence it can mint access. One example it gives: a popular on-call plugin only checks whether the requester is on the rota, not whether an incident is genuinely open. A rule like that is only as good as what it checks.

If you are curious what machine reasoning is genuinely good at in business settings, our earlier piece on how AI sharpens everyday business decisions covers the upside. Approving someone’s root access is not on that list.

6. Keep an emergency account, and treat it like a smoke alarm

Break-glass accounts are the exception to the “no standing privilege” rule, and the Atlas says they should stay permanently active by design. It lists the usual guardrails: at least two cloud-only accounts, sign-in methods that resist phishing, an alert on every use, and a validation exercise at least every ninety days, which matches what Microsoft asks of its customers. If your ML platform shares an identity provider with the rest of the company, an outage there should not strand the team that trains your models.

7. Measure it with a handful of numbers

You do not need a dashboard product for this. A spreadsheet fed from your grant log is enough to start, and the trend matters more than the precision.

The Atlas suggests a compact set of measures: how many privileged accounts stand permanently, what share of elevated access goes through the time-boxed route, how long requests take at the median and the slow end, how much of each grant is actually used, and how quickly emergency use is reviewed. Its worked month is instructive. Four hundred four-hour grants hand out 96,000 minutes, yet only 24,000 minutes were recorded as used, a quarter. If your GPU admin windows look similar, the windows are too long, and tightening them is free.

The same example showed standing Tier 0 and Tier 1 accounts falling from thirty-four to nine over the period, and two emergency uses leaving seven to explain. Small numbers, but they are numbers you can chart.

8. Review, but do not rely on reviews alone

Periodic access reviews are still worth running, and common control sets ask for them at least yearly. Flag dormant accounts too; the Atlas mentions a forty-five-day idle marker in one control framework and a thirty-day “no sign-in” recommendation in Microsoft’s review tooling. But reviews are a backstop. The federal maturity model the Atlas cites treats permanent access plus review as the traditional starting point, not the goal.

One more trap deserves a mention: logging everything and examining nothing. Session recordings are valuable only if somebody samples them, so pick a small, regular slice of recorded privileged sessions and actually watch it.

A quick pass for your own stack

Set aside one afternoon. You will not fix everything, but you will learn where the biggest gaps sit, and that is what lets you argue for engineering time later.

• List every role that can publish or overwrite a production model.
• Count how many are standing and how many are requested.
• Pick the riskiest three and move them to short, approved windows.
• Run one emergency-account drill and note what broke.

Teams that already work with perception systems, such as the image-classification walkthrough we published, tend to guard their labelled datasets carefully. Extend the same instinct to the people and pipelines that touch those datasets. Access to data, models and infrastructure is operational work, not a one-off setup task, and doing it deliberately now will save an uncomfortable afternoon later.