In most organizations, standing privileges don’t show up all at once. They accumulate quietly. A role is added “temporarily.” A contractor needs broad access to finish a project. A service account gets oversized permissions because no one has time to fine-tune them. None of these choices seem harmful in the moment, but over time they build into a privilege surface that’s far too large and far too easy to misuse.

The challenge is that standing privileges often look harmless until something finally goes wrong. The indicators are visible long before the incident, but only if you know where to look. Here are five of the clearest signs that your environment is carrying more access risk than it should.

1. You Have More Admins Than Your Environment Actually Needs

Admin creep happens naturally. In fast-moving environments, the easiest way to unblock a task is to give someone full access. It works. It’s quick. And it’s rarely revisited. Multiply that across cloud accounts, SaaS tools, Kubernetes clusters, and databases and you end up with dozens or even hundreds of identities that hold far more privilege than they need.

The problem isn’t just security. Admin sprawl amplifies operational fragility. A single mistake or a single malicious action can ripple far beyond its intended scope. We’ve seen this play out in cases like the fired contractor who reset thousands of employee passwords, or internal misconfigurations that caused major outages. In both types of incidents, the blast radius existed because privileges were broader than they needed to be.

If you can’t articulate why every admin in your environment truly needs that level of access, that’s a strong indicator that standing privileges have taken root, and a good moment to benchmark your exposure with the Standing Privilege Risk Checklist.

2. Long-Lived Keys and Credentials Are Still Everywhere

API keys, service account tokens, SSH keys, and automation secrets are some of the easiest paths into a cloud environment. They’re also some of the least governed. Many teams still keep:

• Credentials that never expire
  
• Keys embedded in pipelines or code
  
• Secrets used across multiple systems
  
• Tokens with full read/write access to production resources
  

These aren’t bad people making bad decisions. They’re busy teams trying to keep the lights on.

The problem is that long-lived credentials become high-value targets. Attackers increasingly test stolen cloud keys the moment they get them, as we saw in the AWS credential abuse cases involving TruffleHog and SES misuse. Whether the threat is external or internal, a persistent key with broad permissions is often the fastest route to sensitive resources.

If a service account can do more than its exact task—and keep doing it indefinitely—that’s an indicator of standing privilege risk.

3. Privileges Don’t Match What Identities Actually Use

Privilege sprawl is often a visibility problem. Teams don’t know what rights are being used, so they over-grant “just in case.” Over time, roles accumulate hundreds of permissions, most of which are never touched.

Common examples include:

• IAM roles with wildcard permissions
  
• CI/CD pipelines that can modify infrastructure far beyond their workload
  
• Databases where read/write permissions aren’t separated
  
• Kubernetes service accounts with full cluster-admin rights
  
• NHIs with cross-environment access because it was simpler than scoping
  

When permissions are broader than their real usage, the organization isn’t just exposed to attackers. It’s exposed to insider mistakes, misconfigurations, and accidental changes in sensitive systems. The Cloudflare outage is a well-known example of a change having far more impact than expected because of how permissions were structured.

If your team doesn’t regularly compare “granted” versus “used,” standing privileges are almost certainly accumulating.

4. Sensitive Actions Don’t Require Any Friction

Some operations should not be immediately available to any identity, no matter how trusted:

• Resetting large numbers of passwords
  
• Editing IAM policies
  
• Disabling security controls
  
• Modifying production data
  
• Spinning up new users or access keys
  
• Stopping backup or logging services
  

These actions should require either approvals, elevated Just-in-Time access, or automated guardrails that constrain when and how they can be performed.

In environments without friction, sensitive actions can be executed accidentally or misused maliciously. This is how attackers using valid RDP credentials can disable security tools instantly, or how insiders can execute destructive scripts without hitting any checkpoints.

If sensitive actions feel too easy, that’s an indicator that standing privileges are enabling more reach than intended.

5. You Can’t Easily Answer Who Has Access to What

Standing privileges thrive in environments where visibility is fragmented. Cloud, SaaS, identity providers, CI/CD, Kubernetes, and databases all have their own privilege models. Without unified visibility, organizations rely on:

• Spreadsheets for access reviews
  
• Outdated role definitions
  
• Tribal knowledge
  
• Manual investigations
  
• Multiple admin consoles
  

This fragmentation makes it nearly impossible to catch privilege drift or identify when service accounts, contractors, or AI agents have more access than expected.

And when an incident happens, delayed response often comes down to not knowing who had the ability to take a specific action. This is one of the biggest—and most overlooked—indicators that standing privileges have become ingrained.

How Zero Standing Privileges Addresses These Indicators

Zero Standing Privileges (ZSP) focuses on removing permanent access and replacing it with temporary, scoped, and auditable elevation. Under ZSP:

• Access is granted Just-in-Time
  
• Privileges match the specific task
  
• Access expires automatically
  
• Sensitive actions require deliberate elevation
  

ZSP reduces the opportunity for malicious insiders, limits the surface attackers can abuse with stolen credentials, and prevents accidental actions from impacting production systems.

It directly addresses all five indicators by keeping privilege surfaces small and access intentional.

How Apono Helps You Reduce Standing Privilege Risk

Apono makes Zero Standing Privileges practical across cloud, databases, SaaS, Kubernetes, and hybrid environments. It helps teams:

• Automate Just-in-Time elevation without slowing users down
  
• Quarantine risky privileges without breaking workflows
  
• Rightsize access based on real usage and risk data
  
• Remove standing access for human and non-human identities
  
• Log and audit all elevations and admin actions
  
• Detect unusual privilege behavior early
  

The goal isn’t to lock systems down. It’s to introduce the right guardrails so access becomes safer and more predictable.

Putting Better Guardrails Around Access

Standing privileges rarely feel dangerous until they’re misused. But the indicators show up long before the incident happens. If your environment has more admins than needed, long-lived keys, broad permissions, frictionless sensitive actions, or limited visibility, privilege sprawl is already creating risk.

If you want a fast way to understand where your gaps are, download the Zero Standing Privilege Risk Checklist — 

or reach out to see how Apono can help reduce privilege exposure without slowing your teams down.

New integration closes a long-standing Zero Trust gap by eliminating persistent permissions and enabling real-time, policy-driven access across cloud environments.

NEW YORK – January 6, 2026 – Apono today announced a new integration with Check Point Software Technologies that delivers an advanced SASE-based Zero Standing Privilege (ZSP) architecture designed to eliminate long-lived permissions and provide real-time access across modern cloud environments. This solution enables organizations to significantly reduce their attack surface while maintaining the agility required across engineering, distributed teams, and incident response operations.

Traditional SCIM-based identity synchronization can take 30–60 minutes, forcing organizations to rely on standing access to avoid operational delays. The new Apono–Check Point integration removes this dependency by enforcing temporary, event-driven access directly through Harmony SASE. Users receive only the permissions required for the specific task and time window, with access automatically revoked when the work is complete.

“Cloud environments are now operated not only by humans but by automated systems and AI-driven agents,” said Ofir Stein, Co-founder and CTO of Apono. “These systems react in milliseconds, and access must follow the same pace. Our integration with Check Point allows access to rise and fall dynamically alongside the infrastructure, ensuring real-time enforcement whether the actor is an engineer or an automated agent.”

Enterprises increasingly rely on SASE frameworks to secure distributed workforces. However, traditional provisioning approaches introduce friction and slow response times, particularly during high-urgency moments such as incident response.

The joint approach removes these bottlenecks by:

• Eliminating persistent permissions
• Replacing slow SCIM or identity provider syncs
• Enforcing temporary, real-time least-privilege access at the SASE enforcement layer

“Organizations are under increasing pressure to enforce Zero Trust without slowing down their teams,” said Amit Bareket, VP of Security Service Edge at Check Point Software. “With Harmony SASE, our collaboration with Apono extends Zero Trust from identity to Just-In-Time & Just-Enough network access enforcement in a single, cloud-delivered control plane. By unifying policy and real-time enforcement across users, devices, and apps, we eliminate unnecessary complexity and let teams stay productive without compromising security.” 

Key Capabilities

• Real-time identity provisioning: Instantly adds or removes users from Harmony SASE groups without waiting for SCIM or IdP cycles.
• Policy-driven Zero Standing Privilege (ZSP): All access is temporary, time-bound, and governed by policy. Permissions automatically expire when no longer needed.
• Context-aware access workflows: Access can be triggered by signals such as incident acknowledgement, change management events, or ITSM workflows.
• Access rightsizing enforcement: Automates detection of over-privileged users and adjusts permissions to ensure least-privilege access.

Apono and Check Point plan to further expand the integration with advanced automation capabilities, additional context triggers, and broader governance workflows. Both companies share a long-term vision for a unified, real-time Zero Trust architecture where access appears only when needed and disappears automatically.

“When we talk about deeper automation and richer context, we’re talking about an access model that can react on its own,” said Ben Avner, Head of Technology Partnerships at Apono. “Partnering with Check Point gives us the foundation to deliver an end-to-end, real-time system where privileges rise and fall automatically with the work itself.”

About Apono

Apono provides real-time, Just-in-Time, and Zero Standing Privilege access for cloud infrastructure, SaaS, and operational resources. By automating identity provisioning based on policy and operational context, Apono helps organizations enforce Zero Trust without slowing down engineering, operations, or incident response.

Contact Information:

Stephen Lowing
VP Marketing

[email protected]

apono.io 

