Agentic security in practice raises new identity governance questions

At a glance

What this is: Cyberhaven's whitepaper shows how autonomous security agents are being used for triage, threat modeling, and IT support, with measurable gains in speed and coverage.

Why it matters: This matters because identity teams now have to govern agents that reason and act across internal workflows and third-party systems, not just static service accounts.

By the numbers:

• Cyberhaven says manual triage consumes up to 40% of a security engineer's week.
• Cyberhaven says Cerberus reduced false positives by 85% compared to raw scanner output.
• Cyberhaven says Vektr now delivers threat models covering 100% of architectural designs.
• Cyberhaven says Jarvis resolves more than 70% of routine IT tickets without human intervention.

👉 Read Cyberhaven's whitepaper on autonomous security agents in the CISO playbook

Context

Agentic security refers to security workflows where software systems can reason, choose actions, and execute across tools rather than simply assist a human operator. In this whitepaper, Cyberhaven describes three autonomous agents used for vulnerability triage, threat modeling, and IT support, which places identity governance at the centre of operational security design.

The primary IAM question is no longer whether an automation can save time. It is whether a runtime decision-maker can be trusted with scoped access, third-party actions, and approval paths that were designed for human-paced workflows. That shift changes how security teams think about entitlement boundaries, review cadence, and accountability.

The article's starting point is typical for mature security teams under pressure: too much manual work, too few specialists, and too many decisions waiting in queue. What is atypical is the degree of autonomy now being delegated to agents inside core security operations.

Key questions

Q: How should security teams govern autonomous agents that use backend tools?

A: Treat autonomous agents as identities with their own scopes, policies, and revocation paths. The important control is not whether the workflow runs, but whether the agent can only call approved tools, obtain the minimum downstream access needed, and leave a reliable audit trail for each action it takes.

Q: Why do AI agents complicate traditional access reviews?

A: AI agents complicate access reviews because they can accumulate permissions across tools and environments faster than manual certification cycles can observe. A review process built for stable human accounts does not fit an executor that can act across systems, create new access paths, and complete work before the next review window begins.

Q: What breaks when an AI agent can remediate issues directly in SaaS tools?

A: The boundary between recommendation and action breaks first. Once the agent can change settings, close tickets, or modify identity records, it is no longer supporting the operator, it is acting as one. Without explicit scope limits and traceable approvals, accountability becomes ambiguous after the change is already in place.

Q: What should organisations measure to know whether agentic security is under control?

A: Measure more than output quality. Track which systems each agent can touch, how often it uses those permissions, whether its access expands over time, and whether every action is attributable to a specific task. If the agent's authority grows faster than governance artefacts, the programme is losing control.

Technical breakdown

Autonomous security agents and identity boundaries

An autonomous security agent is not just a workflow script with an LLM attached. It can decide what to inspect, which tools to call, and when to act without a human approving each step. That behaviour makes identity scope a runtime problem rather than a provisioning problem, because access must be safe for the full decision chain, not just the initial task. In practice, this pushes security teams toward tighter tool allowlists, task-scoped permissions, and explicit limits on what an agent can do once it has valid credentials.

Practical implication: define per-agent access boundaries around actions, not only around accounts.

Why false-positive reduction changes triage governance

A triage agent that cross-checks multiple models and applies a judge model changes the operational meaning of evidence. Instead of a human analyst comparing isolated scanner output, the agent synthesises signals from several sources and produces a final verdict. That can improve throughput, but it also concentrates decision influence in one runtime path. The governance challenge is not just output quality. It is traceability, because every high-confidence result now depends on the agent's internal reasoning, model selection, and evidence weighting.

Practical implication: require auditability for agent verdicts, not just for the underlying alerts.

Third-party actions and agent privilege in IT support

When an agent can act directly in Okta and other third-party systems, it is effectively holding delegated operational authority. That is different from recommending a fix or drafting a ticket. The access pattern looks like NHI, but the behaviour is autonomous because the agent chooses when to act and can complete a task without human intervention. This creates a governance overlap between NHI controls, privileged access rules, and change accountability, especially when the agent can remediate issues across multiple systems in one session.

Practical implication: treat agent-to-SaaS access as privileged operational access, not ordinary automation.

NHI Mgmt Group analysis

Agentic security creates an identity governance gap, not just a productivity gain. The moment a security system can reason and act across tools, the control problem shifts from who is allowed to trigger a workflow to what the actor itself is allowed to decide at runtime. Existing IAM models were built around stable subjects and predictable requests. That assumption weakens when the identity is an agent that can triage, model, and remediate inside one session. The implication is that governance must move from request-based approval to runtime authority boundaries.

