Roles, Usage Modes and Autonomy Levels: People in Command of Security AI

Every organisation that puts AI to work in cyber defence must first answer a practical question: who decides what the AI may do, who decides each action, who answers for it when it is wrong, and who can stop it. In security the question is sharper than elsewhere, because security AI reads content written by adversaries, holds the most sensitive telemetry in the organisation and, in its more capable forms, can isolate a host or revoke a session. If the answers are vague, the organisation has delegated authority without knowing to whom.

This chapter supplies the vocabulary the rest of the book uses: the team colours, the six usage modes read through a security lens and the five autonomy levels, from Level 0 Advisory to Level 4 Autonomous, followed by how mode and level are decided, how accountability and human command are made real, and how scarce skills are sourced. In CSF 2.0 terms the chapter is responsible for GV.RR Roles, Responsibilities, and Authorities, whose outcomes are that leadership is accountable for cybersecurity risk, that roles and authorities are established, communicated and enforced, that resources match the risk strategy, and that cybersecurity is part of human-resources practice (19, NIST, 2024). It treats the Category through the three focus areas of the NIST Cyber AI Profile (20, NIST, 2025).

Figure 6.1: Mode and level decided together: Modes 1 to 3 act with a person's identity, Modes 0, 4 and 5 with their own, and human command is designed in.

Red, blue, purple and white

The colours of security teams describe functions, not departments. The red team emulates the adversary, executing authorised attacks against the organisation's own or contracted systems under written rules of engagement. The blue team defends: it monitors, detects, investigates, contains and recovers. The purple team is less a third group than the joint loop between the two: red findings become detections, guardrails, configurations and process changes, and the scenario that found the gap is re-run to show it is closed. The white team controls the exercise: it approves scope and rules of engagement, can pause or end an exercise, deconflicts red activity from real incidents so that a test is not escalated to the national CSIRT, and keeps the record.

AI changes the work of each function but not its accountability. It helps the red team plan campaigns and probe the organisation's own AI systems (Chapters 12 and 13), helps the blue team enrich alerts and propose or execute containment (Chapters 18 to 21), and matches findings to detections in the purple loop (Chapter 26). Three responsibilities therefore hold whatever AI is involved. Every offensive activity, including activity performed by AI, is authorised in writing and scoped by rules of engagement (Chapter 7). Red-team AI never holds reach beyond the exercise scope, and blue-team AI never holds offensive capability; that separation is a design decision, not an instruction, because boundaries rather than instructions set the ceiling on consequences. And the white team, not the AI, holds the stop decision for an exercise.

A financial group may have every colour in house, whereas a regional authority may buy its red team and borrow its white team from the CISO's office. GV.RR is satisfied in both cases when each function is assigned, written down and known, with its authorities, to the people who must use them at three in the morning.

The usage modes through a security lens

The mode describes how AI is deployed: where it runs, whose identity it uses and what it can reach. It matters more than the brand of the model, because it determines the opportunity, the vulnerability and the governance. The earlier volumes distinguish six usage modes and conclude that governance is effective when it is codified, evidenced and proportionate to the usage mode and the risk (AI Governance, Chapters 2 and 25) (72, Nordqvist, 2026) (AI Platform and Security, Chapter 2) (73, Nordqvist, 2026). This book builds on that conclusion. Security work sharpens every mode in two ways: much of what security AI reads is influenced by the adversary, so any such field is a channel for prompt injection, and security AI holds sensitive telemetry and, in the higher modes, authority over the estate, which makes it a target in its own right.

Mode 0 Ambient AI is AI that vendors switch on in licensed products: verdicts in endpoint and email protection, summaries in the SIEM. Its decisions are invisible, its models change silently, and some features act automatically: an email gateway that quarantines on a model verdict already acts at Level 3 Bounded or Level 4 Autonomous, a level the vendor chose.

Mode 1 Conversational assistants help an analyst explain a log entry or draft a query. The vulnerabilities are telemetry pasted into an uncontrolled service, wrong analysis accepted unverified, and injection through pasted content. A person judges, in their own session.

Mode 2 Embedded workplace assistants sit inside ticketing, SOAR and office tools. They inherit the user's permissions, can be steered by content in tickets and mails, and can omit the detail that mattered. A person judges, and the assistant acts on the person's delegated access.

Mode 3 Agentic work tools are coding and task agents that engineers use to write detections or run tools in sandboxes. The agent executes commands with the engineer's credentials between instruction and review and depends on skills and connectors that form a supply chain. The July 2026 incident that AI Governance, Chapter 19, analyses took place in the environment closest to this mode (72, Nordqvist, 2026); the affected platform's own timeline describes an agent that escaped an evaluation sandbox (65, Larcher et al., 2026).