Shai Hulud didn’t invent a new supply chain weakness. It took advantage of something most teams already struggle with: long-lived credentials sitting on developer laptops and CI runners. Once it landed in a workstation or pipeline, it went hunting for secrets, then moved into GitHub, npm, and cloud environments.

The damage is huge. More than 25,000 GitHub repositories showed signs of credential exposure tied to the operation, and hundreds of npm packages were altered and republished as “normal” updates. 

Teams that treated non-human identity (NHI) security as a secondary layer discovered that the worm viewed those identities as primary targets. NHIs had more rights and seldom expired. When credentials outlive their usefulness, the Shai Hulud npm worm is a perfect illustration of how quickly a local compromise turns into an ecosystem issue.

What is the Shai Hulud npm Worm?

Shai Hulud 2.0 spread through legitimate packages that contained malicious preinstall scripts. Those scripts ran before installation finished and inherited the environment in which they executed. The worm used this position to inspect local files, gather tokens, and transmit them externally. Equipped with the victim’s npm credentials, it automatically backdoored and republished other packages the maintainer controls.

The pattern wasn’t complicated, but it was frustratingly effective. It waited for a normal install, ran its preinstall script, and searched for credentials with real reach. Once it had one, it republished a backdoored version under the maintainer’s identity and propagated through standard npm channels. Everything looked routine because, operationally, it was.

The worm targeted a predictable set of secrets, including npm tokens, GitHub credentials (e.g., PATs/SSH creds), and cloud API credentials (AWS/GCP/Azure), plus CI environment secrets where available. These secrets already existed because they enabled faster local development and pipeline automation. Because these tokens were long-lived, the worm could reuse them across systems, moving from a single machine into source control, registries, and cloud environments. This is why secret management can’t be treated as a side project, as these tokens are the worm’s fuel. 

This combination of availability, scope, and longevity created the conditions for rapid propagation. The worm did not need to be sophisticated. It only needed access to credentials that could reach beyond the machine it first compromised.

Why the Shai Hulud Worm Is Malicious

Shai Hulud is dangerous because it moves through trusted identity relationships that were never designed to defend against compromise. It does not rely on a single exploit. It relies on normal development workflows and the credentials those workflows expose.

The worm embeds itself in preinstall scripts that run automatically during dependency installation. From there, it focuses on harvesting credentials rather than disrupting systems. Access is the objective. Tokens that can touch source control, publishing, and cloud are worth more than the laptop or runner they were stolen from. 

With the right token, an attacker can change code and reach production-like systems without ever needing to “own” the original machine. The Shai Hulud worm spread by acting like a normal maintainer. It reused real npm tokens to republish packages, so the poisoned versions looked legitimate, and they flowed downstream the same way any routine update would.

Several factors make this behavior particularly damaging:

• Preinstall scripts run by default during dependency installation, often before most security controls or CI guardrails can run.
• Stolen credentials enable unauthorized publishing and changes to repositories.
• NHIs often hold broad, persistent permissions.
• Each new installation exposes additional environments and secrets.

The main issue Shai Hulud exploits is a growing web of interconnected identities that link development systems, such as CI pipelines and cloud resources, together. This factor gives attackers clear paths across environments with little resistance. 

Impact of the Shai Hulud Worm

The operational impact of Shai Hulud extended across development, CI, and production environments. What began as a dependency issue quickly exposed structural weaknesses that exist in many engineering organizations, particularly around credential handling and trust in automation.

At the supply chain level, the worm modified hundreds of npm packages. Teams had to audit both transitive and direct dependencies, frequently without knowing which builds had pulled compromised versions. Integrity verification became sluggish and insufficient as a result. That scramble is exactly what effective supply chain risk management is meant to prevent: clear containment boundaries and fast credential rotation.

After credentials were stolen, the compromise became more serious. Attackers were able to alter repositories, publish unapproved package versions, and initiate continuous integration workflows under false identities. The risk extended beyond source control into cloud environments. Several areas felt the impact most acutely:

• Pipeline instability: Malicious scripts were introduced into build systems and altered execution paths, leading to compromised artifact generation, test behavior, and deployment reliability.
• Maintainer impersonation: Actual npm publishing keys were used to distribute modified packages, thereby undermining ecosystem trust and raising concerns over the accuracy of updates.
• NHI compromise: Service accounts and automation identities became the easiest pivot points. Their permissions were broad, their activity rarely scrutinized, and the worm moved through them without triggering the alerts teams rely on for user abuse.

Once the stolen secrets surfaced in public repositories, containment became significantly harder. Those credentials no longer had a defined boundary, which forced organizations to rapidly revoke, replace, and reassess every access path tied to the affected identities.

How to Know if You Are Affected by the Shai Hulud npm Worm

You can detect potential compromise by focusing on deviations in dependency structure, identity behavior, and repository activity. Look for:

• Packages that include unexpected preinstall scripts, such as setup_bun.js
• New versions of your packages were published without approval.
• Publishing activity by unknown identities or service accounts.
• Unapproved changes to GitHub workflows or repository settings appear without a corresponding change record.
• Sudden creation of GitHub tokens tied to users or automation that do not normally mint credentials.
• Cloud activity that originates from unfamiliar locations or involves sudden increases in privilege.
• CI jobs that run commands or scripts outside the planned sequence.
• Public GitHub repos referencing Shai Hulud that contain your secrets.
• Any shift in NHI patterns is unlikely to be benign because their behavior is normally consistent.

Most early signals appear in automation layers. NHIs do not deviate from routine unless something external influences them. Monitoring that layer provides the strongest detection point.

7 Ways to Protect Against the Shai Hulud Worm and Similar Attacks

Catching the next malicious script is not the goal of defending against Shai Hulud, as most of that is reactive. Removing the access conditions that allow a single compromised dependency to become a multi-system incident is the real work. Here’s how.

1. Remove Standing Credentials Through Just In Time Access

Shai Hulud was effective because the credentials it discovered were already valid and already powerful, some that were never meant to be permanent. That persistence gave the worm time to reuse them across repositories, registries, and cloud environments. 

Just-in-Time (JIT) access changes that dynamic. Using a cloud-native access management platform like Apono, you can apply this model consistently across both human users and non-human identities. The result is that access is available only for the duration of a task. 

2. Enforce Least Privilege Across Developers, Pipelines, and NHIs

Over-permissioning is rarely intentional. It is usually the result of pressure, such as a pipeline failure and blocked release. So someone broadens access to get things moving again, and the permission is never revisited. Over time, identities accumulate rights they no longer need.

When one of those identities is compromised, every attached permission becomes available to the attacker. Limiting privilege to a specific action, environment, and time window prevents that cascade. 

3. Secure CI and CD Systems by Removing Embedded Secrets

Because CI pipelines are situated between source code and production systems, they are appealing targets. That bridge is exactly why CI hardening is inseparable from cloud data security; pipeline credentials often have direct paths to production cloud resources. The pipeline configuration contains static secrets that make that access reusable and long-lasting. Once uncovered, those secrets are perpetually replayable. A more resilient approach removes secrets from pipelines entirely. 

4. Restrict and Monitor Publishing Rights

Package publishing rarely gets much attention once it is working. Tokens are created to keep releases moving and then left in place because changing them is more likely to cause trouble than praise. Over time, no one is quite sure who owns those credentials or how often they should be reviewed.

Shai Hulud exploited that drift. It reused valid maintainer credentials and pushed altered packages through standard release mechanisms. Nothing about the process looked unusual, which is why the updates traveled as far as they did before anyone noticed.

Constraining publishing access changes that outcome. Limiting who can publish, what they can publish, and how long that access exists reduces the window for abuse. 

5. Apply Zero Trust Controls Across Development Tooling

In many environments and for teams, Zero Trust initially applies, but not much beyond. Credentials are accepted once and then reused by developer tools without reassessing context, and access persists until it is explicitly revoked, even when the surrounding conditions no longer exist. This is the gap that Shai Hulud exploits, as stolen credentials remain usable even when the original context no longer exists.

In practice, that persistence shows up in a few predictable ways:

• Credentials remain valid across sessions. Access continues from different machines.
• Changes in device state go unnoticed.

Let’s look at a real-world example. Apono takes a different approach, where access is treated as a continuous decision rather than a one-time event. Each request is evaluated using the current identity attributes and the state of the requesting device. When those conditions no longer meet policy requirements, access is denied instead of preserved. 

Source

6. Track NHI Behavior Continuously

Non-human identities operate on schedules, repeating the same actions and creating useful predictability. When something goes wrong, the signal usually appears as a deviation rather than a spike in activity. That might look like:

• access to resources that the identity has never touched before
• activity outside its normal execution window
• permissions being exercised in a new context

Changes in behavior, scope, and timing are often the first indication that an automation identity has been compromised. Deviations from established patterns tend to surface upstream, before activity becomes overtly malicious, which is exactly where worms like Shai Hulud gain their footing.

7. Strengthen Developer Workstations

Developer machines remain a common entry point because access accumulates quietly over time as tokens get cached, among other bad habits, to reduce workflow friction. Tooling continues to assume a high level of trust long after the original context has changed.

Removing stored tokens, requiring hardware-backed authentication, and using secrets scanning tools to catch exposed tokens before they land in commits or logs. More importantly, local access should never grant durable privileges into production systems. When access is temporary and tightly scoped, a compromised workstation no longer serves as a gateway to the rest of the environment.

