Anyone who has managed a content platform knows the moment: a new freelancer needs to publish, the deadline is tonight, and somebody says “just make them an administrator, we will fix it later”. That sentence is the seed of most permission trouble. IAMOps, the routine upkeep of the policies that govern which actions people and programs can take, exists to stop that seed from sprouting. Six persistent myths stand in the way, and each one deserves a precise correction.
Myth 1: “Grant administrator now, tighten later”
The logic feels sensible, because you can always reduce access once the rush passes. In practice the reverse happens. Once someone holds broad access, their activity produces usage records that appear to justify it: they used the plugin settings, so they must need the plugin settings. The Atlas observes that later usage data tends to “prove” the administrator role was necessary. Start with a narrow role instead, and widen it on a specific request with an expiry. Removal is hard; addition is easy.
Myth 2: “A ready-made role is already least privilege”
Content platforms ship with tidy roles such as editor, author and contributor, and cloud providers offer prebuilt permission bundles. They are convenient starting points. They are not proof that the bundle matches your task. The cloud vendor’s own documentation cautions that its stock managed policies can exceed what a given task needs. Treat any packaged role as a draft, compare it with what the job actually does, and trim the difference.
Myth 3: “An organisation-level policy that says allow gives access”
Service control policies, a feature of one major cloud’s multi-account setup, never grant anything. They only set outer limits. A team that writes a broad “allow” at that level and wonders why nothing changed has misunderstood the mechanism. The same confusion shows up with permission boundaries and session policies. Grants come from identity or resource policies; ceilings only limit. When you hear “it is allowed at the top, so it works”, ask where the actual grant lives.
Myth 4: “Adding a subject condition makes the role safe”
When a deployment pipeline assumes a cloud role through short-lived federation, the trust rule usually checks a subject claim naming the repository. Writing a pattern such as an organisation name followed by a wildcard looks protective, but it admits every repository in that organisation, including ones created next year by someone else. Use exact subjects per repository and per environment. Precision in this one line is worth more than a page of other controls.
Myth 5: “Our site has no policy engine, so there is nothing to test”
Every platform has rules; the only question is whether they are visible. A CMS permission matrix, a hosting control panel and a cloud account all make allow-or-deny decisions. The discipline is to write those rules where people can review them, then test both the cases that should pass and the ones that should be refused. Teams that treat policy as code can put the files in the same repository as their templates and run checks before changes ship.
Myth 6: “Sign-on and two-step verification finish the job”
Strong sign-in answers who someone is. It says nothing about what they may do next. An authenticated account with excessive power is still excessive power. The Atlas draws a line here: identity operations cover who exists and how they log in, while this practice covers what they are permitted to do after that. A related but separate topic is how access is requested and temporarily elevated. Keeping the three concerns apart makes each easier to improve.
A worked example from a publishing desk
Say a publishing team runs a CMS, a hosting panel and a small cloud account for media storage. A contractor needs to upload images for two weeks. The myth-driven route gives them administrator on the CMS, a shared hosting login and a broad storage role, since “it is only two weeks”. The precise route creates an author-level CMS account, no hosting access, and a storage rule limited to one folder with an end date. Both routes take about the same time on day one. Only the second leaves a clean answer to the question “who could reach what?” when the engagement ends, and it is the one a reviewer can verify in minutes.
Why these six keep surviving
Each of them swaps a feeling of safety for a checkable fact. “Later” feels safe, packaged roles feel safe, a top-level allow feels safe, a wildcard subject feels safe. The cure is the loop the Atlas recommends: set a rule, verify its real effect, refine. Verify against usage, but remember blind spots such as infrequent jobs and calls that leave little trace, so a quiet permission may still be needed.
It also helps to name a few measurements so progress is not a matter of opinion. Track how many accounts hold administrator rights, what fraction of allow rules contain a wildcard, and how many credentials are older than ninety days. These three numbers, reviewed monthly, tell you whether the myths are losing ground in your own organisation or quietly regaining it.
Applying this on a content team
Start where the stakes are visible. Audit who can publish live pages, who can install extensions and who can touch hosting credentials. If you are thinking about page structure at the same time, a structural guide covering the essential pages for any business website offers a handy checklist for deciding which areas deserve tighter editing rights, and the reasoning in our note on service pages that convert visitors into clients shows why a stray edit to a revenue page is worth guarding.
For deeper detail on policy languages, maturity levels and pitfalls, the Ops Atlas IAMOps reference is a thorough, if lengthy, read. Whatever you adopt, write the rule, test it, and put a review date on it. Myths survive only where nobody checks.