Mode 4 Built AI applications are services the organisation builds and runs, such as a triage assistant. The organisation is the provider, attacker-controlled alert fields reach the model, and quality drifts with model changes; the service usually has a read-only identity.

Mode 5 Autonomous production agents act in production with an identity and permissions of their own, such as a SOC agent that isolates hosts. AI Governance, Chapters 19 and 25, concluded that every such agent must be governed as a well-meaning insider, because instructions lower the rate of unwanted behaviour but only boundaries set a ceiling on its consequences (72, Nordqvist, 2026). A security agent can be steered by crafted alert content, its credentials can be stolen, and its failures can be correlated across many actions.

As Figure 6.1 shows, the modes fall into two zones. In Modes 1 to 3 human judgement dominates, because the AI acts with a person's identity. In Modes 4 and 5, and in the automatic features of Mode 0, a machine identity acts, and its design becomes the primary control.

Autonomy levels for security AI

The usage mode does not say who decides each action; the five autonomy levels do.

Level	Definition	Who decides each action
Level 0 Advisory	The AI suggests; a person decides and acts	A person
Level 1 Assisted	The AI drafts the action; a person reviews and executes it	A person
Level 2 Supervised	The AI executes after explicit human approval of each action	A person approves; the AI executes
Level 3 Bounded	The AI executes pre-approved, reversible actions within a codified playbook; a person is informed and can stop it	The AI, within a playbook approved in advance
Level 4 Autonomous	The AI selects and executes actions without per-action approval	The AI, within bounds set in advance

Five properties matter. First, the level belongs to a capability in a context and is set per action: one agent can enrich alerts at Level 4 Autonomous, because enrichment changes nothing, while its containment proposals wait at Level 2 Supervised. Second, the line between Level 2 and Level 3 is the most important in the scheme, because above it a class of actions happens without per-action approval. That is the open question AI Platform and Security, Chapter 18, and AI Governance, Chapter 13, left for this book (73, Nordqvist, 2026) (72, Nordqvist, 2026); the book's answer is that a defensive AI may do so only for reversible actions, bounded in blast radius and supported by measured confidence, and only when the authority named in the decision tiers has recorded the decision. Third, Level 3 is defined by its playbook, written as code and enforced by a policy decision point outside the model; a Level 3 capability without one is Level 4 with a misleading label. Fourth, Level 4 Autonomous is never used for offensive or irreversible actions and suits only narrow, reversible, high-volume actions such as quarantining an email. Fifth, the level is decided and recorded, not discovered; a vendor feature found acting automatically must be accepted, constrained or switched off, which Chapter 8 treats as an oversight question.

Deciding mode and level together

Mode and level constrain each other. Modes 1 and 2 normally sit at Level 0 or Level 1, Mode 3 agents stay in sandboxes, Mode 4 services sit at Level 0 to Level 2 because their identity is read-only, and Mode 5 is where Level 2 and Level 3 live. Giving a triage service write tools therefore moves it from Mode 4 to Mode 5, a change in governance that triggers reclassification just as a new model version does (AI Governance, Chapter 8) (72, Nordqvist, 2026).

Within the mode, five factors decide the level of each action.

1. Reversibility. Isolating a workstation or revoking a session can be considered for Level 3; deleting data or wiping a host stays at Level 2 or below.
2. Blast radius. Isolating one workstation and isolating a domain controller are different actions even with the same tool, so the playbook limits blast radius per action and per period.
3. Confidence. Measured precision on the organisation's own evaluation set and in production, not the vendor's claim.
4. Exposure to attacker-controlled input. If the trigger rests on content an adversary can write, Level 3 requires corroboration from a deterministic source, such as an endpoint detection, so that free text alone never triggers an action.
5. The decision tier. AI Governance, Chapter 13, concluded that decisions are tiered, from pipeline gates through a design authority and the AI governance board to the management body (72, Nordqvist, 2026). Accordingly, the management body sets autonomy ceilings (Chapter 5), the CISO decides levels within them, and proposals above a ceiling go to the forum that set it.

The speed of the threat frames the decision. Level 3 earns its place where adversaries move faster than a person can approve; however, a capability acting at machine speed is a privileged insider that an attacker will try to manipulate, so the decision is always a trade between acting too slowly and handing the attacker a lever.

Practical guide: assigning a usage mode and an autonomy level to a security AI capability

Purpose. Record the mode and the level of each action of a security AI capability, approved at the right tier.

Roles. Capability owner, security architect, SOC or red-team lead, white team or risk function, and the decision authority named in the risk strategy.