Why Containing Worms Requires Containing Privilege

When access outlives intent, compromise stops being local. The Shai Hulud infection was able to spread through repositories, pipelines, and cloud systems more quickly than most controls were designed to stop, thanks to those access paths.

Apono breaks the continuity attacks Shai Hulud relies on. Access is issued when needed, removed when it is no longer required, and never left standing by default across development, CI, and cloud systems. When credentials expire, and privilege is tied to intent, a compromised dependency stays local instead of rippling outward.

Supply chain attacks will continue. The organizations that hold up best are the ones that control privilege as aggressively as they control code. That starts with understanding where standing access still exists, how long it persists, and which access paths create unnecessary blast radius.

To help teams take that first step, we’ve put together a practical Zero Standing Privileges (ZSP) Checklist – a quick way to assess your current access posture and identify where privilege needs to be tightened before the next incident tests it.

Identity sprawl is exploding. What was once a manageable set of user accounts has rapidly evolved into a complex ecosystem, comprising human identities, service accounts, ephemeral workloads, APIs, and bots, each with its own permissions and potential blast radius.

Machine identities alone now outnumber humans by more than 80:1, creating an ever-expanding attack surface that most teams can’t fully see, let alone govern. 60% of these non-human identities (NHIs) are over-permissioned, turning everyday automation into a ticking time bomb for lateral movement and unauthorized access.

For DevOps and platform teams, the problem isn’t theoretical. You see it every day in the form of outdated service roles that never got cleaned up and bots that no one remembers creating, yet everyone still relies on. Identity governance tools help untangle that mess, providing teams with the visibility and automation they need to maintain secure access.

What are identity governance software solutions?

Identity governance software solutions provide control over who has access to what, and more importantly, why. They add an oversight layer (automated certifications, approval workflows, entitlement management, and privilege drift monitoring) that goes beyond traditional IAM, which manages only authentication and basic roles. IAM identifies users; IGA ensures the continued appropriateness of access.

Identity governance has become critical in cloud-native environments. The old model (static roles and the occasional access review) just can’t keep up with how quickly engineering teams move today. And when accounts in places like CI/CD pipelines start collecting permissions they no longer need, they quietly turn into long-term attack paths if no one is watching.

Identity and access governance is also a core pillar of Zero Trust. If Zero Trust means “never trust, always verify,” IGA is the function that enforces it at the identity layer. Instead of assuming a role is safe because it was approved months ago, modern governance continuously validates that every permission (human and NHIs) is still aligned with least privilege. 

The proliferation of NHIs holding long-lived, high-risk permissions that never get reviewed means teams rely on identity governance solutions to discover and right-size these entitlements. And because cloud identities now encompass everything from developers and contractors to service accounts and AI agents, ignoring NHIs is no longer an option.

Benefits of Identity Governance Software Solutions

• Reduced risk from excessive privileges: Identity governance solutions proactively detect and right-size over-permissioned accounts to Just Enough Privilege, including NHIs, to reduce lateral movement risk from compromised tokens and long-lived credentials.
• Strengthen compliance and audit readiness: IGA platforms automate access reviews and maintain clean audit logs for regulations and frameworks like SOC 2, HIPAA, GDPR, and CCPA. Instead of manual spreadsheets, you get automated evidence collection and continuous least-privilege enforcement.
• Increase operational efficiency through automation: Workflows, such as provisioning and approvals, are automated, eliminating the ticket load and role sprawl that slow down DevOps teams.
• Enforce scalable, context-aware access: Modern IGA tools apply policies based on identity type, environment, sensitivity, and risk signals for consistent least privilege across multi-cloud and ephemeral workloads.

Key Features of Identity Governance Software Solutions

• NHI visibility and governance: With machine identities far outpacing human users, a modern IGA must discover NHIs and map their access to prevent hidden entitlements. 
• Automated provisioning and deprovisioning: The best identity governance software solutions integrate with cloud providers and DevOps tools to ensure identities are created, updated, and removed in real time.
• Just-in-Time (JIT) and time-bound access: A core component of Zero Trust, JIT access enforces least privilege by granting permissions only when needed and automatically revoking them when the task is complete. 
• Comprehensive audit trails: IGA solutions provide audit trails for access requests, approvals, and entitlement changes, but not workload-level access logs.
• Seamless cloud and DevOps integrations: Modern stacks span dozens of SaaS apps. A great IGA solution must provide native connectors and APIs to enforce consistent policy across all environments.
• Context-aware access policies: Identity governance should adapt to conditions such as user role and behavioral risk signals, making context-aware policies necessary to enforce granular, dynamic access at scale.

10 Top Identity Governance Software Solutions

Some identity governance software solutions (like Apono) bridge multiple categories by combining traditional governance capabilities with automated, Just-In-Time access and dynamic policies that work across both human and non-human identities. Let’s take a look at the categories.

Category 1: Dynamic Access & Just-in-Time Governance

Tools in this category aim to eliminate always-on permissions by granting people (and systems) only the access they need, exactly when they need it. They’re especially useful for teams working in fast-moving cloud-native security environments where access needs shift constantly.

1. Apono

Apono isn’t a traditional IGA platform; it’s the modern evolution of identity governance built for cloud-native, DevOps-led organizations. Instead of relying on static roles or quarterly reviews, Apono brings Zero Trust to life by granting access only when it’s needed and revoking it immediately afterward. JIT and JEA usually sit in the JIT PAM world, but Apono folds those real-time controls directly into governance.

Designed for fast-moving engineering teams, Apono governs both human users and NHIs, ensuring every request is scoped, time-bound, and aligned with least privilege. Its unified, cloud-native policy plane centralizes access across infrastructure, SaaS apps, databases, CI/CD pipelines, and ephemeral workloads, and is delivered through self-serve Slack, Teams, or CLI workflows without ticketing delays.

Key Features 

• Auto-expiring permissions that eliminate standing access risks
• Self-serve, granular access requests via Slack, Teams, or CLI
• Break-glass and on-call flows for rapid incident remediation
• Centralized visibility, access discovery, and audit-ready reporting
  

Best For: Cloud-native organizations enforcing least privilege, securing NHIs, and automating JIT access.

Price: Contact Apono for customized pricing.

Review: “Quick and easy config to integrate access control with a myriad of service providers and data stores. For administrators, it’s relatively straightforward to define and implement access flows. For the requester, all they have to do is ask for it via Slack, and they get what they need within seconds. Apono keeps track of everything and reacts just in time to apply, restore, or revoke credentials and permissions.”

Category 2: Enterprise-Grade Identity Governance Platforms

Enterprise-grade IGA platforms provide the broad, centralized governance capabilities large organizations rely on to manage tens of thousands of identities. They’re well-suited for companies with established IAM programs and complex approval workflows.

2. Omada Identity

Omada is a comprehensive IGA platform focusing heavily on lifecycle management and policy-driven governance. It is known for its mature workflows and robust audit capabilities, and it integrates with complex IT and HR systems.  

Key Features 

• Role lifecycle management and policy-based access control
• Automated access certifications and entitlement reviews
• Segregation of Duties (SoD) policy modeling

Best For: Enterprises with complex IAM programs requiring Segregation of Duties (SoD) controls. 

Price: By inquiry. 

Review: “I like how easy it is to look up and change permissions for a user, and to designate auto-approve for certain things.”

3. Saviynt

Saviynt blends identity governance, privileged access management (PAM), and application access management into a single solution. Users choose it for SoD controls across enterprise apps like SAP and Salesforce.

Key Features

• Cloud-native architecture with strong SaaS integrations
• Risk-based access recommendations and remediation
• Automated provisioning with HR-driven workflows

Best For: Large enterprises requiring unified IGA and PAM. 

Price: By inquiry. 

Review: “The customer relations have been great, there is a great community, and the tool itself makes it easy to get a return on investment quickly.”

4. CyberArk Modern IGA

CyberArk’s Modern IGA extends the company’s suite of privileged access security into full identity governance. Built to complement PAM capabilities, it emphasizes lifecycle automation and certification workflows to reduce the impact of credential attacks.

Key Features

• Access certification workflows and entitlement cleanup
• Risk analytics to surface toxic combinations of access
• Native ties to CyberArk’s PAM platform for end-to-end privilege protection

Best For: Organizations already using CyberArk PAM. 

Price: By inquiry. 

Review: “I like the way we can securely connect to the servers and perform the activity without worrying about cyberattacks or security threats.”

Category 3: Cloud-Native Identity & Access Automation

Cloud-native identity and access automation tools eliminate the manual friction of managing entitlements across distributed, multi-cloud environments. They excel at automating provisioning and identifying privilege drift.

5. SecurEnds

SecurEnds is a cloud-native governance tool designed to streamline access reviews and entitlement cleanup. It’s especially helpful for teams buried in compliance tasks, giving them a clearer view of who has access to what across both SaaS apps and internal systems.

Key Features

• ML-driven entitlement discovery to detect privilege creep
• Risk scoring for accounts and entitlements
• Integrations with HRIS and major cloud/SaaS providers

Best For: Teams needing automated access reviews without deploying a heavyweight enterprise IGA suite.

Price: By inquiry. 

Review: “This tool provides a modular approach that can grow and mature along with the organization, ultimately providing automation options for access reviews.”

6. Veza

Veza is an authorization platform that unifies identity-to-data permissions across multi-cloud and SaaS environments. Veza’s graph-based model gives granular visibility ideal for cloud security and data governance teams.

