Controlled autonomy for AI agents in security operations

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Mate's blog post: Controlled-autonomy for AI agents in security operations uses gamebooks, context graphs, capabilities, and constrained flows to let agents adapt without improvising beyond approved boundaries.

Why it matters: IAM, NHI, and security operations teams need this because autonomous decision-making changes where control has to live, shifting governance from static workflows to bounded execution, approval thresholds, and auditable context.

Context

Security operations teams are no longer choosing only between deterministic automation and free-form AI. The real problem is how to govern agent behavior when speed matters, the environment changes mid-investigation, and human approval may arrive too late to contain the event.

In this model, AI agents are treated as runtime decision-makers that can reason and pivot, but only inside versioned investigation boundaries. That makes the article relevant to autonomous identity governance, because the control question is no longer just what the agent can do, but what it is allowed to decide, when, and under which conditions.

The article’s central claim is that security programs fail when they force agents into brittle scripts or give them unrestricted freedom. Controlled autonomy is presented as the design pattern that preserves machine-speed response without turning the agent into an ungoverned operator.

Key questions

Q: How should security teams retain command over autonomous AI agents that act on their behalf?

A: Security teams should treat AI agents as governed actors, not perimeter threats. Start by defining what actions the agent is allowed to take, what data it may reach, and which steps require human confirmation. Then use continuous monitoring, policy enforcement, and rapid intervention for irreversible actions. The goal is not to block every move, but to keep machine-speed behavior inside clearly defined boundaries.

Q: Why do unbounded AI agents create more operational risk than SOAR playbooks?

A: SOAR is brittle because it assumes the world stays close to the script, but unbounded agents are risky because they can improvise past boundaries. The risk comes from combining real-time decision-making with unrestricted execution, which can turn a useful investigation into an unauthorised operational change.

Q: What breaks when security automation loses investigation context between incidents?

A: Teams lose the reasoning behind prior thresholds, exceptions, and verdicts, so each new case has to be rediscovered from scratch. That produces repeated mistakes, inconsistent decisions, and stale assumptions that no longer match the environment being investigated.

Q: When should teams test an AI agent’s response logic before enabling production actions?

A: Test in shadow mode whenever the procedure can affect access, containment, or production systems, especially when the agent is new, the environment is changing, or the response path has not yet been validated against prior investigations. The goal is to prove boundary discipline before the agent can act for real.

Technical breakdown

Gamebooks versus SOAR playbooks

A SOAR playbook is a fixed script: one alert maps to one sequence of actions, usually with hardcoded APIs and branching logic. A Gamebook instead defines investigative intent, required evidence, allowed pivots, escalation thresholds, and approval boundaries. That distinction matters because security investigations are not deterministic in the way workflows are. New context can appear mid-stream, and the next best step depends on what the agent has already learned. In controlled autonomy, the agent is not given freedom to invent policy; it is given structured room to adapt within policy. The Gamebook becomes the governance layer, not just the automation layer.

Practical implication: Practitioners should govern investigation intent and boundary conditions first, then encode tool actions as constrained execution, not as the policy itself.

Security Context Graph as governed memory

The Security Context Graph is a structured memory layer that retains investigation history, analyst reasoning, business context, and confidence state. Instead of freezing a decision into a permanent allowlist or one-off exception, the Graph preserves why the decision was made and under what conditions it remains valid. That allows future agent actions to inherit context rather than re-litigate every signal from scratch. It also prevents the common failure where automation forgets institutional knowledge between incidents. For autonomous or semi-autonomous operations, memory is part of governance: without it, the agent may repeat work, repeat mistakes, or apply stale assumptions to a changed environment.

Practical implication: Practitioners should treat contextual memory as a control surface and retain decision rationale alongside alerts, exceptions, and investigation outcomes.

Flows constrain execution while preserving speed

Flows are reusable execution DAGs that connect capabilities to real systems through typed inputs, enforced permissions, and scoped action sets. The agent can decide which capability to invoke next, but the Flow defines how that capability can touch systems. This is the boundary that makes controlled autonomy possible: the agent can act at machine speed without being allowed to silently expand its permissions or execute outside the permitted scope. In identity terms, the Flow is where authorization becomes operationally enforceable. It is also where environment variance is absorbed, because the same capability can work across different endpoint, SIEM, or service-management tools without changing the governance model.

Practical implication: Practitioners should separate decision authority from tool authority so that autonomous reasoning never becomes unrestricted operational access.

Threat narrative

Attacker objective: The attacker’s objective is to outrun human-in-the-loop response and complete disruptive action before containment can be authorised.

