Anthropic’s new Claude Code Auto Mode Auto Mode is generating well-deserved attention. It introduces a classifier that sits between the developer and every tool call, reviewing each action for potentially destructive behavior before it executes.

It’s a real improvement over the only previous alternative to manual approval: the –dangerously-skip-permissions flag.

But the announcement is also useful for a broader reason. It puts a clear spotlight on the question that every organization deploying AI agents needs to answer: how do you give agents enough access to be genuinely productive without creating the kind of privilege risk that compounds over time?

Co-pilots Are Already Over-Privileged

Most conversations about agent security focus on a future where fully autonomous agents are making high-stakes decisions. That future is coming, but the privilege gap is already open today.

GitHub Copilot, Cursor, Claude Code, and other co-pilots run with the same credentials as the developer using them. If that developer has broad access to production infrastructure, databases, or cloud resources, so does the agent.

There’s typically no scoping to the task at hand, no independent audit trail, and no automatic revocation when the work is finished.

Our 2026 State of Agentic AI Risk Report found that 98% of 250 senior cybersecurity leaders said security concerns have already slowed deployments, added scrutiny, or reduced the scope of agentic AI initiatives.

That’s not fear of AI itself. That’s a rational response to the fact that existing access models weren’t designed for tools that operate autonomously, at machine speed, with inherited human credentials.

The Kiro incident at AWS last December illustrated this vividly. An AI coding agent inherited an engineer’s elevated permissions, decided autonomously to delete and rebuild a production environment, and caused a 13-hour outage.

Amazon framed it as a misconfigured access control issue, which is precisely the point. Privilege management is the issue, regardless of whether the actor is human or machine.

Why Runtime Evaluation Matters

What makes auto mode architecturally interesting is that it moves permission decisions from configuration time to runtime.

Instead of trying to predict which permissions an agent will need before a task begins, the classifier evaluates each action in the moment with whatever context is available. This is the right direction.

Static permission models force organizations into an impossible tradeoff: grant broad access and accept the risk, or lock things down and accept the lost productivity. Runtime evaluation is what breaks that tradeoff, and Anthropic deserves credit for embedding it directly into Claude Code.

From Actions to Intent

Where the approach has room to grow is in what it evaluates.

Auto mode looks at whether an action is potentially destructive. That catches the obvious cases like mass file deletion or data exfiltration. But risk isn’t always visible at the action level.

Consider an agent that creates a new IAM user, opens a network path, or modifies a security group. None of those look destructive in isolation. All of them can be devastating in the wrong context.

Understanding whether an action is risky requires understanding why the agent is taking it, what environment it’s operating in, and whether the action aligns with the task at hand.

This is the case for evaluating intent, not just actions. When privilege decisions are informed by the agent’s stated purpose, the sensitivity of the target resource, and real-time behavioral context, you can make much more graduated decisions:

• Routine work flows without friction.
• Sensitive operations get human oversight.
• Genuinely dangerous actions get blocked.

That graduated approach is what unlocks real productivity from agents, because it lets them handle more of the work safely instead of being walled off from anything that carries risk.

How We Approach This at Apono

We built Agent Privilege Guard around the principle that intent should drive every privilege decision an agent makes.

When an agent requests access, our Intent Analyzer evaluates the request against multiple layers of context: the agent’s stated purpose, the sensitivity of the target environment, user and asset context, and behavioral patterns. Based on that assessment, the system makes a graduated decision:

• Low-risk actions proceed automatically, keeping agents productive on routine work without developer interruption.
• Sensitive operations escalate to a human via Slack or Teams, so a real person makes the call on high-stakes actions before they execute.
• Credentials are ephemeral, created at the moment of the request, scoped to exactly what the task requires, and destroyed on completion.

Every action is logged end to end with stated intent, the approval decision, credential lifetime, and access granted or denied. When auditors ask questions, the evidence is already there.

This works across Claude Code, GitHub Copilot, Cursor, and other agent platforms from day one, with no rework of existing policies. That cross-platform coverage matters because the privilege challenge doesn’t stop at any single vendor’s boundary, and security teams need a consistent posture regardless of which tools their engineers are using.

Where the Industry Is Headed

Anthropic’s auto mode reflects a shift that the entire industry needs to make: from static, pre-configured permissions to dynamic, context-aware access decisions made at runtime.

We believe intent-based guardrails are the natural next step in that evolution. They let organizations deploy agents with more freedom, not less, while maintaining the control and auditability that security and compliance teams require.

The companies that move fastest on AI adoption will be the ones whose privilege models are smart enough to keep up.

Start Applying Intent-Based Access to Your AI Agents

See how Apono secures AI agent privileges across Copilot, Claude, and more, without slowing engineers down. Explore Apono’s Agent Privilege Guard today.

In the current AI boom, we race to use copilots, orchestration scripts, CI workflows, retrieval pipelines, and background jobs. Sometimes, we take for granted that every one of these things needs an identity. Service accounts. OAuth apps. API keys. Short-lived tokens. 

As AI velocity increases, so does the number of these non-human identities (NHIs). Instead of obsessing over model quality, latency, hallucinations, and GPU costs, we also need to consider how these identities impact security. Every agent you spin up carries credentials, and every credential carries permissions. 

Multiply that across environments, pipelines, and integrations, and AI poses a big identity sprawl problem. Then, you get the hidden cost of AI velocity: identity sprawl that security teams can’t realistically govern with tickets and quarterly reviews. 

What NHI Sprawl Actually Looks Like in 2026

To understand NHI sprawl today, it’s worth pausing for a moment to think about what this sprawl looked like just before the AI era. 

Five years ago, non-human identities were already quite abundant. But the patterns were predictable:

• Build pipelines had dedicated CI/CD service accounts.
• Kubernetes controllers spun up service accounts namespace by namespace.
• Cloud automation tooling used long-lived IAM roles mapped to deployment pipelines.
• SaaS APIs were integrated via app-specific API keys stored in secret managers.
• Backup jobs and ETL processes had static credentials managed by platform teams.

That was sprawl, but it was manageable sprawl. There were usually clear owners (platform, DevOps), predictable lifetimes, and manual reviews tied to release cycles or audits.

AI changed the rate and diversity of identity creation. The pattern many companies now face is:

• Every AI agent/platform needs API access to internal services, CRM, observability, messaging, etc.
• Every automation pipeline spun up to support those agents needs tokens, often embedded in CI/CD workflows.
• Every orchestration layer generates its own principals to schedule, coordinate, and execute jobs.
• Every multi-stage job expands credential usage across environments.
• Every “agent chain” creates implicit privilege inheritance across systems.

What used to be a handful of long-lived service accounts becomes hundreds or thousands of specialized machine identities scattered across your stack. And the scale is no longer hypothetical: machine identities outnumber human identities by 80:1 in enterprise environments. 

When AI Velocity Meets Identity Governance 

Before the AI wave, identity growth in most environments was relatively linear. New services were introduced deliberately. IAM roles were defined around stable workloads. Service accounts were usually tied to long-lived systems. Even if sprawl existed, it evolved at a pace humans could periodically review.

Governance could at least attempt to map identities to systems and owners.But AI velocity collides with typical governance efforts built around inventories, tickets, and periodic certifications.

That’s why this collision creates real cybersecurity risk:

• Privilege drift accelerates. Permissions expand faster than they’re reviewed.
• Blast radius increases. Machine identities often span systems humans never touch directly.
• Detection becomes harder. Machine-to-machine traffic looks normal by default.
• Abuse scales instantly. API-level access means no console login is required.

Why Security Can’t Keep Up

Security can’t keep up because identity governance is still designed around reviewable objects, while AI turns identity into a byproduct of automation. Identities aren’t “created and reviewed.” They’re generated continuously by pipelines and runtime systems.

And yet the control plane hasn’t evolved. Security teams often still:

• Review role assignments after deployment
• Approve access via tickets
• Run periodic certifications
• Maintain static RBAC models that assume stability

The other structural problem is visibility. Modern AI stacks rely heavily on short-lived tokens issued via OIDC or STS. Credentials churn rapidly, but privilege is still defined at the role, service account, or OAuth-scope layer, and that layer persists. 

Security tooling frequently shows what roles exist, but not whether they’re being exercised appropriately, by which workload, for which task, right now.

Compliance doesn’t fix this. You can document least privilege and prove access reviews happened. But if identity creation is embedded in CI/CD and runtime federation, then governance evidence will always lag behind the actual access picture. Many organizations formalize identity oversight within a broader cybersecurity risk management plan, but documentation alone doesn’t address runtime privilege drift in AI-heavy environments.

Zero Trust Paired With Non-Human Identity Controls

In practice, most organizations interpret zero trust as stronger authentication for humans, tighter network segmentation, and conditional access policies. That model assumes people are the primary actors inside systems. Those are important, but they still tend to be human-first. 

In AI-heavy environments, the point is that humans aren’t the dominant actors anymore. If identity is the new perimeter, then non-human identities are now the dominant traffic crossing it. Zero trust without explicit NHI governance leaves your highest-volume lane under-controlled. 

Just as product development lifecycles require structured governance from ideation through release, identity lifecycles demand the same rigor, from creation to privilege assignment to revocation. 

1. From Identity Management to Real-Time Identity Orchestration

Traditional identity management focuses on provisioning and deprovisioning. A user is assigned a role; a service account is granted permissions. The system trusts that assignment until someone revisits it.

That model assumes identities are relatively static. AI systems don’t operate in static environments. They federate across clouds and SaaS platforms. They redeploy frequently, and they rely on ephemeral workloads that request credentials dynamically.

So the control model must shift from managing identities as objects to governing access as runtime decisions. Real-time identity orchestration means:

• Evaluating machine access continuously, not just at creation.
• Governing both human and non-human identities under the same enforcement framework
• Treating identity decisions as runtime events rather than admin tasks.
• Instead of asking, “What does this role have?” the system asks, “Should this identity perform this action right now, in this environment, for this task?”

2. Credential Half-Life Is Collapsing

On paper, this sounds like it should lead to improved lower risk. After all, short-lived credentials reduce exposure windows. But while credentials expire quickly, privilege scopes often remain broad and persistent.

The role still exists, the service account still holds cross-system permissions, and the OAuth integration still has sweeping API scopes.

This creates a new threat profile where:

• Short-lived tokens can still be replayed within their validity window. 
• Over-permissioned roles are exercised continuously.
• Bot-driven API abuse happens at machine speed.
• Attackers don’t need long-lived keys if they can repeatedly obtain short-lived tokens via a compromised workload, OIDC misconfig, or stolen CI identity.

Credential half-life is shrinking, but authorization half-life often isn’t; that asymmetry demands runtime controls. 

3. Dynamic, API-Level Enforcement

Traditional security controls often sit at the network layer: proxies, gateways, firewalls. But most AI-driven interactions happen via APIs.

Dynamic, API-level enforcement means:

• Evaluating identity context at the moment of the call.
• Inspecting action types.
• Applying policy based on workload type, environment, and requested operation.

Rather than just verifying the token is valid, you verify the action is justified.

4. Auto-Expiring Access as the Default State

Standing privileges are handy, but they’re also dangerous. In AI-heavy systems, persistent permissions become invisible infrastructure. Service accounts retain write access long after the original need has faded. OAuth tokens sit embedded in integrations that no one revisits.

Auto-expiring access should be the default for NHIs. If an AI agent needs temporary cross-system access to perform a task, that access should be time-bound and self-revoking.

5. Contextual, Task-Scoped Permissions

An AI enrichment agent may need to read from one dataset, update specific records, and call a defined API endpoint. It rarely needs unrestricted write access across environments.

Contextual, task-scoped permissions limit identities to:

• Specific datasets.
• Specific API methods.
• Specific environments.
• Specific time windows.

Instead of granting “database write,” you grant “write access to this table during this job execution.” Granularity is the difference between “least privilege” on paper and least privilege in practice.

6. Agent-Specific Guardrails

Not all machine identities are equal.

A reporting agent shouldn’t share the same privilege boundary as a deployment pipeline. An inference endpoint shouldn’t hold infrastructure modification rights. You get the point. 

Agent-specific guardrails formalize those boundaries. They codify what that class of NHI is allowed to do, and what it is explicitly forbidden from doing. Also, these guardrails enable continuous adversarial exposure validation by ensuring that AI-driven workflows cannot exceed their intended blast radius. 

In AI ecosystems where agents chain together, this becomes critical. Without guardrails, privilege inheritance spreads invisibly across workflows. Guardrails enforce architectural intent.

7. Human Authorization for Disruptive Actions

Even in the AI-dominated world we find ourselves moving towards, certain operations should never be fully automated without oversight. Think:

• Deleting datasets.
• Modifying production infrastructure.
• Granting additional privileges.
• Rotating encryption keys.
• Accessing high-sensitivity data stores.

Human-in-the-loop controls for disruptive actions create deliberate checkpoints where machine speed must slow down.

Gaining Back NHI Control at Machine Speed

Static roles, quarterly reviews, and spreadsheet-based IAM were never designed for machine-dominated environments. When AI agents can create, modify, and move data in seconds, access governance has to operate at the same cadence.

As long as service accounts, CI tokens, and AI agents retain persistent write access by default, governance will always lag reality. You can’t manage NHIs at machine speed if access decisions were made months ago and never revisited. If you want to understand where your exposure really sits, start with standing access.
Autonomous agents are moving into production environments faster than security teams can assess the risk. Learn more about how to manage your agents’ access using our Agent Privilege Guard, and book a demo here.

AI agents are no longer a future problem. They’re already inside enterprise environments, handling deployments, processing payroll, managing access, and they carry enormous privileges that make them dangerous to trick.

Apono2Pwn is a Capture the Flag designed to show you exactly what that looks like in practice.

What is Apono2Pwn?

A simulated company powered entirely by autonomous AI agents. No employees, just agents with real roles: HR, DevOps, Finance. They run on a live AWS infrastructure, make decisions, handle tasks, and interact with each other.

Your mission: social-engineer them into doing things they shouldn’t.

Join the game on Discord, interact directly with the agents in their channels, and capture flags by manipulating them into crossing lines they’re supposed to hold. Every successful attack earns points. The challenges range from beginner-friendly to deeply technical. If you can convince a chatbot to do something it shouldn’t, you’re already halfway there.

Why We Built This

The attack vectors in this CTF are the same ones showing up in real enterprise environments right now.

Agents are highly privileged. AI agents are typically granted far-reaching access to do their jobs. That access doesn’t go away when someone hands them a malicious instruction. The privileges are always standing, always available to be abused.

They’re easy to trick. Agents trust their inputs. A well-crafted prompt can manipulate their behavior, bypass guardrails, and get them to act against their own constraints, the same way social engineering works on humans, but faster and at scale.

Agents can hallucinate their way into harm. Agents don’t always know what they don’t know. They can confidently take actions based on false premises, misinterpret instructions in ways that cause real damage, or be led to believe a harmful request is legitimate.

Privilege escalation is real. Compromise one agent and you can pivot through its tool access to reach systems far beyond its intended scope. Standing privileges across a connected agent network create a blast radius most teams haven’t mapped.

Attacks look like normal operations. There’s no obvious alarm when an agent is manipulated. Without proper runtime controls, you won’t know it happened until it’s too late.

These aren’t theoretical. They’re the same risks we’ve spent years helping enterprises eliminate for human identities, and they’re now showing up at machine speed, at scale, in agentic systems.