Key Features

• Authorization graph modeling for identity-to-resource mapping
• Domain-specific governance for data stores and cloud IAM
• Alerts for privilege escalations or high-risk entitlements

Best For: Security and data governance teams requiring granular, identity-to-data permissions visibility.

Price: By inquiry. 

Review: “Veza Digital delivered items on time and achieved every milestone as planned. They listened to and addressed feedback in a detail-oriented manner.”

7. Elimity

Elimity provides entitlement intelligence and access cleanup insight, making it a strong fit for teams that want improved visibility without deploying a full-scale IGA suite.

Key Features

• Automated entitlement discovery and insights
• Identity risk scoring and privilege anomaly detection
• Integrations with major directory services and SaaS apps

Best For: Organizations seeking lightweight identity analytics and entitlement intelligence.

Price: By inquiry. 

Category 4: Policy-Orchestration & Cloud Privilege Platforms

Policy orchestration and cloud privilege tools are all about bringing order to multi-cloud chaos. They pull identity and access rules into one place, smoothing out the differences between platforms so teams can enforce least-privilege consistently across every cloud and application.

8. Strata Identity

Strata Identity’s “identity fabric” approach abstracts away platform-specific policy differences, enabling organizations to enforce consistent access rules without re-architecting infrastructure.

Key Features

• Policy orchestration across multiple IDPs (Okta, Azure AD, Ping, etc.)
• Real-time policy replication and drift prevention
• No-code migration of identity policies between platforms

Best For: Multi-IDP or multi-cloud environments that need to unify and orchestrate identity policies. 

Price: By inquiry. 

Review: “Strata helped us update the authentication experience and unify SSO without slowing down innovation.”

9. ZertID

ZertID focuses on cloud entitlement management and identity governance across AWS, Azure, and GCP. It’s used for unifying cloud IAM policies and making cloud permissions easier for security teams to visualize and control.

Key Features

• Permission graphing and entitlement visualization
• Anomaly detection for privilege changes or drift
• Automated cleanup recommendations for excessive permissions

Best For: Cloud-forward teams that need clear visualization and centralized control of AWS, Azure, and GCP IAM entitlements. 

Price: By inquiry. 

Review: “Zertid helped us to create workflows for integrating and cross-wiring things across the ServiceNow platform and our custom ServiceNow apps.”

10. Britive

Britive provides a cloud-native privileged access platform designed to automate ephemeral access across cloud and DevOps environments. Focused heavily on CI/CD pipelines and cloud service entitlements, Britive helps reduce standing privileges across cloud and SaaS systems.

Key Features

• Real-time discovery of cloud entitlements
• Context-aware access workflows and policy enforcement
• Integrations with GitHub, GitLab, Terraform, and more

Best For: DevOps and cloud security teams requiring ephemeral access to APIs.

Price: By inquiry. 

Review: “Solid product, great team behind it, easy to navigate portal, and comprehensive documentation regarding implementation.”

Reimagining Identity Governance for Modern Cloud Environments

Traditional IAM tools, which rely on static roles and manual approvals, can’t keep pace with cloud-native development or the scale of human and non-human identities that organizations manage.

Apono sits at the center of this evolution. By automating JIT access and enforcing least privilege across both human users and NHIs, Apono bridges the gap between identity governance and real-world DevOps workflows.

With auto-expiring access, centralized audit logs, and one-click self-serve requests via Slack, Teams, or CLI, engineering teams stay productive while security teams regain control and visibility.

If you’re ready to reduce identity-based risk and simplify compliance, now is the time to explore a modern approach to identity management. To dive deeper into how privileged access fits into this shift, check out our PAM Buyer Guide and book a quick meeting with our team to see how JIT access can work in your environment.

Secrets run your applications: API keys, SSH keys, tokens, passwords, database credentials. They reside in repositories, CI/CD pipelines, infrastructure-as-code templates, containers, and even chat logs; one stray commit is enough to expose a path into production.

In 2024, abuse of valid account credentials was the initial access vector in roughly 30% of incidents investigated. At the same time, machine identities now outnumber humans by more than 80 to 1, many of which are tied to long-lived secrets that are difficult to manage.

Secret scanning tools help you stay ahead of this by automatically searching code and configuration for exposed credentials across GitHub, GitLab, CI/CD pipelines, and cloud resources so you can revoke and rotate them before an attacker simply logs in.

What are secret scanning tools?

Secret scanning tools are automated security solutions that detect exposed credentials, such as API keys, tokens, passwords, and connection strings, before they can be abused, and provide the necessary information to remediate them quickly. They continuously analyze sources like code repositories, configuration files, IaC templates, container images, and logs to catch secrets that end up in places they shouldn’t. Hence, scanning complements your broader secrets management strategy.

Most tools integrate directly with GitHub and other version control and CI/CD systems. Some run as static scans against code and configuration at rest, while others operate dynamically in pipelines, runtimes, and cloud environments to catch drift and secrets that surface only at execution time.

Even the best scanners only detect exposed credentials; they can’t fix the root causes behind secret sprawl: standing privileges and unmanaged non-human identities (NHIs). Scanning can surface these leaks, but it cannot right-size permissions or prevent overprivileged service accounts from becoming high-value breach targets.

Pairing secret scanning with Just-in-Time (JIT) access and least-privilege policies ensures that even if a secret leaks, its underlying permissions are time-bound and far less dangerous. 

Types of Secret Scanning Tools

Secret scanning shows up at different layers of the delivery pipeline. In practice, most teams combine several types of tools to cover source code, build processes, and infra.

• Source code scanners run against repositories to detect secrets committed to the Git history or stored in branches and pull requests. They typically plug into GitHub, GitLab, or Azure Repos and surface findings directly within the developer workflow.
• CI/CD pipeline scanners run as part of build and deployment pipelines. They inspect artefacts, environment variables, and config files generated at build time.
• IaC and container scanners focus on infrastructure-as-code templates and container images, including configurations used in cloud or on-prem data center management environments.
• Runtime and cloud environment scanners look at live applications and cloud accounts. They detect secrets left in logs, storage buckets, or configuration stores that only appear after the system is live.

Benefits of Secret Scanning Tools

• Stronger security posture: Centralizes how you check secrets across code, pipelines, infrastructure, and cloud.
• Faster incident response: When a key leaks, you can quickly see where it “lives”, who uses it, and what to rotate.
• Better developer productivity: Checks in Git and CI/CD reduce security tickets and late rework by keeping feedback inside dev tools.
• Easier Compliance: Provides evidence that you monitor exposed credentials and enforce access-key policies, which simplifies SOC 2, ISO 27001, PCI and similar compliance regulations.
• Protection for non-human identities (NHIs): Reduces the chance that powerful service accounts and workloads are left with hard-coded, long-lived credentials. NHIs hold a high volume of operational privileges in most cloud environments, which is why teams increasingly rely on NHI management tools to understand and control how these identities use secrets.

Key Features to Look For in a Secret Scanning Tool

• Automated detection and remediation: Continuous scans in repos and pipelines that catch new secrets quickly and can open tickets or trigger revoke-and-rotate steps with your secrets manager, reducing the window in which exposed keys could be used in credential attacks.
• Context-aware, granular policies: Controls you can tune by repository, environment, secret type, and identity. This way, production or high-privilege secrets are handled differently from low-risk test data, following the principle of least privilege and time-bound access patterns.
• Seamless developer experience: Findings in pull requests or pre-commit hooks (with low noise and clear guidance) so teams adopt scanning without feeling blocked.
• Cloud-native, API-driven architecture: First-class support for multi-cloud, containers, and IaC, plus APIs and webhooks to feed results into internal platforms, chat, and automation.
• Centralized visibility and reporting: Dashboards and exports that highlight unresolved high-risk secrets and coverage gaps over time for security and GRC teams, a key requirement for root-cause analysis.

Top 7 Secret Scanner Tools

1. GitGuardian

GitGuardian is a dedicated secrets security platform that scans code repositories, CI/CD pipelines, infrastructure-as-code, and developer tools for hard-coded credentials and other sensitive tokens. It centralizes incidents and secret inventory across GitHub, GitLab, Bitbucket, Azure DevOps, and more, with policy controls and workflows for triage and remediation.

Best for: Perimeter-wide secrets detection.

Price: Free tier for up to 25 developers. Business and Enterprise plans for larger teams.

Review: “I like GitGuardian best for its real-time detection of secrets in both public and private repositories and its easy integration with developer tools…”

2. Apono

Apono is a cloud-native access management platform that eliminates the root causes of secret sprawl: standing privileges and unmanaged NHIs. Apono replaces standing privileges with JIT and Just Enough Privilege access to cloud and data resources for both human and machine identities. It connects to cloud platforms and identity providers to automate time-bound approvals and revoke-or-restore workflows, so credentials are only valid when needed.

Apono’s value becomes clear when combined with secret scanning: even if a credential leaks, its permissions are limited, temporary, and automatically revoked after use. Apono removes the need for long-lived IAM keys by brokering short-lived, scoped access through native cloud identity services.

Best for: Engineering teams that need automated, least-privilege access without slowing down developers or managing credentials manually.

Price: 30-day free trial with subscription pricing based on environments and usage.

Review: “Quick and easy config to integrate access control with a myriad of service providers and data stores.”

3. TruffleHog