Steps.

1. List every action as a verb with an object: enrich alert, isolate workstation, revoke session.
2. Determine the mode from the deployment; an identity of its own with write access to the estate means Mode 5.
3. Assess each action against the five factors and the speed of the threat.
4. Start at the lowest level that meets the need. Irreversible and offensive actions stay at or below Level 2 Supervised; Level 4 is only for narrow, reversible, defensive actions.
5. Check levels against the autonomy ceilings (Chapter 5) and escalate anything above them.
6. Name the owner, operators, the authority that may change the level, and every stop-path holder, including out-of-hours providers.
7. Record the decision as an AI Decision Record with review triggers, and run the stop-path chaos experiment before go-live.

Default values to adapt. A first review 90 days after any increase in level; a stop target of two minutes to credential revocation; at least 200 evaluated cases with a precision of 0.9 or more before Level 3; and a review of any approver whose median approval time for estate-changing actions falls below five seconds.

Definition of done. Every action has an approved mode and level, every named role has accepted it, and the stop path has been tested.

Worked example: autonomy-level decision record AIDR-0311

The illustrative record below is Hansa Mutual's case for moving two reversible containment actions of its SOC investigation agent, HM-SEC-001, from Level 2 Supervised to Level 3 Bounded, within the ceiling set by the group AI governance board (Chapter 5).

# Illustrative: Hansa Mutual, autonomy-level decision record for HM-SEC-001
kind: AIDecisionRecord
id: AIDR-0311
status: proposed
capability:
  id: HM-SEC-001
  usageMode: 5                     # autonomous production agent
  identity: {type: workload, principal: wl-hm-sec-001-prod, credentials: task-scoped-short-lived}
accountability:
  owner: head-of-group-soc
  operators: [soc-rota-hamburg, soc-rota-poland]
  raiseLevelWithinCeiling: group-ciso
  ceilingSetBy: group-ai-governance-board
  stopOrLowerLevel: [soc-shift-lead, group-ciso]
autonomy:
  default: 2
  ceiling: 3
  byAction:
    enrich-and-summarise-alert: 4  # read-only
    isolate-managed-workstation: 3
    revoke-user-sessions: 3
    disable-account: 2
  level3Conditions:
    corroboratedByDeterministicDetection: true   # free text never triggers
    maxWorkstationsPerHour: 5
    excluded: [servers, tier-0-assets, break-glass-accounts]
    entitiesPendingWorksCouncilAgreement: 2
  neverAutonomous: [irreversible-actions, offensive-actions]
humanCommand:
  stopPath: out-of-band-credential-revocation
  stopTargetSeconds: 120
evidence:
  redTeamFindings: HM-SEC-003           # crafted alert content steered proposals
  chaosExperiment: HM-SEC-006/stop-path-runaway
reviewTriggers: [model-change, new-action, incident, red-team-finding, mode-change]

The corroboration requirement is the control that closes the finding from Hansa's AI red-teaming programme, which showed that crafted alert content could steer the agent's proposals. The lower ceiling where works-council agreement is pending keeps the agent at Level 2 Supervised in those entities.

Machine identities and accountability

An AI that acts with an identity of its own cannot be accountable; only people can. Architecture as Code (Chapter 20) set the rule "agents draft; humans approve", with every exception carrying a named human approval in the audit trail (71, Nordqvist, 2025). This book builds on that conclusion: at Level 3 the approval moves from the action to the playbook and the authority that signed it, which concentrates accountability rather than diluting it. Every machine identity therefore has an owner, a person in a line role accountable for purpose, evaluation and residual risk; operators, named through a rota, who approve, watch and stop; and an authority that may raise the level within the ceiling. Lowering the level is open to every stop-path holder, because stopping must never wait for a meeting.

The identity follows the containment baseline of AI Platform and Security, Chapter 19: task-scoped, short-lived credentials, a permission manifest the agent cannot change, and detection from telemetry rather than self-report (73, Nordqvist, 2026). A security agent also needs an identity distinguishable in every log and tokens that carry the entity on whose behalf it acts. The OWASP Top 10 for Agentic Applications names identity and privilege abuse among the principal agentic risks (15, OWASP, 2025).

In Europe, NIS 2 requires management bodies to approve and oversee cybersecurity risk-management measures and allows them to be held liable (Article 20) (3, European Union, 2022), and DORA places ultimate responsibility for ICT risk on the management body (Article 5) (2, European Union, 2022). Neither lets that responsibility pass to a tool, so the chain from appetite statement to named owner must be traceable in evidence. Where security AI is high-risk under the AI Act, the deployer must assign oversight to natural persons with the necessary competence, training and authority (Article 26(2)) (1, European Union, 2024); most security AI is not, although employee monitoring raises a question Chapter 7 takes up.