You can learn more about the risks facing your agents at our Agent Privilege Lab where we break down how frameworks from OWASP, MITRE, and others see the risks. There’s also a simulator that lets you play with guardrail configurations and generate reports to better understand your risk posture.

This is more than just fun and games. It’s a preview of what comes next.

Every flag captured in this CTF represents a real attack vector that enterprises deploying agents need to defend against. To learn about how Apono’s Agent Privilege Guard addresses these risks at runtime, visit our agentic security product page.

How to Play

1. Go to apono2pwn.io and sign up
2. Join the Discord server
3. Start interacting with the agents in their channels
4. Capture flags, earn points, climb the leaderboard

The CTF is live and ongoing. There’s no end date, and new challenges will be added over time.

Play now

NEW YORK – March 18, 2026 – Apono, the agentic-forward cloud-native Privileged Access Management platform, today announced the launch of Agent Privilege Guard, a new product that gives enterprises the ability to deploy AI agents at full velocity without creating security risks they cannot control. Built around Apono’s Intent-Based Access Controls (IBAC), Agent Privilege Guard ensures that sensitive privileges are never available to be abused at runtime, regardless of what an agent is instructed to do.

Intent-Based Access Controls: The Guardrails for the Agentic Era

Co-pilots like GitHub Copilot, Cursor, and Claude Code are already active inside enterprise environments, typically inheriting the full permissions of the developers using them. Autonomous agents are not far behind. Both create the same critical exposure: standing privileges with no runtime mechanism to govern how they are used, leaving enterprises unable to deploy at speed without accepting risk they cannot see or control.

Agent Privilege Guard closes that gap. Apono’s Intent-Based Access Controls evaluate every privilege request at the moment it is made, automatically approving low-risk actions, routing sensitive operations to a human for approval in Slack before they execute, and blocking anything that exceeds policy before it runs. All credentials are ephemeral, scoped to the task, and revoked on completion. Every environment returns to Zero Standing Privileges after each operation.

Most enterprises are already in the early stages of their agentic journey, deploying co-pilots to accelerate engineering productivity. Agent Privilege Guard enables security teams to say yes to that deployment today, and to scale that confidence as organizations move toward fully autonomous agents over time, applying consistent runtime privilege controls across every identity.

“Enterprises have already decided to deploy AI agents. The question is whether security can keep up. Agent Privilege Guard answers that directly. Intent-Based Access Controls give agents the freedom to move fast on everything they should be doing, with the guardrails to ensure sensitive privileges are never available to be abused at runtime.”

— Rom Carmel, Co-founder and CEO, Apono

“The security team’s job isn’t to be the brake pedal on agent adoption — it’s to be what makes full-speed deployment possible. Intent-Based Access Controls give enterprises exactly that: the ability to deploy agents at full velocity, with the confidence that sensitive privileges are governed every step of the way.”

— Ofir Stein, Co-founder and CTO, Apono

Learn More

Apono will be showcasing Agent Privilege Guard at RSA Conference 2026 in San Francisco, booth 5170, North Expo. To learn more visit apono.io/agent-privilege-guard/.

About Apono

Apono is the agentic-forward cloud-native Privileged Access Management platform, purpose-built for enterprises deploying AI at scale. Founded by cybersecurity and DevOps veterans, Apono eliminates standing privileges and enforces Just-in-Time, Just-Enough access across every identity, from human engineers to co-pilot agents and autonomous AI systems, using Intent-Based Access Controls that operate at runtime. Trusted by global Fortune 500 companies including Intel, Hewlett Packard Enterprise, and Monday.com, Apono enables enterprises to deploy agents at full velocity without compromising security. Learn more at apono.io.

Contact Information

Nathan Kofman
[email protected]
+972 0508269578

In most organizations, identity governance and administration (IGA) solutions are supposed to answer one simple question: who has access to what, when, and why? But in cloud-native teams shipping daily, that question gets messy fast. Permissions sprawl and temporary access quietly become permanent. 

The blast radius is colossal. Third-party involvement in breaches doubled to 30% over the last year, which is exactly what happens when access decisions are scattered across vendors, apps, and infrastructure.

IGA still matters for compliance frameworks like SOC 2 and GDPR. Auditors expect provable least privilege and evidence you can actually trust. While many legacy identity governance and administration tools were built for slower environments, modern teams need governance that keeps up in real time. Automated, time-bound access that supports developer velocity is the way to go. 

What are identity governance and administration solutions?

Identity governance and administration (IGA) solutions are platforms that define and enforce who should have access to systems and data across an organization.

IGA helps security and IT teams understand who has access, what they can do, why they have it, and whether that access is still appropriate. Nowadays, these insights extend beyond human users to service accounts and other non-human identities (NHIs).

IGA has two connected pillars:

• Identity administration: Provisioning and deprovisioning access as people join, change roles, or leave, plus managing entitlement across cloud and data systems. 
• Identity governance: Enforcing policy, such as least privilege and access reviews, and producing audit evidence that stands up to frameworks like CCPA. 

The challenge is that many organizations treat governance as a periodic checkbox exercise, through initiatives like quarterly reviews. In cloud-native environments, access changes daily, and privileged permissions can spread fast. 

That’s why modern IGA is shifting from review-and-report to continuous enforcement. Automation and time-bound access are keeping governance aligned with how DevOps teams actually work.

Types of Identity Governance and Administration Solutions

Identity governance and administration solutions aren’t one-size-fits-all. Some platforms are built for HR-driven identity lifecycle and compliance reporting, while others focus on controlling privileged access in cloud environments. Different approaches to IGA can also change how well you reduce exposure to cyber attacks.  

Legacy IGA Platforms

These are the classic enterprise IGA suites designed around centralized directories and on-prem apps. They typically excel at onboarding and offboarding workflows and role modeling. The tradeoff is that they often rely on static roles and periodic reviews, which can lag behind how cloud permissions and DevOps environments actually change day to day.

Role-Based and Policy-Driven IGA

This category emphasizes enforcing access through RBAC (role-based access control) and policy-based rules like segregation of duties (SoD) and approval requirements. This approach works well in structured environments, but it can struggle when teams need highly granular, short-lived access to dynamic resources. 

Cloud-Native and DevOps-First Governance

Cloud-native IGA solutions are designed for modern stacks, including Kubernetes, data platforms, CI/CD tooling, and SaaS apps, where permissions change constantly. Instead of treating governance as a quarterly “review,” these tools lean into continuous controls such as:

• Just-in-time (JIT) access
• Time-bound permissions
• Context-aware approvals
• Automated revocation

This is the direction most high-velocity engineering organizations are moving because it reduces standing privilege without turning access into a ticketing bottleneck. That shift matters because static access creates continuous threat exposure in fast-changing environments and permissions drift. 

Access Review and Compliance-Focused Tools

Some IGA solutions skew heavily toward audit readiness, including access reviews and evidence collection for SOC 2 and similar requirements. They can be effective for proving governance, but may not provide strong real-time enforcement. 

Benefits of Identity Governance and Administration Solutions

• Reduce identity-based security risk: IGA limits over-privileged access and helps prevent insider misuse and credential compromise from turning into full-blown incidents, strengthening your overall cloud data security posture.
• Enforce least-privilege access at scale: It gives you a consistent way to grant access, with permissions that actually match what someone needs for a specific role and environment. 
• Improve visibility into who has access to what: Instead of guessing who has access to what, you get a current, reliable view of entitlements, so you can spot access sprawl. 
• Support compliance and audit readiness: Strong identity controls are foundational to enforcing your broader data governance policy, ensuring only authorized users can access regulated or sensitive data.
• Standardize access processes and reduce friction: Clear, repeatable workflows mean fewer one-off exceptions and fewer tickets bouncing between teams.
• Improve operational efficiency: Automated provisioning and deprovisioning reduce manual work and help prevent orphaned access when someone changes roles or leaves.

Key Features to Look For in an Identity Governance and Administration Solution