TruffleHog is an open-source secrets scanning engine that digs through git history and other sources, such as local files, S3 buckets, Docker images, and logs, to find leaked credentials. It supports hundreds of secret types, utilizing both pattern- and entropy-based detection, and can validate many findings against provider APIs to reduce false positives.

Best for: Granular and extensive customization.

Price: Free and open source, with a paid enterprise edition available from Truffle Security.

Review: “Trufflehog offers a versatile solution for keeping your code’s secrets under wraps, available both as an open-source tool and as an enterprise solution.”

4. Yelp detect-secrets

Detect-secrets is Yelp’s open-source Python scanner that inspects a repository’s current state for high-entropy strings and known secret patterns, using a baseline file to manage existing findings. It’s lightweight enough for pre-commit hooks and CI/CD jobs, and extensible via plugins and custom rules when you need organization-specific detectors.

Best for: Low-overhead CLI scanning.

Price: Free and open source.

Review: “Detect-secrets by Yelp takes a minimalist approach to secret scanning, focusing on high accuracy and low operational overhead.”

5. Doppler

Doppler is a hosted secrets management platform that centralizes environment variables and API keys, then syncs them to apps, CI/CD pipelines, and cloud platforms as up-to-date configuration. It combines secret storage with basic scanning and auditing features, helping teams standardize how secrets are distributed and rotated while relying on dedicated scanners to find new leaks.

Best for: Managing a “source of truth” for secrets alongside separate secret scanning tools.

Price: Free Developer plan with paid plans with per-user pricing.

Review: “Doppler is one of those tools that I don’t want to imagine not having in my stack.”

6. Nightfall AI

Nightfall AI is an AI-native data loss prevention platform that also scans source code and git history for secrets via GitHub Actions, CI integrations, and DLP APIs. It detects credentials and API keys alongside PII/PHI in tools like GitHub, Slack, Google Drive, and other SaaS applications, allowing you to enforce consistent policies across repositories and cloud services.

Best for: Combining DLP and secret scanning across many apps and services.

Price: Free tier and paid volume-based pricing.

Review: “Nightfall is very easy and quick to rollout compared to a lot of other DLP products.”

7. AWS IAM Access Analyzer

AWS IAM Access Analyzer is a native AWS service that analyzes IAM and resource-based policies to identify public and unused access to your AWS resources. It also validates and generates fine-grained policies based on access activity, encouraging least-privilege permissions and reducing blast radius if secrets or credentials are abused.

Best for: AWS-centric secret scanning.

Price: Billed per resource, identity, or API call.

Review: “The fact that it enables me to precisely regulate user access is what I value most.” 

The Hidden Secrets of Secret Scanning

Secret scanning tools are now vital for teams shipping continuously. They provide visibility into exposed credentials across code, CI/CD pipelines, infrastructure, and cloud, allowing you to revoke and rotate them before an attacker gains access. 

On their own, though, scanners are reactive. They can tell you a secret has leaked, but not what it can do, or how long it should stay valid. Controlling attack blast radius requires access policies that default to no access and grant short-lived, least-privilege permissions based on context, such as user, role, resource, and variables like time of day or location. This is the missing half of the equation; detection without automated, zero-standing privilege access controls still leaves your organization exposed.

This is where an access platform like Apono fits into the picture. Apono automates just-in-time, just-enough access for both human and machine identities across your cloud and data stack, so most credentials are short-lived and tightly scoped. It removes the operational overhead of manually granting or revoking access and eliminates long-lived keys across pipelines, tools, and workloads.

If you’re working to reduce secret sprawl and eliminate long-lived credentials, explore our PAM Buyer Guide for a deeper breakdown. Alternatively, book a personalized Apono walkthrough to see how automated JIT access closes the gaps secret scanning tools can’t.

Pillar Security’s recent analysis of Docker’s Agentic AI assistant, Ask Gordon, offers an early glimpse into the security challenges organizations will face as AI systems begin operating inside the development stack. Their researchers discovered that a single poisoned line of Docker Hub metadata caused the agent to run privileged tool calls and quietly exfiltrate internal data.

The failure happened inside the decision-making layer where an AI agent consumes data and translates it into actions. That layer is quickly becoming one of the most critical surfaces security teams must defend.

The broader implication is clear. Organizations are pushing toward Agentic AI because of the enormous potential productivity gains. But autonomy, speed, and system reach create identity-like risks that many environments aren’t prepared to manage.

What Happened

The Ask Gordon AI Agent fetches Docker Hub metadata to help users understand container images. Pillar’s researchers inserted a malicious instruction into a repository description, and the agent:

• Accessed an attacker-controlled URL
  
• Executed internal tool calls (build logs, build lists)
  
• Packaged log data and chat history
  
• Sent the full payload externally without user approval
  

The agent simply interpreted untrusted data as instruction. Docker responded to this risk by requiring human approval for tool calls that touch sensitive data or external systems.

While this is an effective fix, the real challenge is bigger than a single feature bug.

The Growing Tension: Productivity vs Security in the Agentic Era

Agentic AI promises huge efficiency gains with the potential for:

• Reduced manual toil
  
• Faster development workflows
  
• Automation that scales far beyond human capacity
  

But these strengths introduce new risks:

• Agents act independently
  
• They ingest untrusted content at scale
  
• They infer intent and may take unintended actions
  
• They interact with internal and external systems
  
• They do all of this at machine speed
  

These are many of the same factors that we apply risk modeling to human users, but multiplied by automation, volume, and a lack of common sense.

Agentic AI: A New Identity Class With Unique Risk

Security teams historically manage two categories of identity:

Humans — Unpredictable, creative, fallible and sometimes malicious.

Non-human identities (NHIs) — Service accounts, tokens, cloud roles. Predictable but extremely numerous.

Agentic AI now becomes a third category altogether.

Agents combine characteristics of both:

• Human-like autonomy and decision-making
  
• Machine-like scale, speed, and integration depth
  

They access internal systems. They make decisions without human review. And they can be manipulated through crafted inputs. Traditional IAM models do not yet account for these traits.

The Ask Gordon incident is a concrete example of this shift and raises real questions about how organizations can reliably roll out AI tooling in the near term..

How Security Teams Should Approach Agentic AI

Because agents cannot reliably differentiate safe instructions from malicious ones, access boundaries carry the burden of defense. Three principles matter most.

1. Know what your agents can see and do

Teams must understand:

• What data agents can read
  
• Which systems they can modify
  
• What privileges they inherit from humans
  
• Where they overlap with sensitive environments
  

2. Apply Access Controls Based on Risk, Not Identity Type

As organizations adopt Agentic AI, the old model of treating access differently for humans and NHIs breaks down. Agents introduce autonomy and unpredictability at scale, so access must be governed by risk, not by the type of identity making the request.

A risk-based model asks only:

• What is the potential impact if this identity acts incorrectly?
  
• What level of oversight is appropriate for that impact?
  

This applies to everyone:

• Humans bring intent and unpredictability
  
• NHIs bring volume and persistence
  
• AI agents bring autonomy and speed
  

The goal is the same across all of them: define clear boundaries around sensitive actions and ensure identities operate within them.

3. Treat external communication as a privileged action

Ask Gordon succeeded because the agent could transmit data freely. Any system capable of making external requests should require consent, context, or both.

How Apono’s Access Engine Scales to Humans, NHIs, and Agentic AI

Apono’s access model is built around context and risk, which makes it naturally suited for managing Agentic AI alongside humans and NHIs.

A unified, scalable control plane

Apono evaluates every identity the same way:

• What are they trying to access?
  
• How sensitive is the resource?
  
• What context and justification support the request?
  

This creates a consistent, enforceable approach that scales as organizations introduce more automation.

Dynamic policies that prevent privilege drift

As identities take on new tasks or as resources grow in sensitivity, Apono automatically adapts access policies. This keeps permissions aligned with current context and prevents the slow buildup of unnecessary rights.

Ephemeral access removes standing privilege

Whenever access is approved, Apono generates a temporary, scoped role and deletes it when the task ends. This avoids:

• Long-lived permissions
  
• Static role sprawl
  
• Agents inheriting privileges they shouldn’t have
  

Continuous monitoring for accountability

Apono surfaces unusual or risky identity behavior, whether human, NHI, or AI agent. This gives security teams the confidence and auditability needed as autonomous systems become more integrated into daily operations.

Taking the Next Step Toward Smarter Access Controls

Whenever an AI agent is allowed to read internal data and perform actions on your behalf, it becomes part of your identity surface. 

Organizations will adopt Agentic AI rapidly because the productivity gains are too compelling to ignore. But autonomy without access boundaries creates real operational risk.

Zero Standing Privilege offers a workable foundation for securing humans, NHIs, and now Agentic AI. Apono operationalizes that model by making access contextual, temporary, and enforceable at scale.

To evaluate where standing privileges may already exist in your environment, download our Zero Standing Privilege Checklist.

To compare Cloud Privileged Access Management solutions designed for the Agentic era, explore our Privileged Access Buyer Guide + RFP Checklist breaks down the capabilities that matter most and the questions that separate cloud-native solutions from legacy ones.

What the recent AWS campaign reveals about credential misuse, persistence techniques, and the need for Zero Standing Privilege

Last week’s disclosure from AWS is another reminder that in the cloud, attackers don’t need to break in. They just need a working set of keys. 

