Teams that run machine-learning-driven operations tend to spend their energy on data quality and model drift, then wave through the permissions behind the whole thing with a shrug. That habit is where IAMOps myths breed. The label is informal, and the Ops Atlas says so plainly, but the work it points at is real: writing, testing and tightening the policies that decide what people, services and automated agents are allowed to do. Here are six beliefs that keep circulating, and what the evidence says about each.

For the groundwork, the Ops Atlas entry on IAMOps frames the subject as authorisation expressed as code, and its framing is the lens used below. If you are weighing where automation should sit in your own team, our earlier walkthrough on getting an AIOps rollout right inside an IT group makes a useful companion to the list below.

Myth 1: “Grant broad access now and tighten it later”

It sounds pragmatic. Ship the pipeline, give the service an administrator role, plan a cleanup for next quarter. The trouble is what happens in the meantime. Once a broad role exists, every usage log you collect shows it working, and a working role looks like a needed role. The Atlas points out that this is how the later review ends up “proving” the admin rights were required all along.

Evidence-led alternative: start from a narrow grant, watch the denials, and widen with a ticket attached. Least privilege is a loop of setting, verifying and refining, not a one-time dial turn. The idea itself dates back to a 1975 security paper, so nobody can claim it is a fashionable newcomer.

Myth 2: “The vendor’s managed policy is the finish line”

Prebuilt policies are a perfectly good starting point. They are a poor destination. AWS itself warns that its managed policies may not be least-privilege, because they are written to cover many customers’ needs at once. If your model-training job needs to read one bucket and write to another, a managed data-access policy will almost certainly grant far more than that.

The practical route is to begin with the managed policy, measure which actions are really called, and trim. Teams that skip the measuring step end up with the broad policy permanently, simply with a friendlier name.

Myth 3: “An allow in an organisation-level policy gives people access”

Service control policies, resource control policies, permissions boundaries and session policies all share one trait: they limit. None of them grants anything. Identity-based and resource-based policies do the granting. Picture two overlapping circles; access exists only where a grant and every applicable ceiling agree, while an explicit deny overrules every grant it touches.

Why does this matter for an operations team? Because people write an “allow all” statement into a ceiling, see nothing change, and conclude the system is broken. The mental model of four inputs (who, doing what, to which resource, under what circumstances) plus a platform-specific combining rule fixes most of that confusion.

Myth 4: “A subject condition on the role makes it safe”

This one bites teams that federate their pipelines to the cloud in place of storing long-lived keys, which is otherwise a very good move. If the trust condition reads something like repo:acme/*, then every repository in that organisation can assume the role, including the experimental one a contractor created last week. The Atlas recommends exact, per-environment subjects instead of wildcards.

A quick test: could a repository you have never heard of satisfy the condition? If yes, the condition is decoration.

Myth 5: “If the policy looks right, the policy is right”

Reading a policy and testing a policy are different activities, and some failure modes only appear under test. Two examples from the Atlas stand out:

• Negated operators such as StringNotEquals will match when the context key is absent altogether, so a “deny unless tagged” rule can quietly apply to requests that carry no tag.
• With Cedar, a policy that throws an error mid-evaluation is simply passed over instead of rejecting the request. A forbid-style guardrail with a typo can therefore fail open, which is why schema validation belongs in the pipeline.

Contrast that with Google IAM, where a deny that fails to evaluate fails closed. The semantics differ by platform, and assuming one behaviour everywhere is how guardrails turn into false comfort.

Myth 6: “Tighter permissions always mean slower delivery”

Worry about friction is legitimate, so measure it. The Atlas’s worked metrics example tracks time-to-grant alongside denials per hundred changes after a deployment. In that illustration the wait for a new grant stretched from 36 hours to 48, a cost the team accepted once median permission utilisation across 120 roles moved from 22 percent up to 41 percent after one quarter of pruning. A slower grant bought a smaller blast radius, and the numbers made the trade visible.

If you already tune alert pipelines, the discipline will feel familiar; our write-up on cutting through event noise with smarter tooling follows the same measure-then-prune rhythm.

What to take away from the IAMOps evidence

The common thread across all six is that permissions drift toward comfort unless something measures them. Pick one role this week, compare what it can do with what it did over the last ninety days, and write down the gap. Then decide, with evidence rather than habit, which of the six beliefs above has been quietly shaping your environment. If the gap turns out to be large, share the numbers with the role’s owner before anyone touches a policy, because owners who see their own usage data tend to volunteer the cuts themselves. That conversation, repeated monthly, is most of what the discipline asks of an operations team, and it needs no special platform to begin.