ISO/IEC 42001 and Agentic Cyber Defense — Governing AI Agents Before They Govern the Network
Security teams are experiencing a structural shift in how automated defense operates. For years, defensive automation was largely deterministic: static scripts, rule-based correlation engines and predefined playbooks triggered by explicit alerts. When machine learning entered the security operations centre (SOC), it acted primarily as an assistive tool—flagging anomalies, clustering alerts or summarising forensic context for a human analyst to review.
Today, that boundary is shifting. Defensive AI systems are being designed not merely to observe, but to act. They parse unstructured threat intelligence, query internal asset inventories, conduct multi-stage investigations across telemetry sources, formulate remediation strategies and, in some architectures, execute containment actions directly inside production infrastructure.
Consider the contrast between workflows:
This evolution leads directly to an operational and architectural question:
At what point does an AI assistant become an autonomous security actor — and who governs its decisions?
The central thesis of this Practitioner Note is straightforward:
The more authority an organisation delegates to defensive AI, the more important explicit governance, accountability and operational boundaries become.
Agentic cyber defense is not only a cybersecurity architecture problem. It is also an AI governance problem. When an AI system can query sensitive telemetry, evaluate adversary intent and modify network or identity state, its operation can no longer be addressed solely through traditional security tooling. It requires an organisational management system capable of governing AI risk, operational authority and human accountability.
What changes when defensive AI becomes agentic?
To discuss governance productively, security leaders and auditors must avoid treating all "AI in security" as a single uniform capability. An AI summarising a CVE report creates vastly different operational risks than an AI agent authorized to isolate domain controllers or modify firewall rules.
At ShadowThreats, we use an illustrative practitioner model to distinguish levels of defensive autonomy.
Assisting Analysis Without Environmental Modification
The AI system reads threat intelligence feeds, summarises security advisories, clusters alerts, correlates known vulnerabilities against patch databases and creates investigation tickets for human analysts.
Active Investigation and Containment Recommendations
The AI system queries approved internal systems, executes structured threat hunts across telemetry stores, correlates external threat intelligence with internal asset graphs and drafts specific containment or remediation actions.
Direct Modification of Enterprise Security State
The AI system is empowered to execute state-changing actions: disabling user or service accounts, isolating endpoints from the corporate network, altering production firewall or EDR rules, rotating compromised credentials or terminating running processes.
The AI system is no longer merely analysing security when it can change the security state of the organisation.
Autonomy is not the same as risk
A frequent misunderstanding in emerging AI discussions is equating autonomy directly with risk. Autonomy is only one dimension of an AI system's risk profile.
A fully autonomous AI agent operating inside an isolated, synthetic malware analysis sandbox may possess high autonomy within its domain, but create negligible organizational risk. Conversely, an agent with low autonomy that summarizes unverified darknet intelligence directly into executive risk dashboards—or an agent with medium autonomy that holds read-only API access to every employee email mailbox—creates significant confidentiality, integrity and legal exposure.
In practice, assessing risk for agentic cyber defense requires examining multiple interacting dimensions:
This multidimensional profile illustrates why AI risk must be evaluated in its full operational context. It is not an ISO-prescribed scoring formula, but an engineering reality: risk is a function of privilege, consequence, reversibility and data exposure, not degree of autonomy alone.
The defensive autonomy paradox
Organisations deploying agentic cyber defense face two competing risks.
Too little autonomy may leave defensive systems unable to react at the speed of machine-assisted or autonomous attacks. When malicious actors automate discovery, credential harvesting and lateral movement within seconds, relying strictly on manual human escalation creates unavoidable operational bottlenecks. By the time a human analyst reviews an alert, triage tickets are approved and containment is authorised, an adversary may have already established deep persistence or exfiltrated key assets.
Too much autonomy may allow an AI system to cause significant operational disruption through an incorrect decision. An autonomous defense agent that misinterprets legitimate systems maintenance or unusual batch processing as an active adversary and executes immediate network isolation can halt critical business workflows faster and more severely than the attacker would have.
The governance challenge is therefore not to eliminate autonomy, but to determine which decisions may safely be delegated, under which conditions, and with which safeguards.
- Slow response
- Delayed containment
- Human bottlenecks
- Attack propagation
- Missed machine-speed response window
- Risk-based authority
- Confidence thresholds
- Asset criticality
- Reversibility
- Human escalation
- Technical guardrails
- Logging
- Kill switch
- Testing
- False containment
- Service disruption
- Privilege misuse
- Cascading operational impact
- Unsafe automated remediation
The objective is not maximum autonomy. It is sufficient autonomy within defensible boundaries.
Security leadership must recognize that doing nothing is itself a risk decision. Requiring manual approval for every action may appear superficially conservative, but can itself create immense operational risk if the resulting response is too slow to stop a rapidly propagating intrusion.
“In an enterprise IT operations role, I have personally had to make decisions around isolating domain controllers during incident triage.
Decisions of that kind are not theoretical. They are made under significant time pressure and with incomplete information, while both acting and not acting can have major consequences for the organisation.
Isolating critical identity infrastructure may help contain an incident, but it can also affect authentication, dependent services and business continuity.
That experience is one reason I find the governance of defensive AI so important. An AI agent may eventually be required to make or recommend the same kinds of decisions — but at machine speed.”
Where ISO/IEC 42001 enters the picture
Published in December 2023, ISO/IEC 42001 is the international standard specifying requirements for establishing, implementing, maintaining and continually improving an Artificial Intelligence Management System (AIMS).
To understand its relevance to agentic cyber defense, one must understand the relationship between the organisation, the management system and the individual AI tools:
An AI agent is a system. An AIMS governs how the organisation manages AI systems.
This distinction is vital for practitioners and auditors alike. Individual AI models or defensive agents do not get "ISO 42001 certified." Certification applies to an organisation's management system.
Through an AIMS, an organisation establishes a repeatable, auditable framework addressing:
- AI policies and objectives: Clear executive intent regarding responsible, reliable and lawful AI use.
- Roles and responsibilities: Unambiguous accountability for AI system design, operation and outcomes.
- AI risk and opportunity management: Structured identification and treatment of AI-specific risks.
- Lifecycle governance: Requirements covering conception, data selection, testing, deployment, operational maintenance and decommissioning.
- Operational controls: Safeguards addressing data quality, transparency, traceability and system robustness.
- Monitoring and performance evaluation: Continual tracking of whether AI systems meet their intended purpose and remain within safe boundaries.
- Nonconformity and corrective action: Systematic response when an AI system produces unexpected outcomes or fails to meet requirements.
What should an AIMS govern for a defense agent?
When applying an AIMS to an autonomous or semi-autonomous defensive agent, governance must translate into concrete operational parameters. In a practical deployment, twelve core governance dimensions require explicit definition:
What is the agent intended to do? What are its explicit operational boundaries, intended outcomes and out-of-scope tasks?
Who is the accountable human owner for the agent and its operational decisions across engineering, security operations and risk management?
Which specific actions may the agent perform autonomously? Which actions require human approval? Which actions are strictly prohibited?
Which APIs, telemetry stores, endpoints, identity providers and tools may the agent query or invoke, adhering to least privilege?
Which decision gates require human authorization before execution? What escalation paths exist if an action exceeds predefined risk parameters?
How do confidence scores, asset criticality and potential business disruption condition permitted actions? At what confidence level does automated action stop?
Can the organisation reconstruct what data the agent observed, the intermediate reasoning steps it followed and the exact tool calls it executed?
How are model updates, system prompt revisions, tool capability expansions, policy alterations and infrastructure integrations reviewed and tested?
How are unexpected behaviour, hallucinations, performance degradation, data drift and false-positive escalation spikes detected and flagged in production?
What procedures apply if the defensive AI causes an operational outage, blocks critical business services or misinterprets legitimate administration as an attack?
Is there a reliable kill-switch to revoke privileges, isolate the agent and revert to human manual operation without compromising fundamental visibility?
Does management regularly re-evaluate whether the agent's granted authority remains appropriate given changing enterprise architecture and threat landscape?
The autonomy boundary
AI governance becomes operational when an organisation translates abstract principles of oversight into explicit authorization boundaries.
Below is an illustrative practitioner matrix demonstrating how an enterprise might separate autonomous actions, actions requiring explicit human confirmation, and prohibited actions:
| Defensive Action | Autonomous | Approval Required | Prohibited |
|---|---|---|---|
| Read external threat intelligence | ✓ | — | — |
| Correlate with asset inventory | ✓ | — | — |
| Query approved internal telemetry logs | ✓ | — | — |
| Create investigation ticket | ✓ | — | — |
| Recommend endpoint isolation | ✓ | — | — |
| Isolate production endpoint | — | ✓ | — |
| Disable privileged user account | — | ✓ | — |
| Change production firewall policy | — | ✓ | — |
| Destroy business data or purge databases | — | — | ✓ |
This matrix is illustrative. Different organisations will define different boundaries based on system criticality, operational maturity, regulatory demands, control reversibility and risk appetite.
AI governance becomes operational when an organisation explicitly defines what an agent may observe, investigate, recommend and execute.
- Read threat intelligence feeds
- Query approved internal logs and telemetry
- Correlate indicators against asset inventories
- Create investigation tickets and triage notes
- Increase telemetry collection on suspected hosts
- Initiate automated sandbox detonation of files
Permitted only where confidence threshold is met, predefined asset class matches, action is immediately reversible, and policy explicitly permits:
- Initiate predefined threat hunt playbooks
- Invalidate low-impact non-privileged user sessions
- Apply temporary reversible endpoint containment
- Increase endpoint telemetry logging level
- Disable privileged administrative identity
- Isolate critical production server or core banking node
- Modify production firewall or routing policies
- Stop critical business application services
- Destroy production business data
- Delete or modify immutable backups
- Disable disaster recovery or failover controls
- Remove security logging or safety mechanisms
- Expand its own administrative privileges or credentials
This model demonstrates how abstract governance principles translate into operational boundaries. Crucially, the AIMS does not determine the correct autonomy level for every defense agent. It provides the management framework through which the organisation can make, document, implement, test and continually review those boundaries.
Agentic defense in financial services
The autonomy paradox becomes especially acute in banking, insurance and market infrastructure. Under the European Union's Digital Operational Resilience Act (Regulation (EU) 2022/2554, DORA), financial entities are subject to harmonised rules governing ICT risk management, incident reporting, digital operational resilience testing and third-party ICT service provider oversight.
Under Article 5 of DORA, the management body of a financial entity bears ultimate responsibility for managing the entity's ICT risk and is required to define, approve, oversee and be accountable for the implementation of the ICT risk-management framework. This governance obligation cannot simply be delegated to an AI system, an algorithmic model or a third-party technology provider.
Consider how the defensive dilemma manifests during an active intrusion:
Agent alerts the on-call security analyst and awaits explicit authorization before revoking session tokens or disabling the account.
Agent autonomously revokes tokens and isolates the administrative identity across the enterprise directory.
This dilemma cannot be solved by technical algorithms alone. It requires intentional organizational alignment across risk tolerance, asset criticality, operational resilience thresholds, business continuity requirements, reversibility safeguards, audit logging and executive accountability.
For a regulated financial entity, the important question is not whether the decision was made by a human or an AI in isolation. The organisation must be able to explain why that decision authority existed, how it was controlled and how ICT risk remained governed.
Furthermore, where financial entities evaluate NIS2 (Directive (EU) 2022/2555), the regulatory interplay must be analysed carefully. While Articles 20 and 21 of NIS2 place duties on management bodies of essential and important entities to approve and oversee cybersecurity risk-management measures, DORA acts as lex specialis for in-scope financial entities pursuant to Article 4 of NIS2. A regulated bank or insurer does not simply stack duplicate frameworks; it must evaluate how sector-specific obligations govern automated cybersecurity mechanisms.
When agentic defense protects critical infrastructure
The consequences of an incorrect defensive action escalate drastically when defensive AI interacts with critical infrastructure—such as electrical grids, municipal water distribution, transportation signalling or critical digital backbones.
In these operational technology (OT) and industrial control system (ICS) environments, the primary operational imperative is frequently availability and physical safety rather than confidentiality. An automated defense agent that abruptly isolates an industrial controller or terminates an operational telemetry process because it observed anomalous communication patterns can trigger a turbine shutdown, water pressure loss or grid instability.
Consider the practical contrast in an electricity utility:
AI detects suspicious probe against SCADA gateway; autonomously increases logging verbosity, initiates deep packet capture and flags ticket for priority engineering review. Zero disruption to electricity delivery.
AI observes lateral movement signature; autonomously severs network connection between substation control and central dispatch. Substation loses telemetry, fails safe or initiates regional power trip.
This operational reality connects directly to European regulatory considerations. A crucial distinction must be maintained under the European Union AI Act (Regulation (EU) 2024/1689):
The fact that an AI system operates inside critical infrastructure does not by itself determine its AI Act classification. Intended purpose and function matter.
Under Annex III point 2 of the AI Act, AI systems intended to be used as safety components in the management and operation of critical digital infrastructure, road traffic, or the supply of water, gas, heating or electricity are classified as high risk. However, systems intended solely for cybersecurity purposes do not automatically qualify as safety components merely because they protect an entity operating critical infrastructure. If an AI agent does not control physical safety actuators or directly govern critical operational loops, it is not automatically swept into Annex III high-risk classification.
Regardless of formal legal categorization, the governance challenge remains identical: How much operational authority should defensive AI receive when both cyberattack propagation and defensive misaction can disrupt essential societal services?
Who is accountable when the agent acts?
When an autonomous defensive agent takes an action that leads to significant business downtime, data loss or regulatory scrutiny, the fundamental question arises: Who is legally and organizationally accountable?
Security and risk executives must avoid seeking a single, simplistic scapegoat. Accountability in agentic systems is inherently multi-layered:
| Governance Question | Possible Responsibility Layer |
|---|---|
| Who authorised the AI use? | Organisation / management governance |
| Who defined its authority? | Organisation / system owner |
| Who operates the system? | Deployer / operating organisation |
| Who developed the product? | Provider / manufacturer |
| Was the product defective? | Product-liability analysis |
| Was personal data involved? | GDPR controller / processor roles |
| Was a regulatory duty breached? | Applicable sector regulation (e.g. DORA, NIS2) |
| Was a contract breached? | Contractual allocation of responsibility |
Two overarching legal and governance principles govern this landscape:
Responsibility does not disappear because the immediate decision was generated by an AI agent.
Delegating execution to software does not relieve an organisation of its statutory, regulatory or contractual duties. An enterprise cannot defend an unnotified breach or an unlawful outage by asserting that "the agent decided on its own."
At the same time, practitioners must understand the critical distinction: Accountability ≠ Automatic Liability.
Assigning organisational accountability under DORA or NIS2 means the management body is responsible for ensuring an adequate governance and risk framework exists. It does not mean that individual board members or security leaders automatically incur personal civil liability whenever a security tool or agent experiences an unexpected operational failure. Civil and corporate liability depends on national company law, standards of fault, negligence, and contractual limitation of liability.
Liability cannot be determined from the technology alone. It depends on the legal role of each actor, the applicable regulatory framework, contractual arrangements, the system’s intended purpose and the facts of the individual case.
The defense agent is itself part of the attack surface
When an AI agent is integrated into security operations with privileged access to query logs, inspect infrastructure and execute containment, it inevitably becomes an attractive target for adversaries.
Security teams must recognize that the defensive AI system inherits novel attack surfaces that standard security software does not face:
- Manipulated threat intelligence: Adversaries deliberately publishing misleading feeds, indicators or advisories engineered to cause defensive AI agents to misallocate resources or take disruptive actions against benign infrastructure.
- Poisoned contextual data: Inserting malicious content into ticket systems, commit messages, DNS records or user descriptions designed to mislead correlation algorithms.
- Indirect prompt injection: Embedding adversarial instructions inside web pages, log entries, email headers or external advisories ingested by the agent during investigation, causing it to bypass internal guidelines or disclose confidential context.
- Attacker-controlled log inputs: Crafting telemetry payloads that exploit parsing logic or prompt templates when interpreted by foundation models.
- Compromised API tools and MCP servers: Exploiting tool endpoints or model-context-protocol interfaces to induce unintended tool invocations or exfiltrate session data.
- Excessive privileges and credential leakage: Granting agents overly broad tokens or administrative service accounts that can be abused if reasoning fails or prompts are hijacked.
- Unsafe automated execution: Allowing dynamic execution of AI-generated scripts without sandbox verification or deterministic syntax checking.
A defense agent capable of changing the environment becomes part of the attack surface it is supposed to protect.
This is why AI governance and information security cannot be managed in silos. The AIMS (ISO/IEC 42001) must work hand-in-hand with the Information Security Management System (ISMS // ISO/IEC 27001). The ISMS secures the infrastructure, credentials and APIs that host the agent; the AIMS governs the trustworthiness, lifecycle, authority and accountability of the agent itself.
AIMS as the governance layer
A useful way to visualize the integration of AI governance into technical operations is as a governing layer surrounding the active components of the AI system:
The AIMS does not defend the network. It governs the organisation that designs, deploys and operates the AI that does.
Operational resilience and fallback: When defensive AI fails
In traditional cybersecurity engineering, defensive capabilities have often been evaluated on a single binary metric: Did the control stop or mitigate the attack?
In agentic cyber defense, that single-dimensional evaluation is dangerously incomplete. A resilient architecture must evaluate two distinct operational questions:
- Can the defensive agent effectively identify and contain the adversary?
- Can the organisation continue operating if the agent makes the wrong decision?
A defensive action that successfully contains an attacker but unnecessarily stops a critical business service may still represent a serious operational failure.
From a cyber-resilience perspective, granting operational authority to defensive AI requires robust, pre-engineered fallback and recovery mechanisms:
- Deterministic rollback: Every automated action must have a rapid, predictable reversal procedure. If an agent isolates a server, revokes a service token or modifies a firewall rule, security operations must be able to restore the previous known-good state with a single tested procedure.
- Manual fallback pathways: If the defensive AI experiences degraded reasoning, prompt injection, or token exhaustion, operational control must immediately and gracefully revert to human analysts without losing telemetry visibility.
- Alternate administration and break-glass access: If an agent modifies identity permissions or enterprise directory configurations, emergency out-of-band administration paths must remain completely isolated from the agent's reach.
- Domain and network segregation: Agents operating within enterprise office IT environments must be strictly segmented from critical production workloads or operational technology networks to prevent runaway automated containment cascades.
- Failure-injection testing: Before an agent is granted operational autonomy, the organisation should execute simulated failure exercises to test whether human operators can detect, override and remediate an erratic or hallucinated containment action.
Does ISO/IEC 42001 make agentic defense regulatory compliant?
The short answer is: No.
Holding an ISO/IEC 42001 certificate does not provide an automatic pass or immunity from legal obligations. ISO/IEC 42001 is a voluntary international management-system standard, not a statutory regulation.
What ISO/IEC 42001 does provide is a structured, defensible organizational framework. It enables an enterprise to:
- Systematically identify applicable legal, statutory and contractual AI requirements.
- Assign clear internal ownership and accountability for compliance.
- Establish operational controls that produce demonstrable audit evidence.
- Continuously monitor AI risks and adapt when operational environments or laws change.
The EU AI Act Context
A common question among European practitioners is whether autonomous cybersecurity agents constitute "high-risk AI systems" under the European Union AI Act (Regulation (EU) 2024/1689).
It is critical to note: an agentic cyber-defense system is not automatically classified as high-risk AI under the EU AI Act simply because it is autonomous or operates in cybersecurity.
Classification under the EU AI Act depends strictly on the system's intended purpose, whether it forms a safety component of a regulated product under Annex I, or whether it falls under the specific high-risk use cases listed in Annex III (such as critical infrastructure safety components, biometrics, employment or law enforcement). Many internal SOC assistance and autonomous correlation systems will not fall into Annex III, while systems controlling critical infrastructure industrial control processes may require careful legal evaluation.
Nevertheless, the governance disciplines required by ISO/IEC 42001 align closely with the core principles of modern AI legislation:
An organisation operating a mature AIMS will find itself in a significantly stronger position to demonstrate regulatory readiness than one attempting to document governance ad hoc.
ISO/IEC 42005: Assessing the impact of a specific AI system
While ISO/IEC 42001 establishes the organisational management-system framework for governing AI, ISO/IEC 42005 provides guidance for conducting impact assessments of specific AI systems and their foreseeable applications.
These assessments help organisations identify, evaluate and document potential impacts on individuals, groups and society throughout the AI system lifecycle.
For a defensive AI agent, an impact assessment can help examine who or what may be affected by the system's decisions, what consequences may result from incorrect or unintended actions, and which safeguards and oversight mechanisms may be appropriate.
This relationship is conceptual. It does not imply that ISO/IEC 42005 is mandatory for every AI system or every ISO/IEC 42001 implementation, nor does it replace broader AI risk management. Rather, it offers a structured approach when evaluating how a particular system affects its environment and stakeholders.
When conducting an impact assessment for a defensive security agent, relevant inquiries include:
- Decision scope: What decisions can the agent influence or execute directly?
- Affected stakeholders and entities: Which individuals, employee groups, business functions, customers or external parties may be affected by its actions?
- Failure consequences: What could happen if the agent makes an incorrect decision, acts on manipulated telemetry, or misidentifies legitimate operations as an intrusion?
- Reversibility: How reversible are its actions if an unintended operational or stakeholder impact occurs?
- Impact-amplifying dependencies: Which external model integrations, third-party threat feeds or tool permissions could amplify an adverse impact?
- Monitoring and impact evidence: What monitoring, telemetry and documentation are needed to detect, understand and review resulting impacts throughout the agent's lifecycle?
ISO/IEC 42005 is guidance rather than an automatic certification requirement. Whether and how an organisation applies it depends on its governance framework, applicable requirements and the context of the AI system.
Why autonomy also matters for AIMS audit complexity
From an audit and certification perspective, an organisation's AI activities directly determine the scope and depth of audit planning. This is where ISO/IEC 42006 enters the landscape.
ISO/IEC 42006 defines requirements for bodies providing audit and certification of AI management systems. Under accredited certification schemes, an audit team cannot treat every organisation identically. Audit planning and audit-time calculations must reflect the context and complexity of the organisation's AI use cases.
Conceptually, audit complexity reflects an interacting set of organizational factors:
The same characteristics that make an AI environment more difficult to govern may also increase the complexity of auditing the AIMS around it.
When an organisation introduces agents that can autonomously investigate, configure or modify infrastructure, the evidence needed to verify that controls are effective inevitably becomes more technical and extensive. Audit-time determination and certification body requirements under ISO/IEC 42006 are a substantial topic that justifies a dedicated future Practitioner Note.
What might good governance evidence look like?
From a practical audit perspective, an AI policy alone tells me very little about how an autonomous system is actually governed.
Any organization can draft a policy declaring that "AI shall be used responsibly and under human oversight." In an audit, what matters is whether the organization can demonstrate a traceable lifecycle connecting purpose, risk, authorization, execution and oversight.
Useful audit evidence for agentic defense includes:
- AI use-case inventory: Register of all active models, agents, autonomous playbooks and copilot integrations.
- Documented purpose and ownership: Explicit statements of what the agent is authorized to do and who owns the operational outcome.
- AI risk assessments: Documented analysis of hallucination risk, prompt injection, tool misuse and business disruption.
- Autonomy and authority matrix: Evidence of which actions are automated, which require approval, and which are prohibited.
- Access control records: Proof that the agent operates under least-privilege service principals with restricted token lifetimes.
- Human-approval logs: Audit trails verifying that high-impact containment actions were approved by human analysts before execution.
- Pre-deployment testing records: Benchmark evaluations, red-teaming against prompt injections and false-positive assessments.
- Operational logs: Immutable logs capturing ingested threat data, intermediate tool calls, reasoning steps and final actions.
- Change records: Version-controlled updates to model weights, system prompts, tool schemas and environmental integrations.
- Incident and anomaly records: Evidence showing how unintended actions or degraded reasoning were investigated and remediated.
- Management review: Documented management review confirming that autonomous capabilities remain aligned with business risk appetite.
A useful audit trail connects the intended purpose of the agent with its risks, permitted actions, controls, monitoring and evidence of review.
Human oversight is not binary
In debates about artificial intelligence, "human in the loop" is frequently presented as a simple on/off switch. In high-speed cyber defense, this binary framing fails. If every single telemetry query or correlation required a manual button-press, the security operations team would drown in alert fatigue while autonomous adversaries operate in seconds.
Mature AI governance models recognize that oversight must be graduated across the analytical and operational lifecycle:
The agent operates independently within approved read boundaries. It parses threat intelligence, monitors feeds and structures incoming telemetry without human gating.
The agent executes read-only queries across SIEM, EDR and asset inventories, correlating indicators and gathering context autonomously according to defined investigation plans.
The agent synthesizes forensic findings, assesses confidence, formulates containment strategies and presents structured recommendations with transparent reasoning to human responders.
Execution depends on consequence, reversibility, confidence and policy. Low-impact actions (e.g. initiating a sandbox detonation) may be pre-authorized; high-impact actions (e.g. isolating critical infrastructure or revoking active credentials) require explicit human approval.
Human oversight does not require that every analytical step is manually confirmed. It requires that the organisation intentionally chooses where human authority is required, ensures analysts have sufficient context to make informed decisions, and maintains the technical capability to intervene, override or abort agent operations.
Conclusion
As offensive threat systems accelerate toward autonomy, defensive operations will inevitably integrate more capable AI agents. Handing operational tasks to defensive AI is a natural technical response to machine-speed adversaries.
Yet the defensive autonomy paradox demonstrates that evaluating agentic defense cannot be reduced to simplistic extremes. The risk equation is neither "AI autonomy is bad" nor "more automation is always better."
Instead, determining appropriate defensive authority is a multi-dimensional calculation:
The governance challenge is not choosing between humans and autonomous defense. It is deciding which authority can safely move from humans to machines, under which conditions, with what evidence and with whom remaining accountable.
Granting AI agents authority over enterprise environments introduces fundamental governance obligations:
- Greater operational authority makes explicit governance, monitoring and change control essential.
- Autonomy alone is not a complete risk assessment; privilege, data sensitivity, consequence and reversibility determine exposure.
- An AI Management System (ISO/IEC 42001) provides the organizational scaffolding to govern AI systems systematically.
- Governance requires clear operational boundaries that define what an agent may observe, investigate, recommend and execute.
- Privileged defensive agents must themselves be secured as high-value components of the enterprise attack surface.
- ISO/IEC 42001 supports structured AI governance and regulatory readiness, but certification must never be conflated with automatic legal compliance.
The question is no longer only whether AI can defend the organisation. The question is how the organisation governs the AI that is allowed to defend it.
ShadowThreats Intelligence
Agentic cyber defense is not only a cybersecurity architecture problem. It is also an AI governance problem.
As defensive AI gains access, authority and autonomy, organisations need to determine not only what these systems can do, but what they should be permitted to do.
ISO/IEC 42001 provides a management-system framework for establishing and continually improving that governance.
At ShadowThreats Intelligence, we are investigating how external threat intelligence, locally operated defensive AI and human-defined governance can work together while preserving accountability and operational control.
Bernhard Kropacek
Bernhard Kropacek is Co-Founder and Research Lead at ShadowThreats Intelligence and works as an ISO/IEC 27001 Lead Auditor for an accredited certification body.
His research focuses on threat-intelligence governance, cyber resilience, AI governance and the responsible operation of emerging agentic defense architectures.