At 02:40 a pager goes off, and the engineer on call needs production database rights she does not hold. She asks in a chat thread, someone with admin rights pastes a role into her account, and she fixes the problem in twenty minutes. Nobody ever removes the role. Six months later it is still there, one of dozens that nobody remembers adding. That habit is the subject of AccessOps, and below it becomes a short inspection your own team could carry out before the end of the week.

The word is not an industry standard. The Ops Atlas entry on AccessOps at xOps School says as much: it uses the name editorially for the operations around requested and privileged access, resting on long-established practices: vaulting privileged credentials, elevating rights only at the moment they are needed, and keeping a sealed emergency account. For a team that already automates its operations, it is a useful lens, because every automated helper you add also needs to be given access.

Why an automation-heavy team should audit access first

Teams that lean on automated operations tend to have many machine identities, bots and scheduled jobs, each with its own rights. Our earlier piece on calming alert floods with smarter tooling described how a quieter console helps people focus. The same logic applies to permissions: fewer standing rights mean fewer things that can go wrong while nobody is watching.

The Atlas frames the whole area as a three-way split. Identity answers who is present, permission design answers what each party may do, and AccessOps covers the remaining piece: the manner and timing of each handover. An audit of that third question is quick, concrete and surprisingly revealing.

The twelve-point audit

Run these in order. Each one takes minutes, and most teams fail at least four.

Part one: the grant itself

1. Five fields per grant. Pick ten recent elevated grants. Can you point to the recipient, the scope, the stated reason, the end date, and whichever person or rule approved it? The Atlas treats those five fields as the minimum record. Missing fields are your first finding.
2. An end date exists. A grant without an expiry is a permanent role wearing a temporary costume. For ordinary requests the Atlas suggests a default expiry in the range of 90 to 180 days, with much shorter windows for the most sensitive tiers.
3. Eligible, not active. The preferred pattern is that people hold the right to ask, not the right itself. Count how many engineers are permanently active in your highest tier. That number is the one to push toward single digits.
4. The reason is readable. Scan the justification text. If most say “need access” or “ticket”, approvals have become a formality, which the Atlas lists as a typical result of blanket manager sign-off.

Part two: sessions and time

5. Test what expiry really does. The Atlas insists that a grant is not a session. In the lab it describes, an open remote shell outlasted its expired certificate by roughly twenty seconds, since validity is only tested when someone logs in. Try the same experiment on your own stack and write down the result.
6. Know your propagation delay. Cloud providers do not apply permission changes instantly. The entry quotes a typical figure of a couple of minutes for one major provider, sometimes seven or longer, and hours for some group changes. Your emergency procedure has to allow for that gap.
7. Check who can edit the rules. Anyone able to modify permissions can quietly extend their own access past its expiry. List those roles and treat them as the top tier.

Part three: the emergency door and the approvers

8. Break-glass accounts exist and work. The Atlas, drawing on vendor guidance, asks for a pair of emergency accounts held purely in the cloud directory, protected by phishing-resistant sign-in, wired to an alarm each time they are touched, and exercised at least once per 90 days. They stay permanently active by design, which is not a contradiction of the goal of removing standing rights.
9. Every break-glass use is reviewed fast. The worked example in the entry aims for a review within one business day.
10. Approver lists are not empty. A misconfigured approval rule that has no approvers can lock a whole tenant out. Test it in a sandbox.
11. Automated approvers are treated as top-tier systems. If a bot approves requests, whoever controls that bot controls access. The Atlas points out that one popular on-call integration verifies membership of the on-call rota while never confirming that a live incident exists. The entry allows a language model to condense a request for a human reviewer, but finds no documented, safe arrangement where such a model signs off top-tier access by itself.
12. Infrastructure code does not overwrite the grants. If your provisioning scripts reassert permission bindings authoritatively, they can erase or resurrect the access you thought you had changed.

Reading your score

Zero to four checks passed means the habit from the opening story is how your team works: access happens in chat and is never undone. Five to eight means you have a policy but not much proof it works. Nine to twelve means you are operating something close to the ladder the Atlas sketches, which starts at ad hoc, passes through inventoried and time-bound, and heads for just-in-time as the default.

A practical way to use the score is to write the failed items on a whiteboard and rank them by how much damage a stolen session could do through each one. Items touching your most sensitive systems go first, regardless of how easy the cheaper ones look. Share the ranking with the on-call rota too, because they live with the consequences of every tightened rule and will spot where a new time limit would slow a real incident.

Do not start by buying a tool. The entry is explicit that owning a privileged-access product does not mean access is being managed. Start with the inventory of your two highest tiers and a break-glass drill, then add time limits, then reason and multi-factor prompts, and only then consider approvals and session recording. If you are mapping this onto a larger plan, a simple walkthrough for bringing AIOps into your IT group is a sensible companion, since access decisions should be on the roadmap from the first sprint.

What happened to the engineer

The next time she was paged, she raised a request with a reason, a manager rule approved it in a minute because she was on the rota, and the role expired four hours later. The fix took the same twenty minutes. The difference is that the audit trail now answers all five questions, and the 02:40 shortcut no longer leaves anything behind.

That is the quiet promise of this discipline: the emergency path stays fast, and the cleanup stops depending on somebody remembering it.