1. Entry begins when an attacker reaches initial access and the human response loop is still pending, creating a race between machine-speed containment and manual validation.
2. Escalation occurs if the security workflow cannot pivot quickly enough, allowing the attacker to move from detection to broader impact before containment is approved.
3. Impact follows when the delay between evidence, decision, and action is long enough for the attacker to disable accounts, revoke access, or disrupt production systems.

Breaches seen in the wild

• Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.
• Spain's first AI agent data breach 2026: Spain's AEPD logged its first breach notification attributed to an attacker's AI agent, which altered personal data and accessed invoices.

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

NHI Mgmt Group analysis

Controlled autonomy is the right security model for AI agents. The false choice is between brittle scripts and unconstrained agents. Security operations need a third model in which the agent can reason and pivot, but only within explicit boundaries that define intent, evidence, and escalation.

Access review assumptions collapse when decision speed outpaces review cadence. Access review processes were designed for access that persists long enough to be observed, validated, and recertified. That assumption fails when an autonomous system can acquire, use, and release decision authority inside a single operational cycle. The implication is that governance must move closer to issuance and execution, not rely on retrospective certification.

Gamebooks create a named concept worth carrying into identity governance: bounded investigative autonomy. This is not just workflow automation with smarter branching. It is a governance pattern that separates what the agent is trying to achieve from how it reaches the outcome, while keeping approvals, scope, and evidence requirements explicit.

Context retention becomes a control, not a convenience. When analyst reasoning and environmental conditions are preserved in a shared memory layer, the organisation avoids re-creating the same exceptions and the same mistakes. That matters across human IAM, NHI operations, and autonomous agents because the control failure is usually not lack of action, but loss of decision context.

Security teams will increasingly judge automation by its boundary discipline, not its accuracy claims. A system that is 90% correct can still be unacceptable if the 10% failure mode is a privileged destructive action. The field needs to evaluate where authority lives, what evidence is required, and how quickly the agent can be stopped when context changes.

From our research library:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
• 19% of organisations give AI systems dramatically more access than human employees, nearly one in five granting unrestricted privilege, according to the 2026 Infrastructure Identity Survey.
• Read next: Agentic AI Identity Guide

What this signals

Bounded investigative autonomy: Security teams are moving toward a model where agents can reason and pivot, but only inside versioned procedures with explicit evidence requirements and approval boundaries. That matters because the control objective shifts from scripting every action to governing where independent decision-making is permitted.

Access review cycles do not solve this problem on their own. If an AI system can acquire, use, and release authority inside one investigation cycle, the governance task becomes issuance-time constraint, execution-time monitoring, and context retention, not retrospective certification.

70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey. That gap explains why controlled autonomy has to be treated as an access-governance issue, not just an orchestration pattern.

For practitioners

• Define investigation intent before tool steps Express each investigation as required evidence, permitted pivots, escalation triggers, and stop conditions before mapping any API calls or scripts.
• Separate decision authority from execution authority Let the agent choose the next capability, but keep tool access, scopes, and rate limits inside constrained flows that cannot be silently expanded.
• Preserve analyst reasoning in shared context Store why a threshold, exception, or verdict was chosen so later investigations inherit the rationale instead of repeating it as an ad hoc decision.
• Run new autonomous procedures in shadow mode first Test new gamebooks against prior investigations and known outcomes before enabling sensitive response actions in production.

Key takeaways

• Controlled autonomy is the governing principle that keeps AI agents useful in security operations without letting them improvise past approved boundaries.
• The critical failure is not simply that agents act quickly, but that human review and manual validation arrive after the window where decisive action was needed.
• Security teams need explicit evidence, escalation, and execution boundaries if they want autonomous reasoning without unrestricted operational authority.

Key terms

• Controlled Autonomy: A model in which an automated system can act only within clearly defined boundaries and must escalate when context is incomplete or risk is uncertain. In security operations, controlled autonomy balances machine speed with human accountability and operational safety.
• Gamebook: A Gamebook is a governed investigation procedure that defines intent, evidence requirements, escalation points, and permitted actions. Unlike a fixed playbook, it allows an AI agent to adapt execution while keeping the security outcome, boundaries, and reviewability stable.
• Security Context Graph: A Security Context Graph is a relationship model that connects users, assets, identities, and behaviour so alerts can be judged against known organisational context. It helps investigators distinguish unusual activity from expected operations by adding ownership, access, and workflow information to raw telemetry.
• Flow: Flow is the movement of work through a delivery system with minimal waiting, rework, and handoff friction. In DevOps, good flow means changes move predictably from commit to production, with small batches and short feedback loops that keep risk visible while preserving speed.

Deepen your knowledge

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