Several AWS customers learned this the hard way when threat actors used compromised IAM credentials to deploy a rapid cryptomining campaign across EC2 and ECS environments. The incident didn’t rely on vulnerabilities or sophisticated exploitation. It relied on valid credentials and overly permissive access.

Below is a clear breakdown of what happened, what matters, and how organizations can strengthen their defenses using a Zero Standing Privilege (ZSP) approach.

What Happened

According to reporting from Dark Reading and AWS’s own analysis, attackers used stolen IAM credentials to authenticate into customer environments and immediately begin provisioning cryptomining workloads. The campaign was active across multiple AWS customers, who were directly notified.

Importantly, AWS confirmed this was not the result of a flaw in AWS infrastructure. Every action the attackers took was permitted by the privileges attached to the compromised identity.

Once inside, the attackers:

• Targeted EC2 and ECS resources to spin up mining infrastructure
  
• Used automation to deploy workloads within about 10 minutes of initial access
  
• Leveraged AWS APIs to create new roles, extending their control
  
• Enabled persistence by modifying instance attributes to make resources harder to terminate
  

This combination of legitimate access and rapid provisioning made the campaign both effective and difficult to stop in its early stages.

For full details, you can read the AWS security blog here: https://aws.amazon.com/blogs/security/cryptomining-campaign-targeting-amazon-ec2-and-amazon-ecs/ 

A Closer Look at How They Stayed in Control

After gaining access, the attackers created two new IAM roles using the victim’s own permissions to achieve their goals and persistence:

1. A service-linked role for Auto Scaling groups
   
2. A Lambda execution role, with AWSLambdaBasicExecutionRole attached
   

These roles gave them flexibility to deploy and manage resources in ways that blended into normal cloud operations.

They also set DisableApiTermination=true on EC2 instances, which forces defenders to manually re-enable termination before cleanup. This slows incident responders and disrupts automated remediation workflows.

On top of that, the attackers attempted to launch as many EC2 instances and ECS tasks as each victim’s quota allowed. It’s a simple technique: push the environment to its compute limits, maximize mining output, and generate profit before alarms start ringing.

What Security Teams Should Check Right Now

AWS published several indicators of compromise tied to this campaign. Teams should search across logs, CloudTrail, GuardDuty findings, and container registries for the following:

Suspicious container image

• yenik65958/secret (now removed, but variants may exist)
  

Mining pool domains

• asia.rplant.xyz
  
• eu.rplant.xyz
  
• na.rplant.xyz
  

Unusual instance naming patterns

• SPOT-us-east-1-G*-*
  
• OD-us-east-1-G*-*
  

IAM activity

• Unexpected CreateRole or CreateServiceLinkedRole events
  
• ModifyInstanceAttribute calls setting DisableApiTermination to true
  

If any of these appear in your logs, treat it as a high-priority investigation.

Compromised Credentials Are Still the Easiest Way In

This attack chain is not surprising to anyone working in cloud security. In many environments:

• IAM permissions are broad
  
• Long-lived access keys still exist
  
• Role creation is not guarded
  
• There is no friction between authentication and high-impact actions
  

When a compromised identity can create new roles, deploy compute resources, and modify protection settings without additional checks, attackers don’t need zero-days. They just need opportunity.

This is exactly the kind of scenario where a Zero Standing Privileges strategy provides real value.

Why Zero Standing Privileges Matter

Zero Standing Privileges (ZSP) reduces the risk of credential misuse by ensuring that no identity keeps permanent access to sensitive or high-impact permissions. Instead:

• Access is Just-in-Time
  
• Privileges are scoped to the exact task
  
• Access expires automatically
  
• Sensitive roles require additional validation or approval
  

If the credentials in this incident had been tied to temporary, tightly scoped permissions — instead of broad, standing access to create roles and launch resources — the attackers’ options would have been dramatically limited.

How Apono Helps Implement ZSP in AWS

ZSP is a powerful strategy, but difficult to enforce manually. Apono automates the operational layer, making least privilege practical for real engineering teams.

Here’s how Apono would have helped in a situation like this:

Risk-tiered Access Flows

Apono allows organizations to define access policies that match the sensitivity of each system:

• Low-risk resources — Baseline access or long-term auto-approved JIT access for authenticated users
  
• Medium-risk resources — Short-term JIT access with clear time limits and MFA
  
• High-risk environments (production, regulated data, IAM changes) — Require manager or admin approval before ephemeral, time-bound access is granted
  

This means a compromised user cannot silently elevate themselves, create roles, or deploy infrastructure without triggering controls.

Breakglass with Context

For urgent incidents, engineers can request temporary elevation tied to an IRM like PagerDuty, Splunk OnCall, Opsgenie, Grafana IRM, or other service incident ticket, ensuring access is fast but still governed and auditable.

Dynamic, Ephemeral Role Creation

Instead of relying on static IAM roles, which age poorly and are always available for abuse. Apono creates scoped roles on the fly when access is approved.

This accomplishes two important outcomes:

• Attackers cannot rely on pre-existing roles to escalate
  
• Admin teams no longer need to pre-build and maintain dozens of role variations
  

Continuous Monitoring and Anomaly Detection

Apono would have flagged activity such as:

• High-risk access requests, approvals of previously rejected requests, and sudden requests from inactive users

• Repetitive or suspicious automated actions, ensuring that automation doesn’t become a security vulnerability

And before the attack even happened, Apono’s privilege discovery and remediation would have identified:

• Overprivileged IAM accounts
  
• Role-creation permissions assigned to users who shouldn’t have them or don’t need them based on business logic context
  

All of this reduces the blast radius of compromised credentials and limits how much damage attackers can do before they’re stopped.

Taking the Next Step Toward Smarter Access Controls

The AWS incident is a reminder of a simple truth: identity is the primary attack surface in cloud environments. Compromised credentials, combined with broad standing privileges, give attackers everything they need to operate inside your infrastructure.

A Zero Standing Privilege approach minimizes this risk by ensuring access is temporary, scoped, and closely governed. Apono provides the automation needed to make that practical in real-world environments.

Get the Checklist

you want to quickly assess where standing privileges may already exist in your environment, start with our Zero Standing Privilege Checklist — a simple way to benchmark your current exposure. 

And when you’re ready to compare Cloud PAM approaches that operationalize ZSP, our Privileged Access Buyer Guide + RFP Checklist breaks down the capabilities that matter most and the questions that separate cloud-native solutions from legacy ones.

Manual access requests and long-lived credentials pose a significant scaling challenge for engineering teams, even as they automate pipelines, testing, delivery, and monitoring. As the volume of machine identities grows, the sheer volume of permissions makes manual review and revocation unmanageable, increasing risks of stale tokens and silent privilege exposure.

Nearly 47% of cloud intrusions stem from weak or mismanaged credentials, according to a Google Cloud report. Identity is still a major attack path rather than a solved discipline. Manual access management is unworkable at scale, but automated access control systems support fast workflows and safer access.

The automated access control platforms below help teams grant access automatically and maintain least privilege at scale. They support multi-cloud, SaaS, and modern CI/CD workflows, reflecting the future of identity security.

What are automated access control systems?

Automated access control systems use policy context and workflow automation to grant and revoke permissions without tickets, manual reviews, or long-lived credentials. Access opens only when it’s needed, remains active for the duration of a specific task, and then closes automatically, eliminating the risk of forgotten or persistent privileges. 

Automated access control systems reduce reliance on static, role-based access with short-lived, purpose-based permissions that align with least privilege and Zero Trust principles. Every access decision is logged and evaluated against contextual signals such as user role, device posture, location, risk score, and, in advanced systems, workload behavior. 

Non-human identities (NHIs), aka the service accounts, API keys, bots, CI/CD jobs, and cloud workloads running behind the scenes, now outnumber human users by an estimated 80:1. They move faster than any engineer and often carry the highest levels of privilege. The problem is that many NHIs still rely on long-lived IAM keys or broad, static roles. When that happens, they quietly turn into one of the largest and least-watched attack surfaces in the entire cloud environment.

With automated access control systems, you can manage NHIs issuing short-lived, scoped permissions for each pipeline run or automation task, and revoke them cleanly as soon as work completes. This heightened risk is why teams increasingly rely on NHI management tools to right-size permissions and eliminate long-lived credentials.

Teams simply cannot track that level of entitlement sprawl or enforce credential rotation manually. Automated access control systems close that gap and consistently enforce least privilege. Modern platforms also integrate directly into CI/CD pipelines, issuing ephemeral credentials to remove long-lived secrets and reduce overall threat exposure.

Benefits of Automated Access Control Systems

• Replaces long-lived and risky access with short-duration, Just-in-Time permissions, strengthening your overall privileged access management strategy.
• Improves delivery speed by letting users request and receive access through familiar channels such as Slack, Teams, or CLI, without waiting in a queue.
• Produces automatic and timestamped audit records suitable for SOC 2, HIPAA, GDPR, and CCPA evidence reviews, giving security teams built-in compliance support.
• Reduces approval wait time and lowers the risk of misconfigured privileges by automating routing, access activation, expiration, and full teardown.

• Maintains consistent least-privilege enforcement across multi-cloud and hybrid environments through API-driven integrations.
• Controls non-human identities (NHIs) by issuing short-lived, scoped permissions, reducing one of the largest hidden attack surfaces in cloud environments. 

Key Features to Look For in an Automated Access Control System

