AI Governance · Guide
Agentic AI governance: permissions, guardrails and audit trails for AI agents
Agentic AI governance: permissions, guardrails and audit trails for AI agents
Key takeaways
Agentic AI governance decides what an AI agent may do on its own, with what access, under whose authority, and how each action is evidenced. Treat every agent as a non-human identity: register it with a human sponsor, set its autonomy tier by what it can touch, give it least-privilege access, enforce guardrails outside the agent and log intent, permission, action and outcome.
- Organisational responsibility
- The ICO says organisations remain responsible for data protection compliance of the agentic AI they develop, deploy or integrate, and that an agent's autonomy is no excuse for poor compliance.
- UK automated decisions
- UK GDPR Articles 22A to 22D, in force since 5 February 2026, cover significant decisions with no meaningful human involvement and require safeguards, including human intervention and a right to contest.
- EU AI Act high-risk date
- The EU AI Act's high-risk rules for Annex III uses, including Article 14 human oversight and Article 26 deployer duties, apply from 2 December 2027. AI agents are not a separate category.
- Action logs
- The UK AI Cyber Security Code of Practice says system operators shall log system and user actions. For high-risk EU uses, deployers must keep logs they control for at least six months.
Your product team has shipped an AI agent that can read the ticket queue, query the customer database and send emails. Then an enterprise customer's security questionnaire asks how you control autonomous AI, and nobody can say what the agent is allowed to do. Agentic AI governance answers that question with records rather than reassurance.
This guide is for CTOs, heads of engineering and security leads at UK B2B tech firms of 25 to 250 people. It gives you a proportionate model: an agent register, autonomy tiers, least-privilege access, enforced guardrails and an audit trail that ties every action to a named person.
What is agentic AI governance?
Agentic AI governance is the set of rules, permissions and records that decide what an AI agent may do on its own, with what access, under whose authority, and how every action is evidenced. An agent's autonomy should be earned task by task, not granted by default. Guardrails only count when they are enforced and logged.
The model in this guide treats an AI agent as a non-human identity acting with delegated authority. That framing lets you reuse what your security programme already does for people and service accounts: register the identity, limit its access, watch what it does and remove it when it is no longer needed.
Why do AI agents need different governance from other AI use?
AI agents need different governance because they act rather than advise. A chatbot produces text that a person reads and then decides what to do. An agent calls tools, chains steps together and can hand work to other agents, so the risk sits in the actions it takes, not only in the words it produces.
Three properties change the governance problem:
- Agents act. They write to systems, send messages, move data and spend money. A wrong output becomes a wrong action before anyone reads it.
- Agents chain tools. One instruction can trigger many calls across several systems. Each call is a permission someone granted, often without seeing the full chain.
- Agents delegate. An agent may call another agent or a third-party service. Accountability can blur across that supply chain unless you fix it in advance.
How agents are attacked and misused is a separate question, covered in our guide to AI security risks. This page covers the governance that limits the damage when something goes wrong.
What should an AI agent register record?
An AI agent register records every agent your firm builds, buys or switches on, with a named human sponsor, its purpose, the tools and data it can reach, its autonomy tier and your role as provider or deployer. It is the inventory that every other control depends on. An agent missing from the register is not governed at all.
The UK government's voluntary AI Cyber Security Code of Practice makes the same point for AI generally: Provision 5.1 says developers, data custodians and system operators "shall maintain a comprehensive inventory of their assets". For agents, one row per agent is enough to start.
| Field | What to record | Why it matters |
|---|---|---|
| Agent name and ID | A unique name and the identity it runs under | Links every log entry back to one agent |
| Human sponsor | The named person accountable for the agent | Someone must answer for its actions |
| Purpose | The task it exists to do, in one sentence | Keeps scope and data use narrow |
| Tools and systems | Every system it can read from or write to | Shows the real reach of its permissions |
| Data | The data categories it touches, including personal data | Drives UK GDPR and customer obligations |
| Autonomy tier | Read, draft, act with approval, or act alone | Sets the approval and evidence it needs |
| Role | Whether you built it (provider) or bought it (deployer) | Decides which duties apply to you |
| Review date | When its access and tier were last checked | Stops permissions drifting upwards |
We recommend keeping the register in the same place as your asset inventory, so agents go through the same joiner, mover and leaver steps as any other identity.
How much autonomy should an AI agent have?
An AI agent should have the lowest autonomy tier that lets it do its task, set by what it can touch rather than by how capable it seems. We recommend four tiers: read, draft, act with approval, and act alone. Each carries its own approval point and evidence, and an agent moves up only once it has earned it.
| Tier | What the agent may do | Who approves | Evidence to keep |
|---|---|---|---|
| 1. Read | Look up and summarise information; change nothing | Sponsor approves the data sources once | Register entry and access list |
| 2. Draft | Prepare outputs (emails, tickets, code changes) that a person sends or applies | A person approves each output before it takes effect | Draft, reviewer and decision in the log |
| 3. Act with approval | Take actions in live systems after a person confirms each one | A named approver per action, inside set limits | Request, approval, action and outcome |
| 4. Act alone | Take bounded actions without per-action approval | Sponsor and security lead approve the tier and its limits | Full action log, limit breaches and periodic review |
The tier follows the blast radius. An agent that drafts replies to customers can sit at tier 2. An agent that refunds payments or changes access rights should sit at tier 3 until its record justifies more. Tier 4 belongs to narrow, reversible, low-value actions with hard limits.
Autonomy is a permission, not a feature.
Where a person reviews or approves an action, the design of that review matters as much as its existence, and the approval itself belongs in the log.
How do you apply least privilege to AI agents?
Apply least privilege to AI agents by giving each agent its own identity, the narrowest access its task needs, and short-lived credentials that expire on their own. Never let an agent borrow a person's account or a shared admin key. This is the same thinking you already apply to people and service accounts, extended to a new kind of user.
In ISO 27001 terms, the logic follows Annex A 5.15 on access control and Annex A 8.2 on privileged access rights: access is granted for a business need, limited to what that need requires, and reviewed. For agents, that translates into five controls:
- One identity per agent. Every action can then be traced to one agent, not to a shared key used by five.
- Scope by task. Grant read access to the records the task needs, not the whole database. Grant write access only where the tier allows it.
- Short-lived credentials. Prefer tokens that expire in hours over keys that live for years. A leaked short-lived token does far less damage.
- No inherited human privilege. An agent acting for a senior engineer should not inherit that engineer's admin rights.
- Regular access review. Include agents in the access reviews you already run, and remove agents that have no current sponsor.
NIST is working on this problem in public. Its National Cybersecurity Center of Excellence published a concept paper on software and AI agent identity and authorization on 5 February 2026, asking about "the identification, authorization, auditing and non-repudiation of AI agents". You do not need enterprise identity infrastructure to apply the principle. A firm of 50 people can meet it with separate service identities and disciplined scoping.
What about agents built into tools you buy?
Agents built into SaaS tools you buy need the same governance, because you are the deployer even when you did not build them. Register them, check which data and systems the vendor's agent can reach, and switch off autonomous actions you have not approved. Your supplier assessment should ask how the vendor limits and logs its agent's actions.
What are AI guardrails, and when do they count as controls?
AI guardrails are the limits that stop an agent from taking actions outside its approved scope: checks before an action runs, caps on spend and volume, and a way to stop the agent at once. Guardrails count as controls only when they are written as policy, enforced by the system rather than the agent, and logged every time they fire.
A guardrail that the agent can talk its way past is a suggestion, not a control.
Write each guardrail as a policy statement first, with a named owner, then require that it is enforced outside the agent and that every enforcement leaves a record. Our guide to policy as code explains how written rules become checks that are enforced and evidenced automatically. For agents, the guardrails that matter most are:
- Pre-action checks. Before an agent writes, sends or deletes, a check confirms the action sits inside its tier and scope.
- Spend and volume limits. Caps on money moved, records changed or messages sent per hour or per day.
- Scope limits. Lists of the systems, recipients and data the agent may act on, with everything else refused.
- A kill switch. A tested way to stop the agent at once, owned by a named person, with the agent's sponsor told when it is used.
- Escalation on breach. When a guardrail fires, the action stops and a person is alerted, rather than the agent retrying another route.
The EU AI Act takes the same view for high-risk systems. Article 14 expects the people overseeing a high-risk system to be able to "interrupt the system through a 'stop' button or a similar procedure". Test your kill switch before you need it, and record the date of each test.
What should an AI agent audit trail capture?
An AI agent audit trail should capture four things for every action: the intent behind it, the permission that allowed it, the action actually taken and the outcome. Each entry should link to the agent's identity and its human sponsor. Without that chain, you cannot explain an agent's action to a customer, an auditor or a regulator.
The DSIT Code of Practice says system operators "shall log system and user actions" (provision 12.1) and should analyse those logs to spot unexpected behaviour. The NCSC guidelines for secure AI system development also place logging and monitoring in the secure operation and maintenance stage.
Set a review rhythm that matches the tier:
- Tier 3 and 4 agents: review guardrail breaches and failed actions weekly, and sample normal actions monthly.
- All agents: review the register, permissions and tier quarterly, alongside your access reviews.
- Every incident: use the kill switch, preserve the log, tell the sponsor and record what changed before the agent restarts.
For high-risk uses under the EU AI Act, Article 26 requires deployers to keep the logs the system generates, where those logs are under their control, for at least six months. Deciding your retention period now saves rework later.
Which laws and standards apply to agentic AI governance?
No UK or EU law treats AI agents as a separate category. Duties follow the use case, the data and your role. UK GDPR applies when agents process personal data or make significant automated decisions. The EU AI Act applies by risk class. ISO/IEC 42001:2023, the NIST AI RMF and AIUC-1 are the frameworks a customer is likely to name.
UK GDPR. Articles 22A to 22D, inserted by section 80 of the Data (Use and Access) Act 2025, came into force on 5 February 2026 under SI 2026/82. They apply where a significant decision about a person is taken with "no meaningful human involvement". The safeguards include letting the person make representations, obtain human intervention and contest the decision.
The ICO. The ICO's tech futures report on agentic AI is plain that "organisations remain responsible for data protection compliance". In October 2026, the ICO extended its scrutiny to AI agents, saying "the fact AI agents act with autonomy is not an excuse for poor compliance."
The EU AI Act. Under Regulation (EU) 2026/1744, the high-risk rules for Annex III systems, including Article 14 on human oversight and Article 26 on deployer duties, apply from 2 December 2027. Article 4 applies now: providers and deployers must take measures to support the AI literacy of the people operating AI on their behalf.
The frameworks. ISO/IEC 42001:2023 is the certifiable AI management system standard; the register, tiers and audit trail feed its inventory, roles and operational controls. The NIST AI RMF is voluntary and organises the work into Govern, Map, Measure and Manage. AIUC-1 describes itself as "the standard for AI agent security, safety and reliability".
How does agentic AI governance answer customer AI questionnaires?
Agentic AI governance answers customer AI questionnaires by turning each question into a record you can share. When a buyer asks how autonomous AI is controlled, you send the register entry, the autonomy tier, the guardrails and a sample of the audit trail, instead of a paragraph of assurances. Evidence closes the question; prose reopens it.
| What the customer asks | What you send |
|---|---|
| Which AI agents touch our data? | Register entries filtered to their service and data |
| Who is accountable for each agent? | Named sponsors and the approval for each tier |
| Can an agent act without human approval? | The autonomy tier table and the limits on tier 4 |
| How do you restrict what agents can access? | Access scope, credential lifetime and the last access review |
| How would you stop an agent that misbehaves? | The kill switch owner and the date it was last tested |
| Can you show us what an agent did? | A redacted audit trail sample: intent, permission, action, outcome |
The same records serve an ISO/IEC 42001:2023 certification auditor. One set of records answers both.
Common mistakes in agentic AI governance
The most common mistakes in agentic AI governance are granting autonomy by default, letting agents borrow human access, writing guardrails that nothing enforces and logging outputs instead of actions. Each one leaves a gap between what the policy says and what the agent can actually do, and that gap is where incidents happen.
- Starting at tier 4. Agents are switched on with full autonomy because the demo worked. Start at tier 2 and promote on evidence.
- Shared credentials. Several agents use one API key, so no log can say which agent did what.
- Guardrails in the prompt. Instructions telling the agent to behave are not controls. Enforce limits outside the agent.
- No sponsor. The engineer who built the agent leaves, and nobody owns it. Unowned agents should be switched off.
- Ignoring bought agents. Agents inside SaaS tools act on your data too. You are the deployer, so they belong in the register.
- Logs nobody reads. A log with no review cadence is evidence of nothing.
Frequently asked questions
No. An agent is classified by its use case like any other AI system. What agents change is your role: put an agent into a product you place on the EU market and you may be its provider; use one and you are its deployer, with Article 26 duties such as monitoring it and keeping its logs.
Your organisation is. The ICO says organisations remain responsible for data protection compliance of the agentic AI they develop, deploy or integrate. It also lists working out controller and processor responsibilities across the agentic AI supply chain as a new risk, so settle those roles in your supplier contracts before an agent touches personal data.
Only if the involvement is meaningful. A sign-off that rubber-stamps every request is unlikely to stop a significant decision counting as solely automated under Article 22A, so the Article 22C safeguards would still apply. Give approvers the context to judge and the authority to refuse.
Review every agent's permissions and autonomy tier at least quarterly, and straight away when its purpose, tools, data or underlying model change. A new tool connection is a new permission, so treat it as a change the sponsor approves, not a routine update.
Domain engine
AI Governance reference directory.
Every guide in this domain, grouped by level — fundamentals, intermediate and advanced. Open any entry for its core practices, implementation steps and the evidence it produces.
01Fundamentals4 guides
02Intermediate4 guides
AI literacy: what the EU AI Act now asks of your firm, and a proportionate programme to meet itHuman in the loop: designing human oversight you can evidenceAI register: how to inventory every AI system your firm builds, buys or switches onAI risk assessment: how to assess one AI use case for ISO 42001, the EU AI Act and UK GDPR
AI Governance Accelerator
Ready to adopt AI with confidence?
Work with a Trust Architect to inventory your AI use, assess the risks and put controls in place that your board and your enterprise customers can rely on.