By NHI Mgmt Group Editorial TeamBased on C1.ai: “How Weaviate Automated Privileged Access And Turned Zero Trust Into A Customer Win” (October 24, 2025)

TL;DR: C1.ai says Weaviate cut access-management work from two days to two hours a week by automating privileged access across AWS, GCP and Azure, eliminating standing cloud access and letting developers request time-bounded access only when needed. The real lesson is that zero standing privilege works when access becomes policy-bound, ephemeral and invisible to users.


At a glance

What this is: This case study shows how Weaviate replaced manual cloud access handling with just-in-time privileged access, removing standing access and reducing the operational burden on its security team.

Why it matters: It matters because IAM teams must balance developer velocity with control, and cloud access governance breaks down when approvals, reviews and offboarding are still handled as manual tasks.

👉 Read C1.ai's analysis of automated privileged access and zero standing access


Context

Standing access becomes a governance problem when cloud permissions are kept open just to preserve developer speed. In this case, the issue was not only privilege scope but the operational cost of approving, tracking and reviewing access across multiple cloud environments.

Weaviate moved to just-in-time access so developers could request privileges only when needed and have them time-bounded and revoked automatically. That shift is a classic zero standing privilege use case for cloud IAM, where the control objective is to remove persistent admin access without turning security into a manual bottleneck.


Key questions

Q: How should security teams replace standing access with just-in-time access in cloud and virtual machine environments?

A: Security teams should treat standing access as a risk surface, not a convenience. Replace persistent SSH keys and shared paths with short-lived, task-scoped access, then tie elevation to identity, approval, and time limits. The control should be paired with discovery and ownership so every production identity is accountable and access can be reviewed without spreadsheet-driven audits.

Q: Why does manual access approval become a problem in fast-moving cloud environments?

A: Manual approval becomes a problem because cloud access changes faster than people can review it. When privileges are granted through tickets and separate admin accounts, visibility lags behind actual use, and offboarding or review happens after the risk window has already opened.

Q: What are the signs that cloud privilege controls are failing in practice?

A: Common warning signs include broad roles used for routine work, repeated exceptions that never get removed, and alerts that show access far beyond the original task. Another red flag is when teams rely on visibility tools alone and assume misconfigurations are enough to manage risk. If access is not continuously reviewed, privilege creep usually follows.

Q: What is the difference between just-in-time access and standing privilege?

A: Just-in-time access grants privilege only for a defined task window, while standing privilege remains active until someone removes it. JIT reduces exposure by shrinking the time an identity can be abused, but standing privilege creates a constant attack surface. For NHI programs, the difference is often the difference between contained risk and persistent exposure.


Technical breakdown

How just-in-time access changes privileged access governance

Just-in-time access shifts privilege from a persistent state to an issuance event. Instead of leaving an admin account active, the user requests access, a policy evaluates the request, and a bounded entitlement is granted for a limited period. That reduces the standing permission window and makes the control easier to audit. The important detail is that the identity does not become more trusted in general. It receives narrowly scoped access for a specific task, then returns to a lower privilege baseline.

Practical implication: move privileged cloud access from always-on role assignment to policy-based issuance with automatic expiry.

Why manual access reviews become brittle in fast-moving cloud teams

Manual access reviews are designed to confirm whether existing privilege is still justified, but cloud teams that operate at speed often accumulate access faster than reviewers can inspect it. When access is granted through ad hoc admin accounts and tracked in tickets, the review process becomes retrospective and incomplete. The result is visibility lag, not governance. JIT access improves this by making the privilege event itself the governance moment, which is easier to trace than a standing account that may have been active for weeks or months.

Practical implication: treat access issuance as the control point instead of relying on periodic review of long-lived cloud permissions.

How CLI-native workflows reduce bypass pressure on access controls

When security tools force developers into separate portals and ticket queues, teams often look for the fastest path around them. A CLI-native access flow embeds approval, tracking and revocation into the working context developers already use. That does not remove governance. It reduces the incentive to bypass it. In practice, the architecture matters because controls that fit the workflow are more likely to be used consistently than controls that sit outside it.

Practical implication: align privileged access workflows with the developer environment so policy is followed instead of worked around.


Threat narrative

Attacker objective: The objective is to abuse persistent cloud privilege to reach resources that should only be accessible for short, task-scoped windows.

  1. Entry begins when developers hold separate admin accounts or always-on cloud permissions that remain available outside the immediate task.
  2. Escalation occurs when those standing privileges are retained across environments, creating a wider access surface than the work actually requires.
  3. Impact is the prolonged exposure of cloud resources and the administrative burden of proving, reviewing and revoking access after the fact.
  • 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.
  • Uber breach 2022: A contractor's stolen password and MFA fatigue gave a Lapsus$-linked attacker Uber's internal tools; Uber rotated keys to many services.

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

Zero standing privilege is no longer a theoretical hardening pattern for cloud teams. This article shows that persistent admin access can be removed without collapsing developer workflow when privilege is issued just in time and revoked automatically. The governance point is bigger than convenience: persistent access is a risk state, not a productivity requirement, and cloud IAM programmes should treat it that way.

