What is AI agent governance? Definition, risks and practice

A language model that summarises a draft contract produces text. An AI agent that reads the same contract, enters a deadline in the calendar and emails the other side changes the state of real systems. That shift from answering to acting makes agent governance a discipline of its own. Our position: what needs controlling is not primarily the model but every action it is allowed to trigger. At its core, agent governance is permission and approval management for an actor that forms its intentions from text nobody should trust unchecked.

Definition: what AI agent governance is, and what it is not

AI agent governance is the set of rules, technical controls and responsibilities that determine which actions an AI agent may take in which systems, who approves those actions, how they are traceably recorded and how the agent can be stopped at any moment.

General AI governance asks whether an organisation uses AI at all, for what purposes and with which data: policies, risk classification, training. Model security concerns the model itself: training data, robustness against manipulation, unwanted outputs. Agent governance sits where model output meets a real system. It assumes the model will err and can be manipulated, and keeps either from causing damage.

The five building blocks

Agent governance rests on five building blocks. If one is missing, the others cannot close the gap.

These blocks must be enforced technically, not written into the system prompt. An instruction such as "never send files outside the organisation" is a request to a statistical model, not a control.

Typical risks: where agents go wrong in practice

In the 2026 edition of the OWASP Top 10 for LLM Applications, excessive agency, meaning too much room to act, climbed from sixth to third place. OWASP traces the risk to three causes: too much functionality, too many permissions and too much autonomy. Typical patterns:

• Manipulation through content: an agent that reads emails or documents can be redirected by instructions hidden inside them. This indirect prompt injection needs no system access, only a crafted PDF in the inbox.
• Creeping privilege: first the agent gets a mailbox, later a file share and the accounting system. Nobody revokes anything.
• Missing attribution: if the agent acts through a personal account, nobody can later tell whether a person or the machine posted a transaction.

The regulatory frame: AI Act, GDPR and NIS2 as of October 2026

The AI Act does not regulate agents as a technology; it regulates purposes. An agent that pre-codes receipts is usually not a high-risk system. One that pre-screens job applications falls under employment in Annex III. Under Article 14, such systems must allow effective human oversight, including a "stop" button that halts them in a safe state. Under Article 26, deployers must keep automatically generated logs for at least six months. The Digital Omnibus on AI, Regulation (EU) 2026/1744, in force since 27 July 2026, moved the application date for Annex III high-risk systems from 2 August 2026 to 2 December 2027, and for systems embedded in products under Annex I to 2 August 2028. Article 4 on staff AI literacy remains but no longer demands a guaranteed level of competence.

The GDPR applies as soon as an agent processes personal data, which almost every agent in a law firm, tax practice or clinic does. Accountability (Article 5(2)) and security of processing (Article 32) require you to demonstrate what the agent did with which data. Large-scale processing of health data triggers a mandatory data protection impact assessment under Article 35.

Austria's NISG 2026, transposing the NIS2 Directive, entered into force on 1 October 2026. For entities in scope, including medium-sized and larger healthcare providers, risk management, access control and incident reporting are mandatory. An agent with system access is then simply another privileged account.

Where to start: four steps

1. Inventory: record every agent with its purpose, owner, accounts used, reachable systems and data categories. Include agent features in licensed software.
2. Action levels: assign every possible action to an action level, for instance read-only, local change, external effect. The level determines the check required. Sending email, payments and deletions belong at the top.
3. Allowlists: permit only explicitly approved tools and destinations and refuse everything else (default deny).
4. Logging: record each action with trigger, parameters, check result and outcome so that later tampering shows. Such an audit trail is also your evidence towards supervisors and clients.

Start small: one agent, one clearly bounded process.

Governance belongs in the architecture, not the handbook

An approval rule the agent can bypass is no rule at all. That is why the check should happen outside the agent, deterministically and in a separate component. We set out the reasoning in our piece on why an agent cannot check itself.

AEGIS, the locally operated agent system from oQueo, implements this as a three-authority principle. A planning authority produces structured intents but has no access to secrets and cannot execute tools. A checking authority validates schema, action level and tool allowlist, guards against replays and signs approved intents with HMAC-SHA256. The execution authority verifies the signature again and keeps an append-only audit log as a SHA-256 hash chain. AEGIS supports your compliance; it does not replace legal review or organisational responsibility. More on how it works.