• JIT and time-bound access controls: Make sure the tool can grant access only when it’s actually needed, expire it automatically, and still support urgent break-glass workflows. 
• Automated provisioning and deprovisioning: Access should be provisioned when someone joins and revoked immediately when they leave. Bonus points if the tool can handle contractors and service accounts cleanly, not just full-time employees.
• Granular, least-privilege permissions: You want the ability to scope access tightly (by resource or environment) so people don’t end up with broad permissions just to get the job done. 
• Self-service access requests: Look for workflows that let engineers request what they need without opening tickets, while still enforcing policy and applying access automatically. 
• Context-aware approval workflows: Approvals should route intelligently based on what’s happening, from on-call status to ticket references. 
• Comprehensive audit logs and compliance reporting: You need clean, defensible logs that show who accessed what, when, for how long, and why, plus reports you can export and map directly to audit requirements.

10 Top Identity Governance and Administration Solutions 

1. Apono

Most legacy IGA platforms were built around static roles. That model breaks down in cloud-native environments where access changes daily and privileged permissions spread silently across infrastructure, CI/CD, data stores, and third-party tools.

Apono is a cloud-native access management and governance platform built for modern infrastructure teams that need real-time control. Instead of relying on static roles and periodic access reviews, Apono enforces JIT, time-bound permissions across cloud infrastructure, apps, and data, so teams can reduce standing privilege without slowing developers down.

Main features:

• Automated JIT access with auto-expiring permissions to eliminate standing privileges. 
• Auto-expiring permissions to ensure access never outlives its purpose.
• Self-serve access requests with built-in approvals via Slack, Teams, or CLI. 
• Granular, least-privilege scoping to eliminate standing privileges. 
• Pre-configured break-glass and on-call flows for fast incident response. 
• Comprehensive audit trails showing who accessed what, when, for how long, and why. 

Pricing: Contact the Apono team for tailored pricing. 

Best for: Cloud-native SaaS organizations and regulated enterprises that need to enforce least privilege continuously across infrastructure, production systems, and non-human identities, without slowing developers down.

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. The product supports many services and has an intuitive UI, both on the administrative and user sides.”

2. SailPoint Identity Security Cloud

SailPoint’s Identity Security Cloud is built to help large organizations govern access across complex, hybrid environments. It uses automation and analytics designed to reduce risk while keeping access processes consistent at scale. 

Main features:

• Identity lifecycle governance across users and applications.
• Automation and intelligence to drive access decisions. 
• Compliance-oriented controls that support audit readiness. 

Pricing: By inquiry. 

Best for: A mature IGA platform with broad coverage. 

Review: “SailPoint modernizes our identity management, enabling us to onboard 60 applications easily and automate HRMS tasks.”

3. One Identity Manager

Built for organizations that need structured lifecycle management and policy-driven controls, One Identity Manager is useful where identity processes are tightly tied to business workflows and compliance requirements. 

Main features:

• Governance workflows for access requests and approvals. 
• Attestation and recertification support to help meet audit and compliance expectations. 
• Identity lifecycle management to provision and deprovision access. 

Pricing: By inquiry. 

Best for: Enterprises with hybrid identity estates, i.e., a mix of legacy apps, cloud, and privileged accounts. 

Review: “The initial deployment of the solution and basic level configuration required to make the system run are fairly easy as compared with other solutions.”

4. Open IAM

OpenIAM is a converged identity platform that includes IGA capabilities like SSO and MFA. It’s a popular option for teams that want governance controls while also retaining the flexibility of an open-source model. 

Main features:

• Automated access reviews and least privilege enforcement. 
• Deployment flexibility and extensive documentation for integrations. 
• Subscription support tiers for the enterprise edition. 

Pricing: The Community Edition is free to deploy, and the Enterprise requires an annual subscription. 

Best for: An IGA platform with open source roots and deployment flexibility. 

Review: “Simplified single-click provisioning and de-provisioning of users, along with great security controls and logging of who is accessing what resources.”

5. Omada Identity

Omada’s offering focuses on unifying lifecycle management, access requests, access certifications, and reporting in a single governance framework. It’s often evaluated by enterprises that want structured identity processes with strong compliance support, 

Main features:

• Intelligent compliance dashboards with remediation actions. 
• HR-triggered provisioning and deprovisioning across connected systems. 
• Detection and prevention of conflicting access rights. 

Pricing: By inquiry. 

Best for: Formal IAM and IGA programs that need structured governance across hybrid IT. 

Review: “I love the clean interface, simplicity of features and controls, and how quick it is to edit user permissions.”

6. EmpowerID

EmpowerID combines identity lifecycle management and privileged access controls in a single suite. It’s designed for enterprises that want centralized identity orchestration across on-prem, cloud, and hybrid environments, with strong workflow automation. 

Main features:

• Scheduled and ad-hoc attestation campaigns with reviewer tracking. 
• Centralized reporting dashboards showing access assignments and approval history. 
• Event-driven lifecycle automation triggered by HR systems. 

Pricing: By inquiry. 

Best for: Unified identity platform combining IGA and workflow automation. 

Review: “It’s a cool platform for identity management for different accounts, policies, and access compliance.”

7. Netwrix

Netwrix is best known for governing and auditing access in hybrid environments, especially around directories and entitlements. For IGA, the core offering is Netwrix Identity Manager, with complementary governance coverage via Netwrix GroupID for group governance. 

Main features:

• AI-assisted role modeling and centralized identity repository. 
• Access Reviews workflow (via Netwrix Auditor integration). 
• RBAC for lifecycle-driven provisioning and deprovisioning. 

Pricing: By inquiry. 

Best for: Organizations with hybrid identity and data estates. 

Review: “[The] features are extensive, related to most of the use cases [for] group management. No other tool offers such [a] capability in [the] market. [The] product is flexible.”

8. WALLIX

WALLIX is primarily a Privileged Access Management (PAM) vendor (rather than a classic HR-driven IGA suite). In an IGA program, it’s most useful for governing privileged access, especially for third parties accessing critical IT and OT systems. 

Main features:

• Privileged session brokering and monitoring
• Vendor and remove privileged access (VPN-less portal options). 
• Credential controls, including vaulting and rotation patterns. 

Pricing: By inquiry.

Best for: Weak session oversight and strong monitoring and evidence. 

Review: “Flexible and easy to configure monitoring of privileged access. Too [many] accounts to configure during the process of bastion installation.”

9. Ping Identity

Ping Identity is an enterprise IAM platform that spans Single Sign On (SSO) and multi-factor authentication (MFA). For IGA use cases, Ping’s strength is combining access requests and governance workflows, useful if you’re standardizing identity across the workforce or customer-facing apps. 

Main features:

• PingOne Authorize for centralized, policy-driven authorization. 
• Access requests with configurable request types. 
• PingOne Identity Governance to centrally manage identities and access to resources. 

Pricing: By inquiry. 

Best for: A single identity platform for SSO and MFA. 

Review: “This is a cloud-based identity and access management that provides a secure and scalable solution for managing user identities and access in our internal tools.”

10. Microsoft Entra ID

Microsoft Entra ID is an identity layer for SSO and conditional access. When you add Entra ID Governance, it becomes a practical IGA option for organizations that want access packages and lifecycle workflows in the same ecosystem. 

Main features:

• Risk- and context-based policies that gate access rather than relying on static allow lists. 
• Schedule recurring or ad-hoc reviews. 
• Automated lifecycle workflows. 

Pricing: Plans starting from $6/user/month. 

Best for: Microsoft-centric enterprises that want identity security and governance. 

Review: “Microsoft Entra ID has all [the] features required to build a successful end-to-end solution that can scale with the increase of our product demand grows.”

Govern Access Without Slowing Engineers Down

Identity governance is about the way you govern access to match how your teams ship. Legacy identity governance and administration tools can still help with lifecycle workflows and audit reporting, but they often struggle when permissions change daily across cloud, Kubernetes, data platforms, and third-party tools.