• Policy-driven access rules that adjust permissions based on identity, role, task, and context instead of fixed, long-term entitlements.
• Granular visibility and control across human and machine identities, cloud platforms, and sensitive services, with clear mapping of what each identity can reach.
• Native integration with cloud providers, identity platforms, collaboration tools, and CI/CD pipelines to align permissions with real activity and deployment flows.
• Self-service request and approval flows that let users obtain access quickly through approved channels without bypassing governance.

• Full audit and reporting coverage that records every access event, approval, and expiration with searchable logs for security and compliance teams.
• Break-glass and on-call escalation flows providing temporary emergency access with full audit trails and automatic expiration.

Top 10 Automated Access Control Systems

CATEGORY 1: Cloud-Native Access Automation

These solutions are purpose-built for fast-moving DevOps and SaaS teams that need automated Just-in-Time access and least privilege enforcement across multi-cloud environments.

1. Teleport

Teleport issues short-lived, identity-backed certificates for servers, Kubernetes clusters, databases, and internal applications. It removes static keys, records administrator sessions, and surfaces real-time activity to give teams a clear audit trail and tighter oversight of production access.

Best For: Teams that want certificate-based, Zero Trust access (with no standing credentials) across multiple clouds. 

Price: Offers usage-based pricing for enterprises, and a free Community Edition is available.

Review: “I like that Teleport provides secure, certificate-based access to servers, databases, and Kubernetes clusters without needing a VPN.”

2. Apono

Apono automates Just-in-Time access across cloud infrastructure, SaaS tools, and data systems with policy-driven controls for both human and machine identities. Access is time-limited by default and revoked automatically. Engineers can request access from Slack, Teams, or CLI while Apono handles validation and approvals in the background. 

Apono also eliminates privilege sprawl by continuously discovering over-privileged identities and automating remediation. Real-world teams are already doing this at scale. Organizations like Caris Life Sciences use Apono to replace broad, persistent database access with time-bound, auditable permissions aligned with Just Enough Privileges.

After adopting Apono, Caris reduced standing access across sensitive systems and accelerated on-call response by giving engineers fast, temporary access exactly when needed, without compromising compliance or security.

Best For: Organizations looking to automate the entire Just-in-Time access workflow, from request through revocation, with no manual steps.

Price: A 30-day free trial is available for JIT database access.

Review: “Most integration configurations are straightforward and backed up by informative yet simple documentation. In more complicated cases, Apono’s team were happy to help and solved issues fast and with high professionalism.”

3. Zitadel

Zitadel offers a modern approach to authentication, supporting OIDC, passwordless login, and both RBAC and ABAC. Developers get clean APIs and SDKs they can plug straight into their applications, which means they don’t have to own identity storage or user lifecycle management themselves.

Best For: Teams that want solid authentication and fine-grained authorization built into their services. 

Price: A free tier is available, and paid plans are billed based on monthly active users.

Review: “I was relieved to discover ZITADEL, allowing us to leverage their expertise so we can focus on the rest of our platform development.”

CATEGORY 2: Developer-First Access & Authorization Tools

These tools support teams that want to control permissions at the application and service layers using code-driven policy logic, rather than relying on broad platform-level entitlements.

4. Cerbos 

Cerbos is a lightweight policy engine that lets teams pull authorization rules out of their application code. At runtime, Cerbos evaluates those policies through an API, giving every service consistent access decisions, even for automated workflows collecting data at scale or interacting with internal systems.

Best For: Teams that want to externalize authorization logic without adopting a full IAM suite.

Price: Free open-source core plus paid Hub tiers (starting at $25/month) for managed policy tooling and scalable production deployment.

Review: “The best thing about Cerbos is how easily I can tweak access control logic without having to even touch the codebase.”

5. ConductorOne

ConductorOne orchestrates SCIM-based provisioning, deprovisioning, and access reviews alongside existing IdPs. Its strong point is lifecycle management, with HR-triggered onboarding and offboarding plus one-click access to recertifications.

Best For: Organizations that want identity governance that keeps pace with cloud tooling, frequent onboarding changes, and rapid permission updates.

Price: Custom pricing.

Review: “The real strength behind ConductorOne is the ability to leverage its workflows against, at first glance, many disparate SaaS systems, which may not have cohesive workflows out of the box.”

CATEGORY 3: Enterprise IAM Platforms

This category serves organizations that manage large numbers of users and systems, requiring structured identity provisioning, governance workflows, and compliance-ready controls.

6. One Identity Manager 

One Identity Manager links HR and directory data with enterprise apps to automate provisioning, enforce modeled roles, and run scheduled attestation cycles. It is well-suited for complex, regulated organizations that need full governance coverage across many identity sources.

Best For: Organizations operating under strict regulatory or audit requirements that need structured provisioning, role governance, and attestation cycles.

Price: Enterprise pricing is available upon request. 

Review: “We saw a significant boost in IT staff productivity after adopting the One Identity platform.”

7. Ping Identity 

Ping Identity delivers a broad range of enterprise IAM services, including SSO and policy-based access control tailored to hybrid and multi-cloud deployments. It integrates seamlessly with legacy infrastructure while offering modern authentication flows, such as passwordless login and adaptive risk evaluation.

Best For: Organizations modernizing hybrid IAM without overhauling legacy systems.

Price: Starts at $35,000 annually for Essential and $50,000 for Plus, with pricing adjusted by scope and features.

Review: “This use of open standards and overall stability makes it an excellent platform to base user authentication upon.”

8. Okta Workforce Identity Cloud 

Okta Workforce Identity Cloud combines MFA and automated lifecycle workflows with a deep catalog of prebuilt connectors. This gives teams turnkey provisioning and offboarding coverage across thousands of SaaS and enterprise applications.

Best For: Companies standardizing workforce identity across SaaS and hybrid cloud.

Price: Tiered pricing, with core authentication in lower plans and lifecycle, device, and API security features in advanced plans.

Review: “It provides a secure, centralized way to manage user access across multiple applications, which saves time and reduces risk.“

CATEGORY 4: Data-Centric & Authorization Intelligence Platforms

These platforms focus on deep data-layer visibility and contextual authorization, making them ideal for organizations tackling entitlement sprawl and enforcing least-privilege access at scale.

9. Twilio Verify / Identity 

While not a full access control platform, Twilio Identity supports access workflows by validating user identity and risk signals before permissions are granted. It delivers API-based verification, including phone, document, and risk-based checks, so applications can validate users in real time.

Best For: Apps needing flexible, API-first user verification workflows.

Price: Pricing is usage-based per verification, with volume pricing available for higher throughput workloads.

Review: “I was looking for a communication API for my new product when I came across Twilio. It’s super easy and fast to implement, paired with a good customer support team.”

10. Veza

Veza builds an Access Graph across cloud, SaaS, and data systems to reveal effective permissions and hidden entitlements. It helps teams spot unused or over-privileged access and recommends least-privilege adjustments grounded in real data-layer visibility.

Best For: Organizations tackling complex entitlement sprawl across data and SaaS ecosystems.

Price: Custom pricing.

Review: “Veza gives us both broader and deeper visibility into who has access to our data, and how they have access to that data, so we can trust and verify that personnel only have the access they need.”

Why Temporary, Contextual Access is the New Standard

Identity security is moving fast, and the direction is clear: access needs to be temporary, contextual, and fully auditable. The shift toward automated, policy-driven controls IS how engineering teams keep pace with multi-cloud complexity and the explosion of human and non-human identities.

Apono’s approach aligns directly with the trends outlined above by automating Just-in-Time access and enforcing least privilege for both human and machine identities. Auto-expiring permissions, break-glass and on-call workflows, and full access discovery make Zero Trust practical, and it’s all deployable in under 15 minutes. 
If you’re ready to see how automated access actually works in a real environment, get a personalized walkthrough today.

It’s not hard for secrets to sprawl, buried under layers of commits and forgotten branches. Most teams don’t notice it until one bad push exposes everything. Secret leaks don’t come from breaches, but from configuration drift and forgotten credentials; a gap that traditional vault tools struggle to close on their own.

Here’s the scale of that mess. Machine identities now outnumber human users by more than 80 to 1, and each one relies on credentials to function. Yet, only 15% of organizations feel highly confident in preventing NHI attacks, while 69% express concerns about them.

Keeping thousands of invisible credentials under control without slowing your team down begins with improved secrets management and a shift in how you secure non-human identities.

What is secrets management, and how does it relate to NHI security?

Secrets management involves storing, issuing, rotating, and controlling access to credentials such as API keys and tokens. It keeps machine-to-machine credentials out of code and ensures that every secret has a clear owner, scope, and expiration date.

Secrets management and NHI security are closely linked because every non-human identity (whether it’s a CI/CD pipeline or automated workflow) relies on credentials to function. Those credentials often end up hardcoded or overprivileged. NHIs often authenticate through short-lived credentials issued via OIDC or IAM role assumption rather than static API keys, minimizing the credential footprint. Secrets management solves that by turning static keys into short-lived, controlled secrets that expire automatically.

Without secrets management or effective NHI management tools, NHIs become a blind spot. All it takes is one leaked token to give an attacker broad access. With automated secrets management in place, you can enforce least privilege and rotate credentials automatically, removing long-lived tokens before they become a silent liability.

Zero Trust demands you verify every request and validate each secret, enforcing cloud security controls across all NHI workflows. Applying these controls to NHIs ensures machine-to-machine communication stays compliant with SOC 2, ISO 27001, NIST, and broader application security standards.

