Published May 2026 | Senad Džananović | Cyber & AI Governance Advisory
The question most organisations haven’t asked yet
Your organisation has probably deployed an AI agent.
That is not the same as governing one.
In early May 2026, CISA, NSA and cybersecurity agencies from Australia, Canada, New Zealand and the United Kingdom published joint guidance on agentic AI. Their central message was direct: autonomous AI systems are already operating inside critical infrastructure and defence environments, and most organisations are granting them far more access than they can safely monitor or control.
This article maps that guidance — alongside NIST, the EU AI Act, ISO and OECD frameworks — into what organisations actually need to address. Not what the frameworks say in the abstract. What they require from you, at board level, at CISO level, and at risk management level, in the order that matters.
What makes agentic AI different
A chatbot answers questions. An AI agent takes action.
Agentic AI systems — software built on large language models that can plan, make decisions and execute multi-step tasks without human review at each stage — connect to external tools, databases, memory stores and automated workflows. They can send communications, modify records, execute transactions, change access controls and delete audit trails. When an agent takes a wrong action, the sequence has already happened.
This is the distinction most governance conversations miss. Agentic AI is not a more capable tool. It is an autonomous actor operating under your accountability structure — with privileges, memory, and the ability to produce consequences that cannot always be reversed.
Five Eyes guidance identifies five categories of risk specific to agentic systems:
Privilege risk. When agents are granted excessive access, a single compromise causes far more damage than a typical software vulnerability. The blast radius is determined by what the agent can reach, not just what it was asked to do.
Design and configuration risk. Poor setup creates security gaps before a system goes live. Most organisations are configuring agentic AI with the same assumptions they apply to software. The assumptions don’t transfer.
Behavioural risk. An agent may pursue a goal in ways its designers never intended or predicted. Goal drift — where the agent’s behaviour shifts away from its defined objective over time — is a documented failure mode with no simple technical fix.
Structural risk. Interconnected networks of agents can trigger failures that propagate across an organisation’s systems. A single misconfigured agent in a multi-agent architecture can compromise the entire chain.
Accountability risk. Agentic systems make decisions through processes that are difficult to inspect and generate logs that are hard to parse. When something goes wrong, tracing what happened, why it happened, and who authorised it is not straightforward — unless the organisation has built that capability in advance.
What the frameworks actually say
There is no single governance standard for agentic AI. What exists is a set of frameworks — each operating at a different level of specificity — that together define what responsible deployment looks like.
Five Eyes Joint Guidance (CISA/NSA, May 2026)
The most operationally specific document currently available. Its central recommendation is to fold agentic AI into existing cybersecurity frameworks — zero trust, defence-in-depth, least privilege — rather than treating it as a separate discipline. But it goes further than generic principles.
The guidance recommends that each agent carry a verified, cryptographically secured identity, use short-lived credentials, and encrypt all communications with other agents and services. For high-impact actions, human sign-off is required. The guidance is explicit that deciding which actions require human approval is the responsibility of system designers, not the agent.
Critically, the guidance acknowledges that the security field has not caught up with agentic AI. Some risks specific to these systems are not yet covered by existing frameworks. The recommendation for this gap: assume that agentic AI systems may behave unexpectedly, and plan deployments accordingly — prioritising resilience, reversibility and risk containment over efficiency.
NIST AI Risk Management Framework
NIST AI RMF structures governance through four functions: Govern, Map, Measure and Manage. For agentic AI, this translates into a continuous risk management cycle — not a one-time assessment.
The framework’s strength is in governance architecture: defining risk tolerance at board level, assigning clear roles and accountability across the organisation, and creating structures for ongoing evaluation. Its limitation for agentic AI is that it does not prescribe the specific controls that agentic architectures require — inter-agent trust, runtime policy enforcement, cryptographic identity per agent. It provides the governance skeleton; the Five Eyes guidance provides the operational detail.
EU AI Act
The AI Act introduces legal obligations that vary by the role an organisation plays — provider, deployer, integrator — and by the risk classification of the AI system. High-risk AI systems require a documented risk management system, data governance controls, technical documentation, logging, human oversight capability, and post-market monitoring.
The important distinction for practitioners: the AI Act defines what is legally permissible. Five Eyes guidance defines what is operationally prudent. These are not the same. An agentic AI system can be legally compliant under the AI Act and simultaneously represent an unacceptable operational security risk. Legal classification and security posture must be evaluated separately, by different functions, with both results informing deployment decisions.
ISO/IEC AI Governance Standards
ISO/IEC 42001 (AI management system), 23894 (risk management), 42005 (impact assessment) and 38507 (board governance) provide the management system architecture for AI governance — policies, objectives, accountability structures, continuous improvement cycles and audit capability.
ISO standards are the governance backbone. They define how an organisation structures its AI governance programme and how that programme is maintained over time. For boards, ISO/IEC 38507 is specifically designed for governing body oversight of AI — it defines what the board is responsible for and what it needs to be able to demonstrate.
OECD AI Principles and Due Diligence Guidance
The OECD framework adds a dimension that cyber-focused guidance underweights: the full value chain. In agentic AI architectures, the roles of provider, deployer and integrator frequently overlap or shift. An organisation may be simultaneously deploying an agent built on an external model, integrating third-party tools, and acting as the operator accountable to regulators and end users.
OECD due diligence guidance requires organisations to identify and assess impacts across this chain — not just within their own systems — and to establish processes for communicating with affected stakeholders and remediating harm. Most AI governance programmes do not yet address this.
Where most organisations actually are
The gap between what frameworks require and what organisations have in place is not primarily a technical gap. It is a governance gap.
In most organisations I work with, the following questions do not have documented answers:
- Which AI agents are currently operating, what can they do, and who owns the risk for each?
- Which actions can agents take without human approval — and has that boundary been explicitly set at the right organisational level?
- If an agent causes harm — through a wrong action, a compromised credential, or behaviour outside its defined scope — who is accountable, and can they demonstrate they made an informed decision?
- Does the organisation have the capability to pause, isolate or roll back an agent quickly?
- Are vendor-supplied AI agents covered by the same governance requirements as internally developed ones?
This is not negligence. It is the predictable result of deploying technology faster than governance structures can absorb it. The organisations that close this gap are not the ones that slow down AI adoption. They are the ones that treat governance as a prerequisite for expanding autonomy, not a retrospective exercise after something goes wrong.
What board-level governance requires
Across every relevant framework — NIST, ISO/IEC 38507, OECD, EU AI Act and Five Eyes guidance — boards have five core responsibilities for agentic AI.
Define the risk appetite and the no-go zones. The board must decide what the organisation is and is not willing to let an AI agent do autonomously. This is not a technical decision delegated to IT. It is an accountability decision made at the level where accountability sits.
Ensure a complete inventory exists. No governance structure can function without knowing what it governs. Every agentic AI system — including those operated by vendors on the organisation’s behalf — must be inventoried, classified by risk, and assigned a named owner.
Require demonstrable control architecture. The board should not accept assurance that controls exist. It should require evidence: that agents have unique identities, that privileges are bounded, that high-impact actions require human approval, that logs exist and are protected, and that rollback capability has been tested.
Receive regular, readable reporting. Board-level AI risk reporting should be structured around accountability metrics — not technical metrics. What is the agent doing, what can it do, what has gone wrong, and what is open?
Establish and own the exception process. When a business case requires autonomy beyond low-risk scenarios, that exception should require board or executive approval, with documented rationale, time limits and conditions for review.
A board that cannot answer the following five questions about its agentic AI estate has a governance gap worth addressing before the agent estate grows:
- Do we have a complete inventory of all AI agents operating in our organisation — including those deployed by our vendors?
- For every AI agent that can take action on our behalf — can we name the individual accountable for that agent’s decisions?
- Which actions can our AI agents take without human approval — and has the board explicitly accepted that boundary?
- If a regulator asked us tomorrow to explain what an AI agent did, why it did it, and who authorised it — could we answer?
- Do we have a documented process to pause, isolate or roll back an AI agent that behaves outside defined boundaries?
What CISO and security leadership need to implement
The gap between board-level governance and operational security is where most agentic AI risk accumulates. The following represent the minimum control baseline that current guidance — across Five Eyes, NIST, and EU AI Act — converges on.
Identity per agent. Every agent must have a unique, verified identity. Shared credentials between agents create an unacceptable blast radius if any single agent is compromised. Identity should be cryptographically secured and use short-lived credentials where possible.
Least privilege, enforced at runtime. Agents should have access only to the specific resources, actions and data required for their defined task — scoped to the minimum necessary and reviewed regularly. This is not a configuration setting applied once at deployment. It is an ongoing operational requirement.
Controlled tool ecosystem. Every tool, API, plugin and external service an agent can call should be on an approved list, version-controlled, and verified for provenance. Tool squatting — where a malicious tool is substituted for a legitimate one — is a documented attack vector specific to agentic architectures.
Input validation and prompt injection controls. Agents operating on external data — documents, emails, web content — are exposed to prompt injection: instructions embedded in data that hijack agent behaviour. This is not a hypothetical risk. It is a current attack vector with no complete technical solution. Mitigation requires input sanitisation, prompt hierarchy controls, and output validation before any consequential action is taken.
Human approval checkpoints for high-impact actions. The organisation must define, in advance, which categories of action require human sign-off. This includes but is not limited to: changes to access controls, deletion of records, external communications sent on behalf of the organisation, financial transactions above defined thresholds, and any action that cannot be reversed. The definition of “high-impact” is a governance decision, not a technical one — it must be made by system designers and approved at the appropriate organisational level before deployment.
Comprehensive, tamper-resistant logging. Every prompt, tool call, decision, identity, privilege use and action outcome must be logged. Critically: agents must not have write access to their own audit records. Logs that an agent can modify are not an audit trail.
Runtime monitoring for drift and anomaly. Goal drift — where agent behaviour shifts away from its defined objective — cannot be detected by reviewing configuration. It requires active monitoring of agent behaviour in production: anomalous tool sequences, unusual resource consumption, actions outside defined scope. This monitoring must be connected to a response process.
Incident response and rollback capability. Before any agentic AI system goes into production, the organisation must have a tested playbook for: pausing the agent, isolating it from connected systems, revoking its credentials, restoring prior system state, and conducting post-incident analysis. The playbook must be tested before it is needed.
Vendor and third-party controls. An agent deployed by a vendor on your infrastructure is your governance responsibility. Vendor contracts must include: logging requirements, incident notification obligations, security testing standards, audit rights, and evidence of supply chain integrity for models, tools and dependencies.
What risk managers need to address
The classification problem. Most enterprise risk frameworks classify AI as a subcategory of technology or operational risk. Agentic AI requires its own classification — not because it is entirely different, but because the specific risk characteristics (autonomy, privilege, irreversibility, accountability diffusion) are not captured by standard technology risk criteria.
The legal versus operational distinction. Risk managers operating in EU-regulated environments must be clear on this: legal compliance with the AI Act and operational security posture are separate assessments. An AI system can satisfy AI Act requirements for a high-risk system and simultaneously represent an unacceptable operational security risk under Five Eyes guidance. Both assessments must be completed, by the appropriate functions, before deployment.
The value chain problem. In agentic architectures, it is often unclear who is the provider, who is the deployer, and who is the integrator — particularly when external models, open-source tools and third-party APIs are involved. This ambiguity has direct regulatory consequences under the AI Act, and direct accountability consequences under OECD due diligence principles. Risk managers must map the value chain for every agentic AI deployment and assign clear roles before the deployment goes live.
The TPRM gap. Standard third-party risk management processes assess the vendor. They typically do not assess the AI risk the vendor’s systems introduce into the organisation’s processes. An agentic AI system supplied by a vendor requires both forms of assessment — vendor-level and system-level — with results feeding into a unified risk view.
A practical implementation sequence
Across frameworks, the recommended sequence is consistent: governance and inventory first, minimum technical controls second, evaluation before production, phased expansion of autonomy based on demonstrated control.
Weeks 0–2: Inventory all agentic AI use cases, systems, models, tools, vendors and named risk owners. Prohibit new agentic AI deployments going into production without governance approval. Establish a gate process.
Weeks 2–6: Classify each use case by data sensitivity, privilege level, reversibility of actions and legal role. Define the minimum control baseline required for each class. Conduct legal qualification under the AI Act.
Months 2–3: Run controlled pilots in sandbox environments. Implement unique agent identity, allow-listed tools, comprehensive logging and human approval thresholds. Conduct threat modelling before production.
Months 3–6: Red team. Validate outputs. Implement runtime monitoring. Test rollback capability. Build vendor contract baseline. Establish board-level dashboard.
Months 6–12: Expand agent autonomy only where controls have been demonstrated and validated. Conduct quarterly re-evaluations. Build toward internal audit readiness.
The underlying principle is straightforward: autonomy is not expanded by enthusiasm. It is expanded by demonstrated control.
Conclusion
Agentic AI is not coming. It is here, operating in production environments, taking actions on behalf of organisations that have not yet built the governance structures to manage what they have deployed.
The frameworks now exist. Five Eyes guidance provides the operational security baseline. NIST provides the governance architecture. The EU AI Act provides the legal framework. ISO provides the management system structure. OECD provides the value chain and stakeholder accountability logic.
What most organisations are missing is not framework knowledge. It is the translation from framework to accountability structure — who decides what the agent can do, who is responsible when it does something wrong, and what exists to detect and contain the failure before it compounds.
That translation is the work. And it starts with five questions the board should be able to answer before the agent estate grows any further.
Senad Džananović is a senior Cyber and AI Governance advisor with 20+ years of experience across Central and Eastern Europe. He works with boards, CISOs and risk managers to translate governance and regulatory requirements into systems that hold under audit, regulatory scrutiny and real incidents.