The best IGA solution brings together time-bound access, tighter approvals, and audit evidence you can trust, without turning every request into a ticket.

If you’re trying to modernize governance for cloud-native infrastructure, Apono enforces least privilege in real time with automated Just-In-Time access and self-serve approvals in Slack, Teams, or CLI.  Download the audit readiness checklist for access and privileged access controls to see where your current governance model stands, and how to close gaps before your next audit. Alternatively, book a demo to see how Apono enforces real-time, time-bound access across cloud infrastructure, apps, and data.

The question enterprises are asking is no longer whether to deploy AI agents. It is how to do it without creating security risk they cannot control.

In December 2025, Amazon’s own AI coding tool Kiro triggered a 13-hour AWS outage after autonomously deciding to delete and recreate a production environment. Amazon’s official response was telling: the problem wasn’t the AI, it was that the agent “had broader permissions than expected.”

In other words, the standing privileges were the issue.

That is not a one-off incident. It is a preview of what happens when agents operate with access they were never meant to use. Co-pilots like GitHub Copilot, Cursor, and Claude Code are already active inside enterprise environments, and autonomous agents are not far behind. 

Both share a critical gap that traditional Privileged Access Management was never designed to close: standing privileges with no mechanism to govern how they are used at runtime.

Today, Apono is closing that gap with the launch of Agent Privilege Guard.

The problem with how agents are privileged today

When a co-pilot or autonomous agent is deployed, it typically inherits broad permissions granted at configuration time, based on what the agent might need rather than what it is doing at any given moment. Those privileges sit there, standing, available to be used or abused at any time.

That model worked well enough when the identity making a privilege request was human. Humans have context. They recognize unusual requests. Agents are different. 

They act autonomously at machine speed, trust their inputs, and can be manipulated, hallucinate, or simply overreach in ways that cause real damage before anyone notices.

Because agent activity looks like normal operations in the logs, there is often no alarm at all. Static PAM policies written at configuration time cannot keep up with non-deterministic systems making thousands of decisions a minute.

Introducing Intent-Based Access Controls

At the core of Agent Privilege Guard is Apono’s Intent-Based Access Controls (IBAC), a runtime enforcement model built around a simple principle: evaluate every privilege request at the moment it is made, based on what the agent is actually trying to do and the sensitivity of the privilege being requested.

Every request falls into one of three outcomes:

• Freely permitted. Low-sensitivity requests are auto-approved instantly, with no friction to agent productivity.
• Human in the loop. Sensitive operations are routed to a human for approval in Slack before execution.
• Denied. Requests that exceed policy thresholds are blocked before they run. The action never executes.

All credentials are ephemeral, scoped to the specific task, and automatically revoked on completion. 

Every privilege request, stated intent, approval decision, and downstream action is logged in one place. 

After each operation, every environment returns to a state of Zero Standing Privileges. This means that the blast radius of any failure, whether from manipulation, hallucination, or misconfiguration, is contained by design.

This is what Gartner and independent analysts have begun calling Continuous Adaptive Trust: every privilege request assessed at the moment it is made, with privileges revocable in real time if behavior deviates from intent. 

Where Zero Trust redefined network security, Continuous Adaptive Trust applies the same logic to identity in the agentic era.

Securing co-pilots today, ready for autonomous agents tomorrow

Most enterprises are already in the early stages of their agentic journey, deploying co-pilots to accelerate engineering productivity. 

Agent Privilege Guard secures that deployment today, extending existing just-in-time and just-enough-access policies to co-pilot agents with no additional configuration required. 

The privilege gap most enterprises have with their co-pilots can be closed immediately, without rethinking an existing security posture.

As organizations move toward more autonomous deployments, the same platform scales with them. 

The IBAC guardrails and audit trail that secure co-pilots today are built to handle fully autonomous agents operating at machine speed, applying consistent runtime privilege controls across every identity regardless of how autonomous it becomes.

The window to get ahead of this is closing

Autonomous agents are moving into production environments faster than security teams can assess the risk. Agent Privilege Guard gives security and IT leaders a way to say yes to agent deployments without writing a blank check on privilege. Agents get the access they need, sensitive operations stay under human control, and every action is logged with full context.

Amazon called its December outage a user access control issue, not an AI issue. They were right. The access controls are the problem, and fixing them before agents are deeply embedded in your infrastructure is significantly easier than fixing them after.

Apono will be showcasing Agent Privilege Guard at RSA Conference 2026 in San Francisco at booth 5170, North Expo. 

To learn more or request a demo for Agent Privilege Guard, visit HERE

Permission creep rarely looks dangerous at first. It starts as a temporary fix, such as granting an admin role to unblock a deployment. Over time, those temporary decisions become permanent standing permissions. The result is an AWS estate littered with high-privilege roles that sit idle for months, expanding your attack surface without anyone actively noticing.

It takes organizations an average of 277 days to identify and contain a breach. In cloud-native environments where attackers can move laterally in minutes, relying on quarterly IAM reviews and reactive cleanup simply doesn’t scale.

And yet, that’s how most teams manage access today. To move beyond the “whack-a-mole” approach to security, teams must shift from discovering access risks to preventing them from being introduced in the first place. That means eliminating unnecessary standing permissions and enforcing least privilege continuously, which is where AWS IAM Access Analyzer plays a role. 

What is IAM Access Analyzer?

AWS IAM Access Analyzer is a policy analysis service that uses automated reasoning to identify unintended public and cross-account access to AWS resources. It continuously evaluates resource-based policies and trust relationships to determine whether external principals, including other AWS accounts or federated users, can access your resources. 

IAM Access Analyzer acts as a continuous auditing layer. Rather than scanning for simple misconfigurations, it analyzes policies to identify all policy-based access paths to a resource, including access from outside your defined zone of trust.

IAM sprawl and overly permissive policies are natural side effects of clouds at scale and the push for operational speed. AWS IAM Access Analyzer acts as a continuous auditing layer, strengthening identity and access governance by surfacing unintended access paths before they become systemic risk. Broad permissions granted to unblock deployments and the rapid growth of machine identities all contribute to standing privilege and policy complexity.

5 Reasons to Use IAM Access Analyzer

1. Discover unintended access early: The tool uses automated reasoning to flag resources shared with external principals or the public the moment a policy is changed. This allows you to remediate accidental exposure before a bad actor can exploit the opening.
2. Reduce IAM policy sprawl: Unlike many traditional IAM tools, Access Analyzer focuses specifically on policy-level exposure inside AWS environments.
3. Support least-privilege initiatives: It generates fine-grained policies based on actual historical activity found in CloudTrail logs. This replaces broad “Admin” or “FullAccess” policies with exact permissions tailored to what a user or service actually does.
4. Improve security reviews and audits: AWS Analyzer provides a centralised dashboard of findings that serves as a “source of truth” for auditors. It proves you are actively monitoring access and provides a clear trail of remediated risks for compliance standards, such as SOC2.
5. Prevent misconfigurations at deployment time: IAM Access Analyzer includes policy validation capabilities that act like an automated pre-deployment security checker. When integrated into CI/CD pipelines, it can block overly permissive or malformed IAM policies before they reach production.

IAM Access Analyzer Resource Types

Knowing which resources IAM Access Analyzer evaluates is critical because the tool doesn’t monitor everything; it monitors only a specific subset of AWS resource types that support resource-based policies. Understanding the perimeter of these boundaries allows security teams to identify security blind spots, as resources not covered may still be the entry point for significant access risks.

Table 1: Resource Types

