Tide’s least-privilege shift shows where IAM is heading

At a glance

What this is: Tide is replacing static access grants with a needs-based model that combines birthright access and just-in-time requests, showing how least privilege can be operationalised at scale.

Why it matters: IAM teams across NHI, autonomous, and human identity programmes need to see how access governance becomes more consistent when approvals, configuration, and rollback are managed as code.

By the numbers:

• Tide manages birthright access for more than 2,000 users using C1 access profiles driven by HR personas.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.

👉 Read ConductorOne’s post on Tide’s least-privilege operating model

Context

Least privilege is easy to describe and hard to run at enterprise scale. The gap is usually not policy intent but the operating model behind it: access grows through exceptions, manual approvals, and stale grants that nobody revisits quickly enough. For human identities, that produces role drift; for NHIs, it becomes standing privilege and forgotten credentials; for autonomous actors, it can become a broken assumption about how long access exists at all.

Tide’s approach is a practical example of turning access governance into an execution model rather than a ticket queue. The post shows a move from static role-based grants toward birthright access for low-risk applications and just-in-time access for sensitive systems, with configuration managed in Terraform and approvals routed through standard workflows. The pattern is familiar to any mature identity programme, but the discipline required to maintain it consistently is still rare.

Key questions

Q: How should security teams implement just-in-time access without creating too much friction?

A: Start with the systems that carry the highest business or data risk, then make the request path consistent and predictable. The goal is to make elevation easy to justify and simple to revoke. If approvals are slow, opaque, or different for every application, users will push for standing access instead of following the control.

Q: Why do role-based access models often lead to over-privilege over time?

A: Role models age because jobs change faster than entitlement reviews, and exceptions accumulate faster than teams clean them up. Once a role becomes a proxy for convenience, it starts carrying access that no longer matches current need. That creates privilege drift, which is especially hard to spot when review cycles are slow.

Q: What do teams get wrong about managing access with configuration as code?

A: They often treat code as a faster way to do the same manual process. The real benefit is governance: pull requests, peer review, traceability, and rollback create a change-control loop that is much harder to achieve through console-based administration. Without that discipline, code only automates inconsistency.

Q: How should IAM teams decide which entitlements should stay birthright and which should move to JIT?

A: Use risk, not habit, to separate the two. Low-impact collaboration tools can stay in a baseline model if the business need is stable, while sensitive systems should move to time-bound, approval-based access. Reassess the split regularly, because a low-risk application can become high-risk as its data or permissions change.

Technical breakdown

Birthright access and just-in-time access in the same control plane

Birthright access gives users a baseline set of permissions when the risk is low and the entitlement is broadly expected, such as common collaboration or productivity tools. Just-in-time access adds a time-bound approval step for sensitive systems, so privilege exists only for the task window and then expires. The key architectural point is that both models must live in the same governance flow, otherwise teams recreate shadow exceptions and untracked grants. In practice, this means the identity team needs one policy model, one audit trail, and one lifecycle path for requests, approvals, and revocation.

Practical implication: separate low-risk default access from sensitive-system elevation in a single governed workflow, not across disconnected processes.

Terraform and configuration-as-code for identity controls

Configuration-as-code turns access policy into reviewable infrastructure rather than click-path administration. In Tide’s model, identity changes can be proposed through pull requests, peer-reviewed, rolled back, and reused as templates. That matters because identity controls fail quietly when changes are opaque or inconsistent across applications. Terraform also helps teams standardise onboarding for new applications, especially when different systems need different access patterns but the governance rules should remain consistent. The benefit is less about speed and more about repeatability with traceability.

Practical implication: move access policy definitions into version-controlled code so changes can be reviewed, tested, and reversed like any other infrastructure change.

Access profiles as a governance layer for personas

Access profiles map identity attributes or job personas to approved entitlements, which reduces ad hoc granting and makes baseline access easier to explain. In the article, Tide uses persona-driven profiles for birthright access, which is a pragmatic way to align business role with access scope. The limitation is that profiles only work when the persona model is accurate and kept current. If the underlying HR or org data is stale, the profile becomes a new source of over-access. So the control is only as good as the lifecycle data feeding it.

Practical implication: keep persona mappings synchronized with HR and application ownership data, or the access profile layer will simply automate privilege drift.

Breaches seen in the wild

• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.
• IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Least privilege at scale fails when organisations treat access as a one-time assignment instead of a governed lifecycle. Tide’s move from static grants to birthright plus just-in-time access shows the real boundary: least privilege is not a policy statement, it is an operating model with request, approval, expiry, and rollback. Without that lifecycle, standing access accumulates across human identities, service accounts, and adjacent automation. Practitioners should treat access state as disposable unless there is a current business need.

