Picture a platform team on an ordinary Friday afternoon. An automated agent they deployed last month has just opened a pull request, restarted a service and queried a billing table, all inside twenty minutes. Nobody is alarmed. Then someone asks a simple question: what exactly is that agent allowed to do, and who decided? The room goes quiet. That silence is the reason for this IAMOps checklist, a ten-point audit you can run before the next Friday arrives.
IAMOps is an informal label rather than an established discipline. The Ops Atlas page on IAMOps uses it for authorisation as code: designing, testing and refining the policies that decide what people, workloads and agents may do. Our fictional team will borrow that framing, and so will you.
Check 1 to 3: know the actor, the action and the room
1. Name the principal. Each agent gets its own identity, never a shared human login. If two agents share one identity, any audit trail merges them into a single blur.
2. List the actions in plain words. The Atlas breaks each decision into who, what, on which object and under what circumstances. Write the agent’s real tasks beside those four headings. Our imaginary team found that the agent needed to read two tables and write to one branch. It had been given an account that could do far more.
3. Record the context. Does the agent act from a fixed network, at certain hours, only against a staging environment? Context is where the cheapest restrictions live, because it narrows power without changing the job.
Check 4 to 6: separate the grants from the ceilings
4. Find every grant. Policies attached to the identity or the resource are what actually give access. List them all in one place.
5. Find every ceiling. Organisation-level caps and boundaries only limit; they never give. Teams sometimes believe a permissive-looking cap makes something possible, and the Atlas calls this out as a common myth. An explicit deny beats everything wherever it applies, so confirm one exists for the actions the agent must never take.
6. Trace the evaluation rule. Each platform combines these inputs differently. Read the rule for your platform instead of guessing, and write down one sentence a newcomer could repeat.
The team in our story sat down with their notes at this point and realised that the thinking behind how automated systems support business decisions applies in reverse. The same care a company takes before trusting an agent’s recommendation should be taken before trusting its credentials.
Check 7 and 8: make the keys short-lived and the rules testable
7. Replace standing keys with federated, expiring identity. The Atlas cites a 2025 survey in which active keys older than a year were found on more than half of cloud service accounts examined in one major provider. Agents that run from a pipeline can usually exchange a short-lived token instead of storing a secret. When a vendor breach in early 2023 exposed stored tokens, the lesson drawn was exactly that.
8. Put the policy in version control with a test. A rule nobody can run is a rumour. Keep the policy in a repository, require review, and add tests that prove the agent can do its tasks and cannot do a few forbidden ones. One caution from the Atlas: in Cedar, a policy that errors during evaluation is skipped, so a broken forbid rule can fail open. Validate against a schema so a typo cannot silently remove a guardrail.
Check 9 and 10: measure usage and agree a rhythm
9. Compare allowed with used. The Atlas works through a role that used 27 of 180 permitted actions, a utilisation of 15 percent. Run the same comparison on your agent after a month. Anything never used is a candidate for removal, with one exception: ask whether a quarterly job or a data-plane call is hiding from your logs.
10. Set a review beat and an exceptions register. Pick a monthly slot. Review the numbers, retire unused permissions, and keep a short register of deliberate exceptions with owners and end dates. If your team is still building the technical foundations underneath all this, a primer such as a skills roadmap for aspiring DevOps engineers will help new members get comfortable with the tooling quickly.
A short note on tone and ownership
Audits like this fail when they feel like blame. In our story the engineer who had created the agent’s account was the first to volunteer the list of its permissions, because the checklist asked about the account and never about the person. Keep that spirit. Assign each agent a named owner who is responsible for the sheet, and give that owner the authority to shrink permissions without a committee meeting. Widening should take a request; narrowing should take a message.
Agree beforehand on what counts as a surprise. If the agent is denied an action it should never attempt, treat the denial as a signal worth a glance, not noise to be filtered. A pattern of denials usually means the task description has drifted from the policy.
What happened next on that Friday
The team did not fix everything in one afternoon. They did produce a one-page sheet with the agent’s identity, its four-column description, the single grant it truly needed and one explicit deny for production writes. Three weeks later the sheet had a test, a reviewer and a date. When someone asked the original question again, the answer fit in a sentence.
If you want a way to score yourself, the Atlas lays out five rungs, starting at ad hoc then guarded, codified, measured and finally adaptive. A sensible first target is the second rung, no new long-lived keys. Run the ten checks, mark each one done, partial or missing, and choose the three weakest to fix before the next review.