Manual access administration does not scale with cloud velocity. If reviews, approvals and offboarding still depend on humans moving tickets, the control plane becomes the bottleneck and the audit trail becomes stale. The practical conclusion is that access governance has to move from periodic administration to policy-driven issuance and expiry, especially in AWS, GCP and Azure.

Developer experience is now an access-control variable. Controls that slow legitimate work create bypass behaviour, while controls that fit the terminal, the pipeline and the cloud workflow are more likely to be used correctly. IAM teams should stop treating usability as a separate concern from security design because in fast-moving engineering organisations, it determines whether governance is adopted at all.

Standing cloud privilege remains the clearest sign that privilege has been granted for convenience rather than necessity. The article reinforces a named concept worth tracking: persistent privilege drag, where the operational comfort of always-on access outlives the task that justified it. Practitioners should view that drag as a control failure, not an acceptable trade-off.

JIT access is strongest when it is treated as an identity governance model, not just a request workflow. The article shows the value of combining policy, revocation and visibility across cloud and internal systems so that the governance model spans the whole access lifecycle. That is where cloud IAM, PAM and lifecycle governance start to converge in practice.

From our research library:

What this signals

Persistent privilege drag: cloud programmes often keep access open because it is operationally convenient, not because the task requires it. Weaviate’s experience shows that the control problem is less about granting access and more about eliminating the habit of treating standing privilege as the default state.

Policy-based issuance changes the governance model from retrospective review to controlled entitlement creation. For IAM and PAM teams, that means the decisive question is no longer who can approve access fastest, but which privileges should never persist beyond a task boundary.


For practitioners

  • Replace standing cloud admin access Move privileged cloud permissions to time-bounded issuance so access exists only for the task being performed, then expires automatically.
  • Review access governance outside ticket queues Map where approvals, reviews and offboarding still depend on manual tickets, then shift those steps into policy-based controls that can be audited.
  • Extend JIT policy to internal systems Apply the same privileged access rules to customer-facing and internal systems so governance does not stop at the cloud control plane.
  • Measure standing access reduction Track how many privileged accounts remain always-on, how long they stay active and where developers still need separate admin identities.

Key takeaways

  • The article shows that cloud access governance becomes more effective when privilege is granted only when needed and revoked automatically after use.
  • Weaviate reduced access-management work from two days to two hours a week, illustrating how automation can shrink the operating burden of secure access.
  • The control lesson is that standing admin access should be treated as a governance defect, not an acceptable default for developer convenience.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Non-Human Identity Top 10NHI-05 — Overprivileged NHIThe article centres on standing cloud admin rights that exceed task need.
NHI-07 — Long-Lived SecretsJIT access addresses the risk of permissions that remain valid beyond the work session.
Recommendation — Reduce cloud privilege to the minimum scope needed for each task and remove always-on admin rights. Shorten credential lifetime and revoke access automatically when the task ends.
NIST SP 800-53 Rev 5AC-6 — Least PrivilegeThe article is fundamentally about enforcing least privilege in cloud access governance.
Recommendation — Apply least-privilege controls to ensure privileged access exists only when operationally necessary.
NIST CSF 2.0PR.AA-05 — Access Permissions, Entitlements and AuthorizationsCloud access issuance, review and revocation map directly to entitlement governance.
Recommendation — Govern access permissions and entitlements with policy-driven approval and removal workflows.
MITRE ATT&CKTA0004;TA0006 — Privilege Escalation; Credential AccessPersistent cloud privilege expands the avenues attackers use to gain and exploit credentials.
Recommendation — Monitor for privilege escalation and credential access paths created by standing cloud permissions.

Key terms

  • 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.
  • Zero Standing Privilege: A control model in which an identity does not keep persistent access unless it is actively needed. For NHIs, this means credentials and permissions are issued for a narrow task and then removed. It reduces the time window and reuse value of stolen access.
  • Dynamic Privileged Access Governance: Dynamic privileged access governance is the practice of applying access controls that adapt to changing cloud conditions, user context, and task requirements. It replaces static, long-lived entitlements with policies that can issue, monitor, and revoke privilege in a way that better matches the pace of cloud operations.
  • Usage Entitlement: Usage entitlement is the policy that determines who or what may consume a service, how much they may consume, and under what conditions. For AI systems, it increasingly overlaps with financial governance because consumption itself creates cost exposure.

What's in the full article

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

  • How Weaviate used policy-based automation to replace manual access requests across AWS, GCP and Azure
  • How Cone CLI changed the developer workflow for requesting privileged access from the terminal
  • How Baton SDK was used to extend governance to customer-facing and internal systems
  • How the team measured the shift from two days of work to two hours per week

👉 The full C1.ai post covers the workflow changes, policy setup and operating results behind the access model

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.
NHIMG Editorial Note
Published by the NHIMG editorial team on June 7, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org