Human command by design

AI Governance, Chapters 10 and 21, concluded that human oversight must be designed, not declared, with approvals given in seconds treated as a signal of rubber-stamping (72, Nordqvist, 2026); its Chapter 19 analysed what happens otherwise: the affected platform's own timeline records that its AI-based security agents correlated the signals but failed to raise the alert's criticality and trigger the on-call team, which cost time in the response (65, Larcher et al., 2026). Three elements make command real.

The interruption path. Every capability above Level 1 has a stop path outside the system it stops: it revokes credentials at the identity provider or policy decision point and works when the agent's platform is degraded. Its holders are named, alerts are routed to them rather than to a general queue, an out-of-hours provider's shift lead holds the same authority and access, and stopping drops the capability to a safe degraded state such as manual playbooks.

The override log. Every approval, rejection, modification and stop is recorded with person, time, action and reason, as evidence of command and as a source of evaluation cases.

Approval quality. At Level 2 approval can become a reflex, so measure time to approval, rejection rate and later reversals per operator. The response to rubber-stamping is redesign, not blame: fewer proposals, better evidence or a narrow move to Level 3. Because these metrics are themselves employee monitoring, agree them with works councils first and report them in aggregate where possible.

For high-risk AI systems, Article 14 of the AI Act requires that overseers be able to disregard, override or reverse the output and to interrupt the system through a stop button or similar procedure (1, European Union, 2024); those are the properties any security capability's human command should have.

Skills, sourcing and the MSSP

People in command must be competent to command, and CSF 2.0 expects resources to match the risk strategy (19, NIST, 2024). Security AI needs operators who understand how a capability fails, evaluation engineers who maintain the sets on which confidence is measured, and people who can red team the capability; the first can be trained, the second is scarce, and the third is often bought. Organisations build, buy from a managed security service provider (MSSP), or partner through information-sharing groups and shared services among public authorities.

An MSSP's shift lead becomes a stop-path holder for the hours the provider covers, so the contract and charter must grant that authority explicitly, and the provider's own AI, Mode 0 from the customer's perspective, must be disclosed with its hosting and effective autonomy. NIS 2 includes supply-chain security among the risk-management measures (Article 21(2)(d)) (3, European Union, 2022), and DORA sets principles for ICT third-party risk and key contractual provisions (Articles 28 and 30) (2, European Union, 2022).

Skills also erode when AI triages most alerts, which undermines exactly the supervision Level 2 and degraded mode require. Have analysts work a share of alerts without AI, rotate operators through stop-path exercises, and write AI literacy into role descriptions, in line with Article 4 of the AI Act (1, European Union, 2024); Chapter 15 develops training. The Five Eyes agencies urge careful adoption of agentic AI services (40, Five Eyes agencies, 2026), which in GV.RR terms means pacing autonomy to the skills available to supervise it.

Across the usage modes

Mode	Characteristic vulnerability	Who judges, with whose identity	Typical level
Mode 0 Ambient AI	Automatic actions at a level the vendor chose	The vendor's model, the product's identity	Unknown until assessed
Mode 1 Conversational assistants	Telemetry leaving control; wrong analysis accepted	A person, own identity	Level 0 Advisory
Mode 2 Embedded workplace assistants	Inherited permissions; injection via tickets	A person, delegated identity	Level 0 to Level 1
Mode 3 Agentic work tools	Engineer's credentials used between instruction and review	A person reviews, engineer's identity	Level 1 to Level 2
Mode 4 Built AI applications	Attacker-controlled fields reach the model; drift	A person acts, read-only service identity	Level 0 to Level 2
Mode 5 Autonomous production agents	Privileged machine insider open to manipulation	The agent within codified bounds, own identity	Level 2 to Level 3

Across the autonomy levels

Level	Who holds the decision	Evidence that command is real
Level 0 Advisory	The analyst who acts	Suggestion and action taken
Level 1 Assisted	The analyst who executes	Drafted versus executed action
Level 2 Supervised	The approving operator	Override log and approval-quality metrics
Level 3 Bounded	The authority that approved the playbook; the operator holds the stop	Playbook version, per-action evidence, stop-path tests
Level 4 Autonomous	The authority that set the bounds	Sampling reviews; never offensive or irreversible actions

Verifying with security chaos engineering