Why Secrets Management is the Weak Link in NHI Security 

Every bot, API, or AI-powered workflow needs credentials to connect systems, deploy builds, and pull data. Each non-human identity opens a new attack path. In most organizations, no one knows exactly how many exist or what they still access. API keys and tokens often carry more privilege than the humans managing them. Left unchecked, they multiply across scripts, containers, and pipelines, creating NHI sprawl.

As CI/CD pipelines spin up new workloads, they leave behind forgotten service accounts and unrotated secrets. These orphaned credentials expand your attack surface until a single unused token becomes an admin key to production. 

5 Secrets Management Mistakes to Avoid

1. Hard-Coded Secrets in Code Repositories

Leaving API keys or credentials inside your code is one of the simplest ways to reveal private information. Anybody with access, or even a public scan, can locate those lines once they are pushed to version control. A single exposed key can spread instantly across mirrors and forks before you even realize it. Attackers regularly scan public repos for exposed credentials, and even a brief exposure can result in a full system compromise.

2. Shared Service Accounts

To “keep things simple,” many teams use the same account for several services or pipelines. As a result, there is no accountability. It is impossible to determine which process or individual used a shared key. As a result, incident response is slow and unreliable, and audits (including any privileged access management audit) are unreliable. 

3. Long-Lived Tokens and Passwords

Static credentials that never expire are a major liability. The longer a secret stays valid, the more likely it is to leak, be reused, or be forgotten. Long-lived tokens often have broad permissions, which can turn into open doors for privilege escalation. Automated rotation and expiry policies close that window by ensuring credentials live only as long as needed.

4. Manual Rotation and Ticket-Based Workflows

Everything is slowed down, and human error is introduced when engineers are relied upon to manually rotate secrets or submit tickets for access. In reality, a lot of credentials are never rotated because the procedure is cumbersome or disruptive. Automating rotation and approvals enables teams to stay focused while maintaining consistent security controls.

5. Lack of Visibility and Auditing

Without centralized visibility, it’s impossible to know how many secrets exist, who has access, or when they were last used. That lack of visibility slows down audits and provides attackers with room to move undetected. With continuous monitoring and solid audit logs in place, you can identify suspicious use early and shut it down before it escalates into a larger problem.

A Step-by-Step Guide to Secure Secrets Management for NHIs

Step 1 – Discover and Classify All Secrets

Start by identifying every credential in your environment for human and non-human. Many teams find more machine credentials than expected once they run a proper discovery scan. Classify each secret by environment and purpose to keep control from day one.

Implementation Best Practices

• Map service accounts, workloads, CI/CD tokens, and API keys.
• Group them by sensitivity (production, staging, dev) and function.
• Automate discovery to catch orphaned credentials left behind by old systems.
• Revoke or rotate anything without a clear owner or current use.
• Identify unused, stale, or orphaned secrets left behind by old systems.
• Flag credentials that have no active owner or purpose.
• Document every secret’s source, usage pattern, and access path.

Automated NHI security tools can identify hidden tokens and accounts with permissions that should have expired but remain active.

Step 2 – Centralize Secrets in a Secure Vault

Leaks are inevitable when credentials are stored across code repositories, scripts, and cloud variables. You can maintain uniform visibility and access controls with a central vault.

Implementation Best Practices

• Enforce least privilege from the start.
• Separate environments to contain damage if a secret is compromised.
• Apply strong encryption and require MFA or identity-based access for retrieval.
• Schedule regular audits to see who’s accessing what.
• Remove hard-coded secrets from repositories, scripts, and config files.
• Replace environment-file secrets with vault-issued credentials.
• Require vault retrieval as part of your CI/CD and deployment workflows.

A vault is only effective if usage is mandatory, so make it part of your standard deployment process.

Step 3 – Automate Secret Rotation and Expiry

Manual rotation doesn’t scale. Credentials should never stay valid indefinitely, and teams shouldn’t depend on ticketing systems to manage them.

Implementation Best Practices

• Rotate secrets automatically after a set interval or trigger (like a deployment).
• Link rotation to events in your CI/CD pipeline.
• Implement time-bound access so credentials expire after use.
• Use just-in-time (JIT) provisioning to generate secrets only when needed.
• Replace static credentials with time-bound or ephemeral tokens.
• Set automatic expiry for all machine-issued secrets.
• Remove ticket-based rotation workflows and make rotation part of CI/CD automation.

This best practice reduces dwell time for attackers and ensures compromised credentials have limited value.

Step 4 – Apply Just Enough Privilege (JEP) Controls

Granting broad access ‘just in case’ is the fastest way to lose control, which is why adopting just enough privilege controls is essential.

Implementation Best Practices

• Define context-aware rules (who, what, when, for how long).
• Limit privileges to a single pipeline, namespace, or function.
• Set automatic expiry on all access requests.
• Integrate with collaboration tools like Slack or Teams for quick approvals.
• Replace shared service accounts with workload-specific identities.
• Issue scoped keys tied to a single service, pipeline, or namespace.

Combining JEP with automation produces cleaner audit trails and aligns easily with compliance frameworks, such as SOC 2 or ISO 27001.

Step 5 – Monitor, Audit, and Continuously Improve

Secrets management isn’t “set and forget.” Continuous monitoring keeps privilege creep in check and exposes potential misuse early, which is a core component of any continuous threat exposure management approach.

Implementation Best Practices

• Monitor for unused, expired, or overprivileged credentials.
• Feed secret access logs into your SIEM for cross-system visibility.
• Run quarterly reviews to spot drift between policy and practice.
• Treat every access request as untrusted until verified.
• Surface unused, dormant, or overprivileged credentials for review.
• Track secret access patterns to detect drift or unexpected usage.
• Alert on secrets that haven’t been rotated within policy thresholds.

When done well, this process becomes part of your Zero Trust framework by verifying every secret, every request, and keeping both human and machine identities accountable.

Bringing Automation and Trust Back to Access

Bots, pipelines, and workloads now outnumber human users many times over, and each depends on secrets to function. Without visibility and automation, those credentials quietly become the weakest link in your cloud security.

Instead of static credentials that linger for months, Apono delivers short-lived, scoped access that expires automatically when needed. Every request is verified, every permission is temporary, and every action, from approval to expiry, is logged for full visibility. It integrates natively into your workflow, whether you’re in Slack, Teams, or a CI/CD pipeline, and deploys in minutes, not days.

With Apono, least privilege is enforced automatically. Security and speed move together, so developers can ship fast while auditors sleep easy.See how your organization stacks up. Get an NHI Access Assessment and uncover where machine identities are over-privileged, and how automated, time-bound access reduces the risk.

We’re excited to announce Apono integration with 1Password to help organizations control, automate, and audit access to sensitive credentials and secrets bringing stronger security and smoother operations to teams everywhere.

This new integration enables customers to enforce Zero Standing Privileges (ZSP) and provision Just-in-Time (JIT) and just-enough access (JEA) to secrets stored in 1Password Enterprise Password Manager through Apono’s automated access flows. The result: security teams gain confidence, engineering teams move faster, and sensitive data stays protected.

A Shared Vision for Secure Access

In today’s complex environments, credentials and secrets are the keys to every system, cloud environment, and service. Yet managing who can access them  and when can be one of the biggest operational and security challenges for modern organizations.

Apono and 1Password share a common mission: to simplify secure access without slowing teams down. By combining 1Password’s trusted enterprise password management with Apono’s dynamic, policy-driven access control, organizations can now adopt a Zero Standing Privileges model while maintaining the speed their teams need to innovate.

Key Benefits

Together, Apono and 1Password give organizations greater control, visibility, and automation around access to credentials and secrets.

Provision Just-in-Time (JIT) Access

Automatically grant policy-driven, granular Just-in-Time access to 1Password credentials, secrets, and sensitive information ensuring that users get access only when they need it and for as long as they need it.

Enforce Least Privilege

Reduce standing privileges and enforce least-privilege access across all secrets managed in 1Password. Apono continuously right-sizes permissions, improving your overall security posture.

Eliminate Manual Friction

Streamline operations by automating access flows in line with your organization’s business policies and needs. Give R&D and engineering teams secure, compliant access faster without the manual approvals and delays.

Track, Audit, and Detect Anomalies

Gain complete visibility and auditability into every access request. With integrated tracking and anomaly detection, security teams can easily answer who accessed what, when, and why.

How It Works

The integration between Apono and 1Password enforces Zero Standing Privileges (ZSP) by granting access dynamically and revoking it automatically when it’s no longer needed.

Access requests are handled through policy-driven workflows in Apono, ensuring all approvals align with organizational policies and compliance requirements.

Using real-time, identity-aware provisioning, teams can adopt Just-in-Time (JIT) and Just-Enough Access (JEA) models for secrets management in 1Password – keeping credentials secure while maintaining business agility.

Why It Matters

This integration represents a major step forward for organizations adopting Zero Trust principles and modern access governance.
 By integrating Apono’s automated access controls with 1Password’s enterprise-grade secrets management, teams can:

• Eliminate manual credential sharing.
  
• Reduce security risk from secrets standing privileges.
  
• Automate access provisioning and revocation.
  
• Gain centralized visibility into every access decision.
  

Get Started

The integration between Apono and 1Password is available now.
Contact our team for a demo. and see how your team can start implementing Zero Standing Privileges (ZSP) to 1Password secrets  today.