AWS Resource	Risk if Misconfigured	Potential Impact
Amazon S3	Sensitive files (PII, financial records, internal documents) become publicly readable or accessible to unauthorized third-party accounts.	Data leaks, reputational damage, customer trust erosion, and regulatory fines under GDPR, CCPA, HIPAA, and similar frameworks.
IAM Roles	Overly permissive or misconfigured trust policies or misuse of permissions like IAM:PassRole can allow external principals to pass privileged roles to AWS services.	Privilege escalation, administrative takeover, lateral movement, and data theft.
AWS KMS (Keys)	Key policies allow unintended cross-account or public access to encryption keys.	Decryption of sensitive data (database credentials, EBS volumes, application secrets). Encryption becomes functionally ineffective — encryption is only as strong as its key policy.
AWS Lambda (Functions)	Overly broad invocation permissions allow unauthorized accounts to execute functions.	Cost spikes (“denial of wallet”), unauthorized logic execution, backend manipulation, and service disruptions that contribute to downtime losses.
Amazon SQS (Queues)	Queue policies grant access to unauthorized entities.	Message interception, data theft from payloads, or injection of malicious commands into application workflows.
Amazon SNS Topics	Topic policies allow unauthorized publishing or subscribing.	Triggered automation abuse, data leakage, and downstream system manipulation.
AWS Secrets Manager	Resource policies expose secrets to unintended principals.	Credential theft (API keys, database passwords), leading to downstream system compromise.
Amazon RDS (Snapshots)	Snapshots shared publicly or cross-account without controls.	Full database exfiltration and restoration in attacker-controlled environments, bypassing VPCs, firewalls, and security groups.
Amazon ECR (Repositories)	Overly permissive repository policies expose or allow modification of container images.	Supply chain compromise, exposed infrastructure secrets, and image poisoning that propagates across environments.

7 Tips for Using IAM Access Analyzer

1. Start with High-Risk Resources First

Access Analyzer categorises findings based on the resource type and the level of access. Some resources, such as S3 buckets and IAM roles, pose a significantly higher risk if misconfigured than others. 

Focus your initial “cleanup” phase exclusively on Public and Cross-Account findings for S3 buckets, SQS queues, and KMS keys. In the console, use the filter isPublic: true to identify resources that are accessible to anyone on the internet. Remediating these “open doors” provides the highest immediate return on security posture.

2. Treat Findings as Signals, Not Noise

A finding is based on logic-based reasoning (provable security), indicating a real policy-permitted access path. The same type of misconfiguration is routinely identified during offensive security assessments and red team exercises.

Avoid alert fatigue by integrating findings into your existing incident response workflow. Use Amazon EventBridge to trigger automated notifications (via SNS or Lambda) when a high-severity finding is generated. This best practice transforms the tool from a static report into a real-time security signal that prompts immediate investigation.

3. Validate IAM Policies Before Deployment

Policy validation in IAM Access Analyzer is a proactive security layer that acts as a “linter” for your IAM policies. It complements other cloud security controls, including infrastructure scanning and API security tools, by preventing overly permissive access from being deployed in the first place.

Shift security left by integrating the IAM Access Analyzer SDK into your CI/CD pipelines (e.g., GitHub Actions or GitLab CI). Set a gate that prevents the deployment of any CloudFormation or Terraform template that contains “Security” or “Error” level findings. 

4. Review Findings Regularly, Not Once

Engineering teams are constantly deploying new microservices, experimenting with serverless functions, and tweaking database connections. This high velocity creates a moving target for security.

Establish a weekly or bi-weekly cadence for your cloud security team to review the findings dashboard. Use the “Archive” function for findings deemed acceptable, but revisit those archived rules quarterly to ensure the business justification for that access still holds true.

5. Correlate Findings with Real Usage

The Unused Access Analysis feature looks at your CloudTrail history to see if the permissions you’ve granted are actually being used. It identifies “zombie” roles and unused IAM user credentials. 

When you identify an unused role via IAM Access Analyzer, your first instinct might be to hit “Delete.” However, in complex enterprise environments, some roles are “cyclical” (used only for annual disaster recovery tests or specific tax-season workloads).

6. Document Intentional Exceptions

In many complex environments, certain risky permissions are actually necessary (e.g., a cross-account role for a security vendor or a public S3 bucket for website hosting). When you encounter an intentional finding, don’t just ignore it. 

Create an Archive Rule with a specific, descriptive name and a “Reason” tag to create a documented audit trail. If an auditor asks why a specific account has access to your data, you can point to the Archive Rule as evidence of a conscious, documented business decision.

7. Eliminate Standing Permissions

The most effective way to prevent recurring findings and policy drift is to move away from permanent, high-privilege roles that sit idle 99% of the time. 

Transitioning to a Just-In-Time (JIT) access model represents a fundamental shift from static to dynamic security. It solves the root cause of the findings that IAM Access Analyzer flags by ensuring that high-risk permissions only exist when they are actively being used.

Closing the Gap Between Findings and Enforcement

AWS IAM Access Analyzer provides critical visibility into overly broad or risky access paths. For cloud-native organizations operating at scale, this insight is indispensable. However, visibility alone doesn’t reduce the attack surface. 

If you rely solely on periodic IAM cleanup, you could be trapped in a cycle of detection where standing permissions continue to accumulate, and audit pressure increases. In these cases, automated JIT access changes the landscape. 

With Apono, developers can request granular, time-bound access directly from Slack, Microsoft Teams, or CLI, with permissions that auto-expire once the task is complete. Break-glass and on-call flows allow rapid production remediation without permanently expanding privilege. Comprehensive audit logs and automated reporting provide clear visibility into who accessed what, when, and why, simplifying compliance and internal audit requirements. Learn how to ensure continuous access compliance across your entire stack, or see how automated Just-In-Time access works in practice by booking a live demo.

If you’re evaluating a move away from StrongDM, you’re probably asking two questions at the same time:

• Is it worth the disruption?
• If we switch, how do we do it without creating new risk and operational chaos?

You might be frustrated with the UI, or you may have discovered that Slack integration isn’t native and access requests still feel slower than they should. Upgrade conversations may be happening more often than meaningful product improvements.

Over time, though, the concern often becomes more structural. Static roles and session-based access no longer align with where your environment is headed.

This decision isn’t really about Slack or pricing tiers. It’s about whether your access model can support what comes next.

Why the Access Model Itself Has to Change

Your infrastructure is far more dynamic than it was a few years ago, with a broader cloud footprint and automation woven into nearly every workflow. AI agents are beginning to initiate actions rather than simply surface insights, executing changes at a pace that exposes weaknesses in overly broad, standing privileges.

When static roles sit underneath that level of autonomy, risk compounds quietly. Not because someone misconfigured a policy, but because the model itself was designed for a different era.

If you are going to leave StrongDM, the opportunity is not simply to replace a vendor. It is to rethink how privilege is granted, scoped, and revoked across your environment.

That means moving from session-based control to intent-driven access, from static roles to dynamic, ephemeral permissions, and from standing privilege to a Zero Standing Privilege model by default.

This is not just a product change. It is a shift in approach.

Here is how to execute that transition in a structured, low-risk way.

Mapping Out Your Transition Away from StrongDM to Zero Standing Privilege

If you’re making this move, the goal is not a clean vendor swap. The goal is to eliminate standing privilege without disrupting engineering velocity.

That requires structure.

1. Start with Visibility, Not Replacement

Before migrating anything, build a clear picture of what exists today.

Export your StrongDM inventory:

• Resources such as databases, Kubernetes clusters, servers, and bastions
• Users and groups
• Current role mappings
• Access frequency data

At the same time, export your identity source of truth, whether that is AWS IAM Identity Center or another IdP. Capture users, groups, and permission sets.

The objective is not to recreate your current structure inside a new tool. It is to understand where standing privilege exists so you can redesign access around intent and risk.

2. Redefine Access Around Intent

This is where the shift in approach becomes real.

Instead of asking, “What roles do we have?” ask:

• What tasks are people actually performing?
• What is the minimum scope required for each task?
• How long should that access exist?
• What level of approval matches the risk?

