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

At a glance

What this is: NHI Mgmt Group's analysis, drawing on C1.ai's blog post: Tide is operationalising least privilege by replacing static access grants with birthright profiles and just-in-time access.

Why it matters: It matters because IAM teams across human, NHI, and autonomous programmes are under pressure to turn access policy into repeatable, auditable operations instead of manual approvals.

By the numbers:

• Tide manages birthright access for more than 2,000 users using C1 access profiles driven by HR personas.

👉 Read C1.ai's blog on Tide's least-privilege access model and Terraform workflow

Context

Least privilege fails when access models stay static while work, applications, and approval paths keep changing. In this case, the governance problem is not whether policy exists, but whether access can be issued, reviewed, and removed in a way that matches actual use.

Tide’s approach shows the practical shift many IAM teams are making: move low-risk access into birthright profiles, reserve just-in-time access for sensitive systems, and express the whole model as configuration rather than manual ticket handling. That is the difference between policy intent and operational control.

The article is a useful lens for human IAM, but the same pattern matters for NHI governance whenever standing permissions, approval workflows, and rollback discipline need to be repeatable at scale.

Key questions

Q: How should teams decide which applications get birthright access and which need just-in-time approval?

A: Use business risk and task sensitivity, not organisational convenience. Low-risk tools that support daily productivity can sit in birthright profiles, while systems that move money, expose sensitive data, or can materially change state should require just-in-time approval with clear ownership and expiry logic.

Q: Why does least privilege often fail when it is managed manually?

A: Manual access handling usually creates slow approvals, inconsistent context, and standing permissions that survive long after the original need has passed. Once access lives in tickets, chat threads, and ad hoc exceptions, the organisation loses reliable control over who has what, for how long, and why.

Q: What are the signs that an access model is not really operationalised?

A: The warning signs are repeated manual escalations, inconsistent approval paths across applications, and difficulty rolling back access cleanly after a change. If teams cannot explain how an entitlement was granted, reviewed, or removed, then least privilege is still a policy aspiration rather than a working control.

Q: Should IAM teams use one workflow for SSO and non-SSO applications?

A: Yes, as far as possible. Different technical back ends can still feed the same request, approval, and fulfilment pattern, which reduces variance and makes the governance model easier to audit. The practical goal is one decisioning process, not one authentication protocol.

Technical breakdown

Birthright access versus just-in-time access in modern IAM

Birthright access is persistent, pre-approved access attached to a role or persona so new users can start work immediately. Just-in-time access is ephemeral and time-boxed, granted only when a user needs a sensitive system or action. The technical point is that Tide is splitting access by risk, not by department or broad role. That reduces standing privilege for high-value systems while keeping low-risk tools usable. The model depends on accurate persona mapping, strong request routing, and reliable revocation so that temporary access truly expires when the task ends.

Practical implication: separate low-risk entitlement paths from sensitive-system approvals so standing access only exists where the business risk is genuinely low.

Configuration-as-code for access control

Treating IAM configuration as code means access profiles, approval logic, and onboarding patterns are stored in version-controlled files instead of built by clicking through a console. In Tide’s case, Terraform creates peer review, rollback history, and reusable blueprints for new applications. That changes governance from a manual administration activity into an auditable change-control process. It also lowers the friction of scaling least privilege because new rules can be copied, reviewed, and tested consistently across applications. The architecture matters because access models become part of engineering workflows, not a separate admin queue.

Practical implication: express access logic in version control so changes inherit review, rollback, and repeatability instead of ad hoc admin handling.

Jira-driven approval workflows and operational consistency

The article shows a hybrid workflow where approved requests can create Jira work items for the identity team, while non-SSO applications are still brought into the same access request model through Okta groups. That matters because the control objective is not the ticket itself, but the consistency of decisioning, context, and fulfilment. If requests, approvals, and implementation steps live in disconnected channels like email, Slack, and manual ticket notes, the model breaks down. Tide’s design makes the request path predictable enough that identity engineers know what to do and when to do it.

Practical implication: standardise request-to-fulfilment workflows so approvals produce the same context and handling path every time.

Breaches seen in the wild

• Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Least privilege is becoming an operating model, not an access policy. Tide’s shift shows that the real control is no longer the written rule about who should have access. The control is the repeatable mechanism that issues, constrains, and removes access as work changes. For IAM teams, that means policy only matters when it is encoded into provisioning, review, and rollback processes.

Configuration-as-code is now an identity governance pattern, not just a DevOps convenience. When access profiles and JIT policies are managed in Terraform, governance moves into the same review and change-control layer as infrastructure. That improves traceability and reduces configuration drift. The practical implication is that identity teams increasingly need engineering-grade operating discipline to keep least privilege real.

Birthright and JIT should be treated as different risk classes, not competing access philosophies. Low-risk tools can remain accessible through persona-based birthright access, while sensitive systems need task-scoped JIT and approval gates. That split helps avoid the false choice between productivity and control. The lesson for practitioners is to classify access by operational risk, then govern each class differently.

Human IAM patterns are now the baseline for broader identity governance. The same operational logic that Tide applies to employees will increasingly be expected for service accounts, workload identities, and AI-driven access paths. Standing access, manual approvals, and inconsistent rollback are all signs of a governance model that will not scale cleanly across identity types. Practitioners should design one lifecycle discipline and adapt it by actor type.

Access review programmes will increasingly depend on whether teams can measure use, not just assignment. Tide’s planned removal of unused entitlements reflects a broader shift from entitlement ownership to entitlement activity. That change matters because governance based only on grants tends to preserve dead access. The implication is that identity teams need tighter linkage between access records, usage signals, and removal workflows.

From our research library:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
• Read next: Ultimate Guide to NHIs — Key Challenges and Risks

What this signals

Least privilege becomes durable only when it is encoded as a change process. Tide’s model shows that access control stops being theoretical once requests, approvals, and rollbacks are managed as versioned workflows rather than one-off admin decisions. That is the operational difference between a policy and a programme.

Access governance is drifting toward entitlement lifecycle management. The next control maturity step is not just granting access correctly, but removing unused access quickly and predictably. Teams that cannot link assignment, usage, and removal will struggle to keep pace with modern IAM, NHI, and autonomous access patterns.

For practitioners

• Standardise access by risk tier Map low-risk applications to birthright access and reserve just-in-time approvals for sensitive systems that move money or hold sensitive data.
• Move IAM changes into version control Keep access profiles, approval logic, and onboarding patterns in Terraform or an equivalent code workflow so changes are peer reviewed and reversible.
• Unify request handling across SSO and non-SSO apps Route non-SSO applications through the same request model by using groups and ticket integration so the fulfilment path stays consistent.
• Plan for entitlement cleanup based on inactivity Add a removal workflow for unused access and make re-requesting simple enough that teams will actually accept the tighter control model.

Key takeaways

• Tide’s model shows that least privilege only works at scale when access is separated by risk, not when every application follows the same grant pattern.
• The practical challenge is not defining policy but making approvals, rollback, and entitlement cleanup repeatable across applications and teams.
• IAM programmes that cannot manage access as code will struggle to keep standing permissions and manual exceptions from undoing least privilege.

Key terms

• Birthright Access: The baseline set of entitlements that a user should receive by default because of role, department, or another stable attribute. It is a governance construct, not a blanket permission model. The control challenge is proving that the baseline stays current as jobs, applications, and ownership change.
• Just-in-Time Access Request: Just-in-Time Access Request is a pattern that grants access only when it is needed and only for the duration required. It reduces standing privilege by making access temporary, policy driven, and task scoped. This approach is especially useful for contractors, sensitive systems, and short-lived operational work.
• 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.
• Entitlement Cleanup: Entitlement cleanup is the process of removing access that is no longer required. It includes revoking accounts, reducing licences, and retiring integrations that remain active after the business reason for access has ended.

What's in the full article

C1.ai's full blog covers the operational detail this post intentionally leaves for the source:

• Direct quotes from Tide’s identity leadership on why the organisation moved from static grants to needs-based access
• Implementation detail on how Terraform patterns are used to standardise access profiles and JIT workflows
• Examples of how C1 and Jira are connected to produce consistent work items for the identity team
• Specific onboarding and migration patterns for applications moving from manual access handling into the new model

👉 The full C1.ai post covers Tide's access profiles, JIT approvals, and code-based rollout patterns in more detail

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.