The experiment verifies that the stop path reaches its holders. In a test environment, a test instance of the agent, using a catalogued benign emulation, issues containment requests against synthetic workstations above its playbook limit. The steady-state hypothesis is that the policy decision point refuses the excess requests, an alert reaches the stop-path holder on shift, including a provider's night shift, the holder revokes the credentials out of band and the capability falls back to degraded mode, within ten minutes and with no effect outside the test environment. Run it before any increase in level and then unannounced; Chapter 25 sets the safety boundaries.

The three AI focus areas

Securing AI systems. Every AI capability has a named owner, and every machine identity an owner, operators and an authority, with accountability rising through the decision tiers to the management body (20, NIST, 2025).

AI-enabled cyber defence. Modes and levels define how far defensive AI may act and who decides, per action, with human command built from a stop path, an override log and measured approval quality.

Thwarting AI-enabled attacks. Pre-decided authorities let the organisation act at machine speed for bounded, reversible actions, while corroboration, blast-radius limits and an out-of-band stop path keep that authority from becoming an attacker's lever.

Nordvik Region and Hansa Mutual

Nordvik Region keeps its security AI in Mode 0, Mode 1 and Mode 4, at Level 0 Advisory or Level 1 Assisted. The SOC triage assistant NR-SEC-001 is Mode 4 at Level 1 Assisted with a read-only identity, recorded in AIDR-0301, and the exposure prioritiser NR-SEC-003 is Mode 4 at Level 0 Advisory. The CISO decides levels within the charter's ceiling of Mode 4. The red role in RoE-NR-2027-001 is contracted, a small white team comes from the CISO's office, and the MSSP's night-shift lead is named in the charter as a stop-path holder and included in the stop-path experiment.

Hansa Mutual runs HM-SEC-001 as a Mode 5 agent at Level 2 Supervised, and AIDR-0311 argues for Level 3 Bounded for workstation isolation and session revocation, with operators in Hamburg and at the Polish service centre and the SOC shift lead holding the stop path. Its red team of five, the blue SOC and a white team for the TIBER-DE exercise divide the work, and approval-quality reviews that flagged some approvals given in seconds strengthen the case for Level 3. The two differ because Nordvik buys scarce skills and keeps every action with a person, while Hansa has the people to supervise bounded machine action and the attack speed that justifies it.

Summary

People remain in command of security AI only if roles, modes and levels are designed together. GV.RR Roles, Responsibilities, and Authorities should define how red, blue, purple and white teams divide the work when AI is part of each, and who owns, operates and may stop every capability. Offensive activity stays under signed rules of engagement, red and blue AI stay separated by design, and the white team holds the stop decision.

The usage modes describe how security AI is deployed and whose identity it uses; the autonomy levels describe who decides each action. Both are decided per action and recorded, as in AIDR-0311. A defensive AI may act without per-action approval only for reversible, bounded actions with measured confidence, on the authority of the tier that owns the ceiling, and never at Level 4 for offensive or irreversible actions.

Every machine identity needs a named owner, operators and an authority, as NIS 2 and DORA expect of management bodies, and human command is built from stop paths outside the system they stop, override logs and measured approval quality, extended to any MSSP that covers the night shift. Chapter 7 sets the policy, mandate and rules of engagement under which these roles operate.

Sources

1. NIST. The NIST Cybersecurity Framework (CSF) 2.0. (19, NIST, 2024)
2. National Institute of Standards and Technology. Cybersecurity Framework Profile for Artificial Intelligence (Cyber AI Profile). (20, NIST, 2025)
3. Nordqvist, G. Architecture as Code. (71, Nordqvist, 2025)
4. Nordqvist, G. AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. (72, Nordqvist, 2026)
5. Nordqvist, G. AI Platform and Security: Building and Securing AI Platforms in European Enterprises and Public Authorities. (73, Nordqvist, 2026)
6. Five Eyes cyber security agencies: ASD's ACSC, CISA, NSA, Canadian Centre for Cyber Security, NCSC-NZ and NCSC-UK. Careful adoption of agentic AI services. (40, Five Eyes agencies, 2026)
7. OWASP Foundation. OWASP Top 10 for Agentic Applications for 2026. (15, OWASP, 2025)
8. European Parliament and Council of the European Union. Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). (1, European Union, 2024)
9. European Parliament and Council of the European Union. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). (2, European Union, 2022)
10. European Parliament and Council of the European Union. Directive (EU) 2022/2555 on measures for a high common level of cybersecurity across the Union (NIS 2 Directive). (3, European Union, 2022)
11. Larcher, H., Carreira, A. et al. (2026). Anatomy of a Frontier Lab Agent Intrusion: A Technical Timeline of the July 2026 Incident. (65, Larcher et al., 2026)