For example:

• Debugging production may require read-only database access for two hours.
• Running a migration may require write access for thirty minutes with approval.
• Kubernetes namespace access may need to be scoped tightly and time-boxed.

The principle is straightforward: access should reflect intent, align with risk, and expire automatically once the task is complete.

This same model applies to automation and AI agents. If a workflow needs to rotate credentials or deploy infrastructure, it should receive only the permissions required for that action, only for the duration of that action, and nothing more.

3. Plan a Parallel Transition

Avoid big-bang cutovers.

Run StrongDM and your new access platform in parallel while you migrate in controlled waves.

A practical sequence:

• High-frequency resources engineers use daily
• Critical systems with moderate usage
• Long-tail resources that are rarely accessed

For rarely accessed systems, add guardrails. Require justification and approval. If something has not been touched in months, a new request should prompt a conversation.

This phased approach reduces operational risk and builds confidence as teams adapt to dynamic access.

4. Migrate by Resource Type with Discipline

As you move resources over, focus on replacing standing access with scoped, ephemeral flows.

For Kubernetes:

• Grant namespace-level or workload-level access
• Make elevated privileges short-lived and approved

For databases:

• Separate read access from write access
• Keep write and admin privileges tightly time-bound

For servers:

• Replace perpetual admin rights with requestable elevation

For cloud permissions:

• Convert static group memberships into requestable, expiring entitlements

The principle remains consistent across every resource type: eliminate permanent privilege wherever possible.

5. Operationalize the Model

Zero Standing Privilege succeeds when the secure path is also the easiest path.

Publish clear internal guidance on:

• How to request access
• How to choose appropriate scope and duration
• What justification looks like for higher-risk requests

Train DevOps teams on flow design and policy governance. Train engineers on using chat, portal, or CLI workflows. Maintain a weekly cadence during rollout to review feedback and refine policies.

For guidance on how to plan out your access policies, check out our Just-in-Time Access Policy Design for Cloud Security Teams explainer blog.

The goal is not friction. It is controlled flexibility.

Laying the Ground for Your AI Future

As automation deepens and AI agents begin to initiate actions independently, the access model beneath them determines whether risk scales with capability.

Static roles and standing privilege were designed for a human-centric world. Agentic systems operate continuously, at speed, and often across multiple services. If those systems inherit broad permissions, the blast radius expands silently.

A Zero Standing Privilege approach ensures that access is created dynamically, scoped to intent, bounded by risk, and revoked automatically once the action is complete.

That foundation allows you to deploy more capable automation and AI without increasing systemic exposure.

Switching away from StrongDM may be the catalyst.

Adopting an intent-driven, risk-aware Zero Standing Privilege approach is the real outcome.

Done correctly, this transition does more than address UI frustrations or integration gaps. It positions your organization to scale human and autonomous access safely, deliberately, and with confidence.

Considering Life After StrongDM?

Many teams exploring a StrongDM replacement want to understand one thing first: how to migrate safely without slowing engineering down.

Book a short strategy call with our team to review your environment and discuss how organizations move from static roles to a Zero Standing Privilege model. Moving Beyond StrongDM_ A Pract…

As a thank-you for your time, Qualified StrongDM customers receive a $200 Amazon gift card after completing the session. $200 Amazon gift card.

For many organizations, Grafana is a central operational system. Engineers use it to investigate issues, analyze logs, review infrastructure metrics, and query production-connected databases. But while dashboards are visible, the real sensitivity lies in the underlying data sources Grafana connects to.

These data sources often include systems such as logs stored in Elasticsearch or OpenSearch, SQL databases like PostgreSQL or MySQL, and Amazon CloudWatch metrics. Access to these systems can provide visibility into production telemetry, infrastructure performance, and potentially sensitive operational data.

The challenge is clear: How do you give engineers fast access to Grafana data sources without maintaining standing, over-privileged access?

The problem: static access in dynamic environments

In standard operating environments, Grafana data sources are typically accessed via long-lived IAM roles or broad group assignments. This “always-on” model is designed for speed, ensuring engineers have immediate visibility during critical incidents without the friction of authentication and authorization delays.

However, for organizations handling highly sensitive data or operating under strict regulatory constraints, this approach can introduce unique operational challenges, such as:

• Persistent permissions may exceed the actual window of time an engineer needs to perform a task.
• Distinguishing between routine monitoring and targeted investigative access can become difficult during compliance reviews.
• Compliance and audit friction.

For these specialized scenarios, teams are moving toward a Just-in-Time access model. This allows for a security posture that remains dormant by default and activates only when a specific, verified need arises, aligning high-stakes security with operational flow.

Governing Grafana data sources with Just-in-Time access

Apono integrates with Grafana to continuously discover configured data sources. Each discovered data source becomes a governed resource within Apono’s access control framework.

Security and platform teams define policies to specify:

• Who can request access
• Which data sources they can access
• Whether human approval is required
• Maximum access duration
• Contextual conditions (such as on-call status)

Instead of granting permanent access to a logs or metrics data source, organizations move to an on-demand model.

A typical workflow

1. An engineer needs to query a specific Grafana data source (for example, a logs or metrics backend).
2. They submit a request for access.
3. Apono evaluates the request against predefined policies, and user and asset context.
   Access is granted for a defined time window.
4. When the time expires, access is automatically revoked.

There are no permanent role changes and no lingering privileges. Access becomes scoped, time-bound, and policy-driven.

Reference architecture: Just-in-Time access for Grafana data sources

The diagram below illustrates how Apono integrates with Grafana and connected data sources to enforce time-bound access while preserving operational workflows.

In this model:

• Grafana connects to multiple data sources (logs, metrics, traces, cloud services, databases).
• Apono integrates with Grafana to discover and govern access to those data sources.
• Access requests are evaluated against centralized policies.
• Permissions are provisioned temporarily and revoked automatically.

This architecture ensures that access to observability data is dynamic and controlled, rather than static and persistent.

Incorporating operational context with Grafana Cloud IRM

For teams using Grafana Cloud IRM, access decisions can incorporate operational signals such as:

• On-call schedules
• Active incident participation
• Responder roles

By integrating Grafana Cloud IRM with Apono, organizations can align access with real-time operational responsibility. For example:

• Only an engineer currently on call can receive immediate access to a production data source.
• Access can be limited to the duration of an active incident.
• Permissions automatically expire when responsibility shifts or the incident is resolved.

This ensures access reflects real-time operational context rather than static IAM group membership.

Benefits for users

Organizations using Grafana together with Apono report improvements across both security and operational efficiency. Here’s a closer look at the benefits:

• Zero Standing Privileges: Access to Grafana data sources is granted only when required and automatically revoked.
• Faster investigations: Engineers obtain faster access without waiting for manual IAM updates.
• Reduced blast radius: Short-lived permissions limit exposure if credentials are compromised.
• Policy-driven governance: Access policies are centrally defined and consistently enforced.
• Full audit visibility: Every access event is logged, supporting compliance and review processes.

Getting started and next steps

The Apono integration is available for both on-premises Grafana and Grafana Cloud. 

As a practical first step, we recommend identifying which of your Grafana data sources connect to sensitive production systems and are currently governed by standing roles.

From there, teams can:

• Integrate Grafana with Apono
• Discover existing data sources
• Define time-bound access policies
• Gradually remove permanent access assignments

As observability environments grow in scale and importance, implementing Just-in-Time and least privilege access for Grafana data sources helps minimize risks without slowing teams down.

To learn more, please explore our integration documentation.

Earlier this year, AWS experienced a 13-hour outage that was reportedly linked to one of its own internal AI coding tools. 

Apparently, their Kiro agentic coding tool thought that there was an issue with the code in the environment, and that the best way to fix it was to simply burn it to the ground. 

