Last updated: 22 October 2026
Quick answer: Agentic AI governance is the set of controls that keeps AI agents (systems that plan and take actions through tools and APIs) within your organisation’s risk appetite. In practice it means keeping an inventory of every agent, classifying its risk, limiting what it can access, setting thresholds for human approval, logging every action so it can be traced to an accountable owner, and testing, monitoring and auditing the agent like any other privileged system.
Many organisations have an AI policy. Fewer have controls that work once an AI system stops answering questions and starts doing things: raising purchase orders, changing records or sending emails without a person reviewing each step.
That shift changes the question risk and audit teams must answer: not only whether output is accurate, but what the system is allowed to do, on whose authority, and whether you can reconstruct what it did afterwards.
This guide is written for CISOs, risk managers, DPOs and internal auditors. It explains how agentic AI differs from assistants, the specific risks it introduces, the governance building blocks you need, how to audit agents and what evidence to ask for, and how the work maps to the EU AI Act, ISO/IEC 42001, the NIST AI RMF and ISO 27001. A control checklist table is included near the end.
What is agentic AI, and how is it different from an AI assistant?
Agentic AI refers to systems that pursue a goal by planning steps and executing them, usually by calling tools, APIs or other agents, with limited or no human review of each step.
A typical agent combines a large language model with access to tools (a CRM, ticketing system or payment API), some memory or context, and a loop that decides the next step based on the result of the last one.
| Characteristic | AI assistant or chatbot | AI agent |
|---|---|---|
| Main output | Text, answers or drafts for a person to use | Actions in other systems |
| Human role | Reviews every output before acting | Sets the goal; may review only some actions |
| System access | Usually read-only or none | Read and write access through tools, APIs and service accounts |
| Sequence | Single request and response | Multi-step chains, sometimes involving other agents |
| Main governance question | Is the output accurate and appropriate? | What is it allowed to do, and can we trace and reverse what it did? |
For governance purposes, treat any AI system that can change data, move money, communicate externally or trigger other systems as an agent.
What are the main risks of agentic AI?
The main risks come from autonomy combined with access: an agent can act quickly, at scale and outside working hours, using permissions that were often granted for convenience rather than need.
Autonomy and goal drift
Agents interpret goals. “Reduce open support tickets” can be met by closing tickets without resolving them. The more open-ended the instruction, the wider the range of possible actions.
Tool access and excessive privilege
Agents act through service accounts, API keys and OAuth tokens. These are frequently broader than the task needs, shared between agents, or not rotated. The OWASP Top 10 for LLM Applications calls this “excessive agency”: too much functionality, too many permissions or too much autonomy.
Prompt injection
Agents read content they did not write, such as emails, web pages and documents. Instructions hidden in that content can redirect the agent, for example to forward data. Indirect prompt injection is hard to prevent fully, so controls need to limit the damage an injected instruction can do, not only try to detect it.
Data leakage
Agents may pull personal or confidential data into prompts, logs, memory or third-party model endpoints. Where personal data is involved, GDPR obligations such as purpose limitation, data minimisation and, for high-risk processing, a data protection impact assessment still apply.
Action chaining and cascading errors
One wrong step feeds the next. When agents call other agents, a single error or manipulated input can spread across several systems before anyone notices, which is why rate limits, transaction limits and kill switches matter.
Accountability gaps
If an agent approves a refund or changes a supplier’s bank details, someone in the organisation must own that decision. Without a named owner and a defined intended purpose for each agent, incidents become hard to investigate and responsibility is unclear.
Third-party models and platforms
Most agents rely on externally hosted models, frameworks or plug-ins. Model updates, provider data retention and sub-processors are outside your direct control and need to be managed as supplier risk.
What does an agentic AI governance framework need?
An effective framework extends your existing GRC controls to agents. It needs eight building blocks.
- Inventory or registry. Record every agent: its owner, intended purpose, underlying model and provider, tools and systems it can reach, data categories it processes, autonomy level and deployment status. Include a discovery step for agents built by business teams on low-code platforms. Recording agents in your asset inventory alongside the systems they touch makes dependencies visible.
- Risk classification. Classify each agent by impact (what is the worst realistic outcome?), autonomy (how much does it do without review?) and exposure (does it read untrusted external content?). Check whether the use case falls into a regulated category, such as a high-risk use under the EU AI Act or automated decision-making under GDPR Article 22.
- Access control and least privilege. Give each agent its own identity, scoped credentials and only the permissions its task needs. Prefer read-only access and short-lived tokens. Treat agent accounts as privileged accounts and review them on the same schedule.
- Human-in-the-loop thresholds. Define which actions need prior human approval, for example payments above a set value, external communications, deletion of records, changes to access rights or anything irreversible. Set these thresholds in line with your risk appetite statement and enforce them in the system, not only in policy.
- Logging and traceability. Log the triggering request, the inputs the agent used, each tool call and its parameters, the outputs, any human approvals and the final outcome. Logs should be tamper-resistant, time-synchronised and retained for a defined period. Note that a model’s stated reasoning is not a reliable account of why it acted; the record of actions and inputs is the evidence that matters.
- Testing and red-teaming. Before deployment and after material changes, test the agent against its intended tasks and against misuse: prompt injection, attempts to exceed its permissions, malformed tool responses and edge cases.
- Incident response. Add agent scenarios to your incident playbooks, including how to suspend an agent quickly, revoke its credentials, identify affected records and reverse actions. Agent incidents may also trigger personal data breach or regulatory reporting duties.
- Vendor due diligence. Assess model and platform providers for data use and retention, security certifications, location of processing, sub-processors, change notification and contractual commitments on training with your data.
In practice: start with the inventory and access review. Most early findings come from agents nobody knew about and service accounts with far more access than the agent uses.
How do you audit an AI agent?
You audit an agent as you would audit an automated process with privileged access: confirm it is authorised and owned, that its permissions match its purpose, that controls operate as designed, and that its actions can be reconstructed from evidence.
Because decisions are made by a process rather than a person, often outside working hours, auditors shift from interviewing decision makers to testing the controls around the process.
Audit steps
- Scope. Select agents from the inventory based on risk classification. Reconcile the inventory against identity and access management data and procurement records to check completeness.
- Governance. Confirm each agent has a named business owner, a documented intended purpose, an approved risk assessment and an approval to deploy.
- Access. Compare granted permissions with the permissions the agent actually used over a sample period. Unused high-risk permissions are a finding.
- Human oversight. Sample high-impact actions and check that required approvals were obtained before execution, by authorised people, and that approvers had enough information to make a real decision.
- Traceability. Pick a sample of completed tasks and reconstruct them end to end from logs. If you cannot, logging is not adequate.
- Testing and change. Check that model, prompt, tool or permission changes went through change management and were retested.
- Incidents and monitoring. Review alerts, incidents and near misses, and test that the kill switch or suspension process works.
- Suppliers. Confirm due diligence and contracts are in place for model and platform providers.
Evidence to request: the agent register extract, risk assessments and DPIAs, access lists and the last access review, approval thresholds with sample approval records, action logs for sampled tasks, test and red-team reports, change records, incident records and supplier assessments. The checklist table below maps each item to its control.
If you already run an ISO 27001 internal audit programme, add agents to its scope rather than creating a separate audit cycle. Keeping this evidence in one central repository, linked to the relevant controls, saves time at each audit.
How does agentic AI governance map to the EU AI Act, ISO/IEC 42001, NIST AI RMF and ISO 27001?
None of these frameworks has a separate rulebook for agents, but each already contains requirements that apply directly to them.
EU AI Act
The EU AI Act (Regulation (EU) 2024/1689) regulates AI systems by use case and risk level, not by whether they are agentic. An agent used for a purpose listed in Annex III, such as recruitment, creditworthiness assessment or access to essential services, may be a high-risk AI system. The provisions most relevant to agents include:
- Article 4: AI literacy for staff dealing with AI systems, applicable since 2 February 2025.
- Article 9: a risk management system for high-risk AI systems (a provider obligation).
- Article 12: automatic recording of events (logs) over the lifetime of high-risk systems.
- Article 14: human oversight, including the ability to intervene in or stop the system.
- Article 15: accuracy, robustness and cybersecurity.
- Article 26: deployer obligations, including using the system in line with its instructions, assigning human oversight to competent people, monitoring operation and keeping automatically generated logs for at least six months unless other law requires otherwise.
- Article 50: transparency, such as informing people that they are interacting with an AI system.
The Act applies in stages. Under the original timetable most high-risk obligations apply from 2 August 2026, but the European Commission has proposed changes to the timing of high-risk requirements through its digital omnibus package, so check the current legal position before planning around a specific date. The concept of an “intended purpose” in the Act is a useful anchor for your agent register, whatever the risk tier.
ISO/IEC 42001
ISO/IEC 42001:2023 specifies requirements for an AI management system. It provides the management structure for agentic AI governance: AI policy, roles and responsibilities, AI risk assessment and treatment, AI system impact assessment, life cycle controls, data management, use of AI systems and third-party relationships. Our ISO 42001 certification roadmap explains how to scope and implement it.
NIST AI RMF
The NIST AI Risk Management Framework (AI RMF 1.0) is voluntary and organises AI risk work into four functions: Govern, Map, Measure and Manage. For agents, Map covers context, intended use and the tools an agent can reach; Measure covers testing and monitoring; Manage covers prioritising and responding to risks, including decommissioning. NIST has also published a Generative AI Profile (NIST AI 600-1) that addresses risks specific to generative models.
ISO 27001
Many agent controls are ordinary information security controls applied to a new kind of user. Relevant ISO 27001 Annex A controls include 5.9 (inventory of information and other associated assets), 5.15 and 5.18 (access control and access rights), 8.2 (privileged access rights), 8.15 and 8.16 (logging and monitoring), 8.12 (data leakage prevention), 8.29 and 8.32 (security testing and change management), 5.19 to 5.23 (supplier relationships and cloud services) and 5.24 to 5.28 (incident management).
Agentic AI control checklist
Use this table as a starting point for a gap assessment.
| Control area | Control | Evidence | Framework references |
|---|---|---|---|
| Inventory | Every agent is registered with owner, purpose, model, provider, tools, data and autonomy level | Agent register; reconciliation with IAM and procurement | ISO 42001; NIST AI RMF Map; ISO 27001 5.9 |
| Risk classification | Each agent has a documented risk and, where relevant, impact assessment, including regulatory classification | Risk assessment; AI impact assessment; DPIA | ISO 42001; EU AI Act Art. 6 and Annex III; GDPR Art. 35 |
| Accountability | A named human owner approves deployment and is responsible for outcomes | Approval record; RACI | ISO 42001; NIST AI RMF Govern |
| Least privilege | Agent has its own identity and only the permissions its task requires | Access list; permission usage report; access review | ISO 27001 5.15, 5.18, 8.2 |
| Human oversight | High-impact or irreversible actions need prior human approval; agent can be stopped | Threshold definitions; approval samples; kill switch test | EU AI Act Art. 14 and 26; GDPR Art. 22 |
| Guardrails | Tool allow-lists, transaction and rate limits, input and output filtering | Configuration records; test results | ISO 27001 8.12; EU AI Act Art. 15 |
| Logging | Inputs, tool calls, outputs and approvals are logged, protected and retained | Log samples; retention settings; end-to-end reconstruction | EU AI Act Art. 12 and 26; ISO 27001 8.15 |
| Monitoring | Anomalous behaviour, errors and threshold breaches raise alerts | Alert rules; alert and response records | ISO 27001 8.16; NIST AI RMF Manage |
| Testing | Functional, security and prompt injection testing before go-live and after changes | Test and red-team reports; remediation tickets | ISO 27001 8.29; NIST AI RMF Measure |
| Change management | Changes to model, prompts, tools or permissions are approved and retested | Change records | ISO 27001 8.32; ISO 42001 |
| Incident response | Playbooks cover agent suspension, credential revocation and reversal of actions | Playbooks; exercise records; incident register | ISO 27001 5.24 to 5.28 |
| Third parties | Model and platform providers are assessed and contracted | Vendor assessments; contracts; data processing agreements | ISO 27001 5.19 to 5.23; ISO 42001 |
| Literacy and training | Owners, approvers and developers understand agent risks and their role | Training records | EU AI Act Art. 4 |
How do you put agentic AI governance into practice?
Start small and build on the controls you already run. A practical sequence looks like this:
- Write or update the policy. Define what counts as an agent, who may build or buy one, the approval route and the minimum controls. Manage it through your normal policy management process so it is versioned, approved and acknowledged.
- Build the register. Survey business units, IT and procurement for agents in use.
- Assess and rate risk. Add agent risks to your enterprise risk register with owners, controls and treatment plans, and run a DPIA where personal data is processed at scale or decisions affect individuals.
- Fix access first. Reduce permissions, separate agent identities and set approval thresholds for high-impact actions.
- Assess suppliers. Run due diligence on model and platform providers through your vendor and third-party management process.
- Test, then audit. Red-team the highest-risk agents and add agents to the internal audit plan.
- Review regularly. Reassess agents when their tools, permissions, model or purpose change.
Enactia’s GRC platform supports this work through its risk register, asset inventory, policy management, vendor assessments, incident management and evidence repository, with ISO/IEC 42001 among its supported frameworks. The technical controls themselves, such as agent permissions, guardrails and action logging, sit in your identity, security and AI platforms; the GRC layer records ownership, risk, controls and evidence so that you can demonstrate them.
Frequently asked questions
What is agentic AI governance?
Agentic AI governance is the set of policies, controls and oversight processes that keep autonomous AI agents within an organisation’s risk appetite. It covers who may deploy agents, what they can access, which actions need human approval, how their actions are logged and traced to an owner, and how they are tested, monitored and audited.
Does the EU AI Act regulate AI agents?
The EU AI Act does not create a separate category for agents. It regulates AI systems by use case and risk level. An agent used for a high-risk purpose listed in Annex III, such as recruitment or credit scoring, may be subject to high-risk requirements including logging, human oversight and deployer obligations, while transparency duties can apply to agents that interact with people.
How do you keep a human in the loop with autonomous agents?
Define thresholds for actions that need prior approval, such as payments above a set value, external communications, deletions or changes to access rights, and enforce them technically. There should also be a tested way to pause or stop the agent.
What should an AI agent’s audit log contain?
At minimum: the request or trigger, the inputs and data sources used, each tool or API call with its parameters, the outputs, any human approvals and the final result, all time-stamped and linked to the agent’s identity and owner.
Is ISO/IEC 42001 enough to govern agentic AI?
ISO/IEC 42001 gives you the management system: policy, roles, risk and impact assessment, life cycle and supplier controls. It does not replace technical security controls. Most organisations combine it with ISO 27001 controls for access, logging and incident management.
Who should own AI agent risk?
Each agent should have a named business owner accountable for its purpose and outcomes, supported by IT or security for technical controls and by risk, compliance and data protection for oversight. Internal audit provides independent assurance.
Bringing agents into your GRC programme
AI agents do not need a separate governance universe. They need the controls you already apply to privileged systems and automated processes, extended to cover autonomy, untrusted inputs and third-party models. Start with an inventory and an access review, set clear approval thresholds, make every action traceable to an owner, and keep the evidence ready for audit.
For help structuring AI risk, ISO/IEC 42001 and related controls in one place, contact us or book a demo or start your 14-day free trial.
This article is for general information and is not legal advice.