Configuration-as-code is now a governance requirement, not an engineering preference. The meaningful shift in Tide’s model is not simply that Terraform is used, but that identity controls become peer-reviewed, repeatable, and revertible. That closes the gap between design intent and actual access state, which is where most privilege creep begins. For IAM and IGA teams, the lesson is to govern identity changes with the same change-control discipline used for infrastructure.

Identity profile drift: access models break when job personas, approval chains, and entitlement maps stop reflecting the real operating context. Tide’s persona-based birthright model works because low-risk access is pre-aligned to defined roles, but the model depends on accurate business data and application ownership. When those inputs drift, the profile layer becomes a distribution mechanism for stale access rather than a control. Practitioners should treat profile accuracy as a core control, not a documentation task.

JIT access becomes the practical control point where least privilege meets user productivity. The article shows why teams keep reverting to standing access: manual tickets and inconsistent context make time-bound access painful. The governance answer is not to relax the model, but to make the request path predictable enough that users do not bypass it. That is the difference between a policy teams endorse and a policy they actually operate.

For NHIs, the same least-privilege logic gets harsher because there is no human to compensate for stale access. The NHI reality is that excessive privilege, slow revocation, and poor offboarding create persistent blast radius. NHIMG research shows 97% of NHIs carry excessive privileges and only 20% of organisations have formal offboarding and revocation processes for API keys. The practitioner conclusion is straightforward: if the process cannot safely govern human access, it will fail even faster for machine identities.

From our research:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
• To operationalise lifecycle control, review the NHI Lifecycle Management Guide alongside OWASP Non-Human Identity Top 10.

What this signals

Identity programmes will keep running into the same problem until access state becomes disposable by default. The Tide model is useful because it shows how to make access reversible without turning every request into a manual project. That matters for NHI governance too, where long-lived credentials and delayed revocation still drive most of the real exposure.

Least privilege only becomes operational when review, expiry, and rollback are treated as one control family. If those functions live in separate workflows, teams will keep fixing the same access problem in different systems. That is why identity engineering is increasingly becoming a policy-as-code discipline rather than a ticket-resolution discipline.

With 70% of organisations granting AI systems more access than they would give a human employee performing the exact same job, per the 2026 Infrastructure Identity Survey, the same governance pattern now needs to extend across human, NHI, and autonomous actors. The organisations that can express policy once and enforce it consistently across those actors will have a material governance advantage.

For practitioners

• Map access by risk tier, not by convenience Define which applications qualify for birthright access and which must always require just-in-time approval. Review the sensitive set first, then keep low-risk tools on the simplest possible baseline entitlement path.
• Move access policy into version-controlled code Store entitlement profiles, approval rules, and application onboarding patterns in Terraform or an equivalent code repository. Require peer review for every change and make rollback part of the standard change process.
• Tighten persona data before expanding profiles Validate that HR persona mappings, application ownership, and group memberships still reflect real job functions. If the input data drifts, the profile layer will distribute over-access faster than manual review can catch it.
• Standardise JIT for sensitive systems Use one approval path, one ticket format, and one expiry rule for systems that hold sensitive data or move money. Consistency reduces exception handling and makes revocation easier to prove.
• Apply the same control logic to NHIs Extend the same lifecycle discipline to service accounts, tokens, and API keys so standing privilege does not become the default. Build revocation and expiry checks into the operating model, not just the policy.

Key takeaways

• Tide’s model shows that least privilege is an operational system, not a policy slogan.
• Configuration-as-code makes access governance reviewable, repeatable, and reversible.
• The same lifecycle discipline that reduces human over-access is even more urgent for NHIs and AI-driven access paths.

Key terms

• Just-in-time access: Just-in-time access is a governance pattern that grants elevated permissions only for the period needed to complete a specific task. It reduces standing privilege by making access temporary, approval-based, and easier to audit across human identities, service accounts, and autonomous workflows.
• Birthright access: Birthright access is the baseline set of entitlements a user receives automatically because they belong to a role or persona. It is useful for low-risk applications, but it becomes a control failure when the persona data is stale or when low-risk access quietly expands into sensitive systems.
• Configuration as code: Configuration as code means identity policy, entitlements, and access workflows are managed in version-controlled files instead of only through consoles. It turns access changes into reviewable, reversible change events and makes governance more consistent across applications and teams.
• Privilege drift: Privilege drift is the gradual accumulation of access that no longer matches current business need. It usually starts with exceptions and manual fixes, then hardens into standing access that survives longer than the original reason for granting it.

Deepen your knowledge

Least privilege, just-in-time access, and identity configuration-as-code are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are modernising access governance in a similar way, it is worth exploring.

This post draws on content published by ConductorOne: How Tide Uses C1 to Operationalize Least Privilege at Scale. Read the original.