In their statement, AWS stated that the issue here wasn’t necessarily with their agent but with the user access controls where the human had more privileges than they were supposed to have, which allowed the agent to go forth and cause the outage.

Regardless of where the breakdown occurred, the incident raises serious questions about how we approach Agentic AI Security as autonomous systems begin operating inside sensitive environments.

Organizations are under pressure to integrate more agents into their workflows in hopes of harnessing their scale and speed to increase velocity. At the same time that they share the desire for accelerated productivity, CISOs have real concerns about releasing these unpredictable agents near to their crown jewels. 

In a recent survey of some 250 security leaders, a whopping 98% of respondents reported that they are slowing the adoption of agents into their organizations due to security concerns. 

These leaders are not resistant to innovation. They recognize that we’re undergoing a structural shift — from deterministic software to autonomous systems. That shift fundamentally challenges traditional models of Agentic AI Security.

The Catch: Non-Deterministic Systems

Before going further, it’s worth being explicit about what we mean by deterministic because this is where many of our assumptions quietly break.

A deterministic system is one where the same input, under the same conditions, will always produce the same output.

A non-deterministic system behaves differently. The same request can yield different outcomes depending on context, prior state, interpretation, or probabilistic reasoning. The system is not simply executing instructions. It is deciding how to act.

Traditional security models, including Zero Trust, implicitly assume determinism: software is predictable, permissions are static, and risk comes primarily from humans misusing or abusing access.

AI agents break that assumption.

When Agents Go Wrong

There are two primary failure modes in Agentic AI Security:

1. Manipulation

Social engineering has always targeted humans — exploiting context, urgency, and framing. Now that same pressure can be applied to machines. Prompt injection, malicious instructions embedded in documents, or carefully crafted inputs can push an agent into behavior it was never meant to perform.

An agent may:

• Send sensitive information externally
• Access systems outside its intended scope
• Trigger workflows with cascading impact
• Modify or delete critical data

The attack surface expands because the agent acts with legitimate credentials.

2. Overreach

Agents are mission-driven. They optimize for task completion. If their objective is to “solve the problem,” they may take increasingly aggressive actions that appear logical in isolation but are destructive in context.

They don’t understand proportionality. They don’t understand long-term consequences.

And critically, they operate at machine speed across real systems.

This is the core risk in Agentic AI Security: non-deterministic systems with deterministic privilege grants.

Hallucinations and unintended behavior

Agents consume large volumes of data. They summarize, correlate, and infer. 

And sometimes they get it wrong. Even when the reasoning sounds coherent, the action can be harmful.

Consider a simple analogy.

You’re trying to turn off a light but can’t find the switch. At first, you try reasonable solutions — look for another switch, ask someone nearby, and maybe unscrew the bulb.

But as frustration grows, more extreme options start to appear. What if you cut power to the entire house? What if you call the utility company? What if — in the most absurd version — you burn the house down just to guarantee the light goes out?

You would never do that, because you understand proportionality. You understand consequences.

An agent probably does not. 

In a recent report released by the Claude team on testing of their Opus 4.6 model, they found that when it hit roadblocks to getting the access it needed to perform a task, it simply “found” other credentials like hardcoded creds and Slack tokens to get to where it wanted to go. It then proceeded to attempt price colluding and got better at hiding its bad behavior from its monitors. You can get a deeper dive in this fascinating video here below.

As we see, an agent will figure out how to escalate in pursuit of its goal. If the objective is “solve the problem,” it may choose the most direct path available — even if that path is destructive.

Adding to the challenge is that an agent operates at machine speed, across real systems. This makes it incredibly difficult monitor and control its thousands of decisions at scale

This is the core risk at the center of Agentic AI Security: non-deterministic, mission-driven software operating with static privileges.

So then given the risks, how do we protect ourselves in a world where our software behaves more like a person than a script?

Many teams skip this question and deploy agents everywhere.

Let’s slow down and map the risks from the perspective of what they are allowed to do.

Levels of Agent Autonomy

Not all agents are created equal.

Some are little more than conversational interfaces. Others can read internal systems. Some can generate artifacts, trigger workflows, or modify production environments. Lumping them together obscures the real risk.

To understand the challenges ahead, we need to break agents down by capability. Risk does not emerge all at once. It compounds as agents move from observing, to communicating, to reading, to acting, and finally to modifying.

Up to this point, the risks are mostly conceptual. From here on, they become operational and they compound quickly. 

The Hidden Power You’re Granting by Default

In many deployments, agents are given broad capabilities by default — for convenience and speed — without fully accounting for the risk.

Common examples include shell or command execution, file read/write/delete access, browser access with stored sessions, broad internet access, background execution, multi-channel messaging, and external tool execution.

Every one of these must be explicitly evaluated.

This is not optional.

1. The Environment Matters

Agents run somewhere.

That environment must be designed as hostile-by-default.

Minimum requirements:

• No admin privileges
• Hardened OS
• No sensitive data present
• Explicitly scoped network access

If the agent shouldn’t see it then it shouldn’t exist on that machine.

2. Communication Control

Limit which channels the agent can use.

Channels restricted only to the owning user are critical to prevent:

• External influence
• Silent data exfiltration

3. Tool Access and Least Privilege

Every tool granted to an agent should be evaluated along three dimensions:

• Read
• Create
• Modify/Delete

Using them securely means implementing some commonsense practices:

• Never store passwords or secrets on the agent’s machine.
• Use short-lived credentials, injected only when required.
• Apply least privilege guardrails rigorously.

From Zero Trust to Continuous Adaptive Trust

Zero Trust was a major evolution. It forced organizations to stop assuming implicit trust and to validate identity before granting access.

But Zero Trust still assumes something critical: that once access is granted, software behaves predictably.

AI agents invalidate that assumption, forcing a redefinition of Agentic AI Security beyond identity validation alone.

What’s required instead is a model of Continuous Adaptive Trust. This is sometimes described as Just-in-Time (JIT) Trust.

In this model, access is not static. It is ephemeral, scoped, and continuously evaluated.

Access becomes:

• Time-bound
• Purpose-bound
• Context-aware
• Continuously reassessed

Instead of long-lived credentials and standing privileges, agents receive narrowly scoped, temporary grants aligned to a specific task. These grants expire automatically.

Trust is derived not just from identity and context, but from observed intent and behavior. This includes prompts issued, tools invoked, APIs called, execution patterns followed.

Intent is a critical component to securely managing agents because it is the best indicator of what we want it to accomplish. Furthermore, we need to be able to understand the relationship between our intended action and the behavior that the agent is trying to carry out.

If there is a discrepancy between the two, then this is a red flag that we might have a problem.

When behavior deviates from expected intent, the system responds dynamically:

• Privileges can be reduced
• Scope can be constrained
• Human approval can be triggered
• Access can be suspended

By creating guardrails that continuously assess intent and the risk level of behaviors to determine where agents can work uninterrupted and where a human is required to be in the loop, organizations can confidently deploy autonomous agents and reap the benefits of exponential productivity in their business.

So Can Every Employee Have an AI Agent?

Not under static entitlement models. Not a chance.

But under Continuous Adaptive Trust — with ephemeral access, intent/behavioral monitoring, and real-time privilege adjustment — the answer becomes more nuanced.

We’re at an inflection point in Agentic AI Security.

The future is clearly agentic. The productivity upside is undeniable. But to embrace it safely, we must evolve privilege management. Static entitlements cannot govern dynamic systems. Adaptive privilege models — aligned to intent, risk, and context — are the foundation of sustainable Agentic AI Security.

Ready to Stress-Test Your Agentic AI Security?

Before deploying autonomous agents broadly, understand how your current privilege model holds up under real-world scenarios.

The Agent Privilege Lab is an interactive simulation tool that lets you explore agent autonomy levels, attack paths, and privilege escalation risks — and see how blast radius expands as access increases.

Request access below to unlock the interactive simulator and evaluate your Agentic AI Security posture.