Task success metrics can obscure privilege creep in agentic workflows. A system that resolves 70% of tickets or covers 100% of design reviews may look operationally mature, but those numbers do not reveal how much latent authority the agent accumulated to get there. In NHI terms, the relevant question is not only whether the agent worked, but whether its access surface expanded across Okta, internal systems, and design tools without corresponding lifecycle controls. Practitioners should read productivity metrics as a potential proxy for expanding identity blast radius.

Autonomous agents collapse the assumption that access is stable long enough to review. Access review processes were designed for identities whose privileges persist until the next certification cycle. That assumption fails when an agent can acquire, combine, and exercise permissions within a single session and then move on to another system path before a reviewer ever sees the state. The implication is not merely better review cadence. It is a need to rethink whether certification is still the right control model for agentic execution.

Named concept: runtime authority boundary. This article shows why the decisive control is no longer the account record but the live envelope of actions an agent can perform in a given task. That boundary has to account for tool selection, execution timing, and downstream side effects, because the same credential can be harmless in one context and excessive in another. Security teams should treat the runtime authority boundary as the unit of governance for autonomous agents.

Cybersecurity teams should expect agentic identity to spread from support workflows into core control planes. Once agents prove they can reduce manual work, they tend to move from narrow pilot use cases into broader operational decision paths. That widens the gap between traditional IAM governance and the behaviour of systems that increasingly act like operators. The practical conclusion is that identity programmes need a separate lens for autonomous systems before adoption scales faster than governance can adapt.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• That blind spot becomes more consequential when agentic workflows extend into remediation, so practitioners should pair agent telemetry with the governance patterns in OWASP Agentic AI Top 10.

What this signals

Runtime authority boundary: the next governance gap is not whether agents are useful, but whether their live permissions can be bounded tightly enough for audit and offboarding. Teams that already struggle to certify human and machine access on schedule will find agentic decision speed exposes the limits of their current review model.

With 92% of organisations saying governing AI agents is critical but only 44% having implemented policies, the programme signal is clear: operational adoption is outrunning policy design. Security leaders should expect this gap to show up first in incident response, approval logging, and third-party access governance.

The practical shift is toward identity controls that observe agent behaviour in real time rather than after the fact. That includes tighter linkage between the identity layer, tool permissions, and evidence retention, with standards-oriented thinking from the NIST AI Risk Management Framework helping anchor the governance conversation.

For practitioners

• Define runtime authority boundaries for each agent Map every autonomous agent to the exact actions, tools, and external systems it can touch during execution. Separate read, recommend, and remediate permissions so the agent cannot escalate from analysis into direct action without explicit design intent.
• Classify agent access as privileged operational access Review integrations with Okta, Slack, ticketing, code, and security tooling as privileged pathways. Apply stronger approval, logging, and offboarding expectations than you would for ordinary workflow automation because the agent can make decisions and execute them.
• Audit review cadences against agent decision speed Test whether access certification, recertification, and exception handling can still observe the state an autonomous agent uses before it changes. If the answer is no, the control is lagging the actor rather than governing it.
• Instrument agent decisions for evidence and traceability Require event-level logs that show what the agent saw, what it chose, which tool it invoked, and what changed in the target system. Without that trail, troubleshooting and accountability both collapse once the agent completes the task.

Key takeaways

• Autonomous security agents change the identity problem from workflow automation to runtime authority management.
• The strongest evidence in the article is operational, not theoretical: false positives fell by 85%, routine tickets resolved at more than 70%, and full design coverage was claimed for threat modeling.
• Security teams should govern agentic access as privileged, time-bound authority with auditable decisions, or their IAM programme will trail the actor it is supposed to control.

Key terms

• Autonomous Security Agent: A software system that can decide what to do, choose tools, and execute actions without a human approving each step. In identity terms, it behaves like a runtime actor with delegated authority, so governance must cover both the account and the live action envelope.
• Runtime Authority Boundary: The set of actions, tools, systems, and side effects an autonomous identity is allowed to exercise during a task. It matters because the same credential can be safe in one context and excessive in another, especially when an agent can chain actions across systems.
• Agentic Access: Agentic access is delegated system access granted to an AI agent or autonomous workflow so it can perform defined tasks across tools and data sources. It differs from human access because the actor can execute continuously, combine actions quickly, and amplify mistakes at scale.

What's in the full report

Cyberhaven's full whitepaper covers the operational detail this post intentionally leaves for the source:

• How Cerberus cross-checks findings across Anthropic, OpenAI, and Google models before issuing a verdict
• How Vektr applies STRIDE inside the RFC review process to generate threat models for architecture designs
• How Jarvis executes directly in Okta and other third-party systems to resolve routine IT tickets
• How the Office of the CISO structured collaboration between autonomous agents and human reviewers

👉 Cyberhaven's full whitepaper covers the agent design, workflow integration, and operational outcomes in detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or operational governance, it is worth exploring.