The management team asks the privacy officer: how many AI agents do we run, and what may they do? IT names the customer service bot. Marketing has connected an agent to a shared mailbox, and a developer lets a coding agent read production. Nobody knows who can stop them.
The agent register in brief
An agent register, or AI agent inventory, is the list that records, for each AI agent, what it does, who is responsible for it, what it may do and which rules apply. No framework we have read prescribes an agent register with fixed fields, but the idea keeps recurring: the Dutch Data Protection Authority asks for "a clear and up-to-date overview", Singapore's IMDA and six national cyber agencies for agents that are catalogued and centrally tracked, and NIST for an inventory of AI systems. Do not build a separate list: extend your AI register with fourteen fields per agent and point to the record of processing (Article 30 GDPR). Keep it current with an intake, a periodic comparison against what actually runs and a review after every change. The free Praxikon Agent check produces a pre-filled entry.
Why do you need an agent register?
An agent acts on its own, so regulators ask for an overview, even where they do not call it that.
The Dutch Data Protection Authority (Autoriteit Persoonsgegevens, AP), the GDPR supervisor, writes in its AI & Algorithms Netherlands report (RAN 6, 5 March 2026, p. 33): "A clear and up-to-date overview of the agentic architecture is also needed, recording which AI agents perform which tasks, which powers they hold and how they interact with each other" (our translation). Singapore's IMDA framework (version 1.5, 20 May 2026) wants agent identities and permissions "catalogued and centrally managed" to prevent "agent sprawl": agents multiplying without central management. Six national cyber agencies (1 May 2026) advise a "trusted registry" of agents. NIST asks in the AI RMF 1.0 (GOVERN 1.6) that "mechanisms are in place to inventory AI systems"; that 2023 framework does not mention agents.
So an agent register is not mandatory: no framework we have read prescribes it with fixed fields, and the AI Act has no internal register duty. Without a list, though, you will struggle to demonstrate the duties that do exist: AI literacy (Article 4 AI Act), the transparency duties that come with your role (as a provider, telling people they are dealing with AI, Article 50(1) AI Act) and your GDPR duties, including accountability under Article 5(2) GDPR.
How does it differ from the AI register and the record of processing?
An agent register need not be a separate list: the two existing registers each answer a different question, and neither asks what an agent may do on its own.
| Register | One line per | Question | Mandatory? |
|---|---|---|---|
| Record of processing | processing activity | Which personal data about whom, for what, to which recipients (including outside the EEA), for how long and, broadly, how secured? | Yes, as a rule (Article 30 GDPR) |
| AI register | AI system | Which AI, in which role and risk class? | No |
| Agent register | AI agent | What may the agent do on its own, who can stop it? | No |
So the vendor, the model provider and transfers outside the EEA also belong in the record of processing (points (d) and (e) of Article 30(1) GDPR); what the agent register adds voluntarily is the permissions, approval points, kill switch and tests per agent. Do not build a separate list for that: two registers covering the same systems must be maintained twice, and then they drift apart. An agent is, as a rule, an AI system (the Commission calls that view provisional) and belongs in your AI register. Add the fields below and point each agent to the lines in the record of processing it touches. Do not confuse it with the EU database under the AI Act or the Dutch government's Algorithm Register: those are external registrations.
Which fields do you record for each agent?
Fourteen fields in five groups: a working model, not a legal form. Where an article is the reason, it is named.
Who and what
1. Name and task. A unique name, the task in one sentence and on whose behalf the agent acts. The task weighs heavily: the AI Act classifies on intended purpose (Article 3(12) AI Act) and the GDPR works with purpose limitation (Article 5(1)(b) GDPR).
2. Owner. One named person in the department that uses the agent, not "IT". The UK NCSC wants it settled in advance who owns the agent, approves its access, monitors it and can ultimately stop it. Under the GDPR you must be able to demonstrate compliance (Article 5(2) GDPR).
3. Vendor and model. Vendor, language model and version, plus the contract: the data processing agreement (Article 28 GDPR) and whether the vendor uses your data for its own purposes, such as training. If it uses your data for its own purposes with your agreement, it is itself the controller for that (Article 4(7) GDPR) and you need a legal basis to hand the data over; if it does so outside your instructions, it infringes the GDPR and is considered a controller (Article 28(10) GDPR). See our article on the purchase contract.
What the agent may do
4. Connections and permissions. Every system, plug-in and MCP server (a connector for tools) the agent can reach, with its permission: read, write, send, pay or run code. IMDA advises allowing only trusted MCP servers from a list; according to security researchers, about a fifth of OpenClaw's plug-ins contained malware (Dutch DPA, 12 February 2026). A connection that processes personal data on behalf of you or your vendor is a processor or sub-processor, and a sub-processor needs your prior written authorisation (Article 28(2) GDPR); a service that receives the data for its own purposes is a controller in its own right. Record which of the two each connection is.
5. Personal data. Which categories of data and data subjects the agent can see, not just what it is meant to see, with special categories (Article 9 GDPR) separate and a reference to the record of processing (Article 30(1)(c) GDPR).
6. Dangerous triangle. Does the agent combine access to private data, exposure to untrusted content (email, websites, plug-in output) and the ability to communicate externally? Then a hidden instruction can make it send data out (Simon Willison's "lethal trifecta"). Record which leg you removed, or that a person approves every outgoing message.
7. Approval points. Which actions wait for a person, who approves, and is it enforced in software? IMDA prefers system-level controls over agreements in the prompt. According to the European supervisors, an approval is genuine human involvement under Article 22 GDPR only if the reviewer has the authority and competence to change the decision and considers all the relevant data (WP251rev.01, p. 21); that also takes time (see when an agent decides for itself).
What you can verify and stop
8. Logging and retention. What is recorded, in logs the agent cannot alter, and for how long. For high-risk systems the provider must build the system so that it logs events automatically (Article 12 and Article 16(a) AI Act). Providers and deployers keep the logs under their control for a period appropriate to the intended purpose, of at least six months, unless other Union or national law, in particular data protection law, provides otherwise (Article 19(1) and Article 26(6) AI Act). Logs can contain personal data, so always set a retention period (Article 5(1)(e) GDPR).
9. Kill switch. Who stops the agent, how (switch it off, revoke keys, block connections) and when was that last tested? The Dutch DPA names "built-in stop mechanisms in case of abnormal behaviour" as a design choice (RAN 6, p. 32, our translation). For high-risk systems the provider must design the system so that those overseeing it can, where appropriate, halt it with a "stop" button or a similar procedure (Article 14(4)(e) AI Act). If the deployer has reason to consider that the system presents a risk within the meaning of Article 79(1) AI Act, it informs the provider or distributor and the market surveillance authority without undue delay and suspends use (Article 26(5) AI Act).
What the law asks
10. Role and risk class under the AI Act. Provider, deployer or both, and the class with the reason. A provider is whoever develops an agent or has it developed and places it on the market or puts it into service under its own name or trademark, including for its own use (Article 3(3) and (11) AI Act); whoever only uses a vendor's agent is a deployer, unless Article 25(1) AI Act shifts the role. Record what applies already (Article 4 AI Act; Article 50 AI Act since 2 August 2026) and what is coming (Annex III from 2 December 2027). A provider that considers an Annex III system not to be high-risk documents that assessment before placing it on the market or putting it into service, and registers itself and the system in the EU database (Article 6(4) and Article 49(2) AI Act); Article 6(4) applies from 2 December 2027 (Article 113(c) AI Act).
11. Role and legal basis under the GDPR. Controller, processor or joint controller, per link in the chain (Article 4(7) and Article 4(8) GDPR, and Article 26 GDPR), and the legal basis per purpose (Article 6 GDPR). If the agent takes decisions with legal or similarly significant effects, record which exception in Article 22(2) GDPR applies.
12. DPIA and FRIA. Whether a data protection impact assessment (DPIA) is needed, with date and reason, also when the answer is "not needed" (Article 35(1) GDPR; review when the risk changes: Article 35(11) GDPR). The fundamental rights impact assessment (FRIA) applies from 2 December 2027 only to high-risk systems from Annex III (Article 6(2) AI Act), and then only to bodies governed by public law, private entities providing public services and deployers assessing creditworthiness or pricing life and health insurance (Annex III point 5(b) and (c)), not in critical infrastructure (Article 27(1) AI Act); for systems already placed on the market or put into service before that date, Article 111(2) AI Act applies.
How the agent works with others and is tested
13. Interaction with other agents. Which agents does it hand work to, whose output does it receive, do they share memory? According to the Dutch DPA the risk also lies in how agents influence each other (RAN 6, p. 32). The Commission's draft guidelines (19 May 2026, point 75) treat systems that together materially influence an individual decision as one AI system, including for agents.
14. Last test and review. The date, what was tested (hidden instructions, permissions, kill switch), the result and the date or trigger for the next review. The GDPR asks for measures to be reviewed and tested (Article 24(1) GDPR and Article 32(1)(d) GDPR). Change the date only after a real test.
What does a filled-in entry look like?
Three fictional agents in the same fields; in your register the justification sits alongside.
| Field | Customer agent (web shop) | Screening agent (employer) | Coding agent (production) |
|---|---|---|---|
| Name and task | Answers questions about orders | Ranks candidates on vacancy criteria | Writes and tests code, runs commands |
| Owner | Customer service team lead | Recruitment manager | Lead developer |
| Vendor and model | Vendor, model, version, processing agreement | Vendor, model, version, processing agreement | Vendor, model, version, no training on our code |
| Connections and permissions | Reads orders, sends email, no payments | Reads applicant system, writes score back, no email | Repository and test; production read-only; approved MCP servers only |
| Personal data | Name, address, order history (processing line 12) | CVs, possibly special categories (processing line 31) | Customer data in production (read-only); masked in the test environment |
| Dangerous triangle | All three, so a person approves every reply | Two of three, sends nothing out | All three, so no internet from the test environment |
| Approval points | Refunds, deviations from policy | Every rejection, by a recruiter with the full file | Changes to production, new connections; enforced in the development process |
| Logging | Tool calls and approvals, retention set | Input, criteria, score, who decided | Every command, in logs the agent cannot change |
| Kill switch | Team lead or IT switches off, revokes key | Manager switches off, recruiters continue by hand | Revoke keys and MCP connections; tested |
| AI Act | Deployer (vendor is provider); not high-risk | Deployer; high-risk (Annex III point 4(a)) from 2 December 2027; Article 6(3) AI Act does not apply, because ranking is profiling | Deployer; no Annex III task, not high-risk |
| GDPR | Controller, legal basis contract | Controller, legal basis and balancing recorded, Article 22 GDPR assessed | Controller, vendor is processor |
| DPIA and FRIA | DPIA not needed, reason recorded; no FRIA | DPIA before go-live; no FRIA (private employer) | DPIA screening recorded: reads real customer data in production; no FRIA |
| Interaction | Hands returns to the warehouse agent | Passes ranking to the scheduling agent: under the draft guidelines, to be assessed together as one system | Review agent in the development process, then a person |
| Last test | October 2026; again on a new connection | October 2026, test for bias and hidden text; again on a model update | October 2026, hidden instruction in a ticket; again on a new model |
The customer agent is the lightest case. If the web shop has the agent developed for it and puts it into service under its own name, it is itself the provider and Article 50(1) AI Act falls to it.
The screening agent is the heaviest: filtering applications and evaluating candidates is listed in Annex III point 4(a), and the exception in Article 6(3) AI Act never applies where the system profiles people. If the system was already placed on the market or put into service before 2 December 2027, the high-risk requirements apply only once its design changes significantly after that date (Article 111(2) AI Act).
How do you keep the agent register current?
Find the agents nobody reported. Employees switch on agents themselves. On 12 February 2026 the Dutch DPA warned about OpenClaw, which after installation gets access to a computer, email and files and can act without prior approval. Compare the register periodically with what actually runs, as six national cyber agencies advise ("periodically reconcile the registry against the live set of agents"): licences, connected apps, API keys, MCP configurations.
Let new agents go live only through an intake. No register entry, no keys. The same agencies even advise denying access to any agent that is not in the registry.
Review on every change. IMDA names model updates, modified tools, a changed environment, anomalous behaviour and new rules as triggers (p. 45). Watch for a new task in particular: if you change the purpose of a vendor's agent so that it becomes high-risk, you become its provider (Article 25(1)(c) AI Act). Mark agents nobody uses as "retired" and revoke their keys.
Who owns the agent register?
Two roles. Every agent has an owner in the department that uses it (field 2). The register has a keeper, usually the privacy officer or the AI lead, who guards the intake and runs the periodic comparison. IT or security supplies the technical facts and procurement the contracts; the board decides on agents with extensive permissions or high risk. A responsibility matrix (RACI) is in AI governance through the privacy function.
Where do you start?
Do not start with a blank form. The free Agent check from Praxikon asks fourteen questions and returns a pre-filled register entry: what the agent can do on its own, personal data, dangerous triangle, approval, logging and kill switch, AI Act role and class, Article 22 GDPR and DPIA. You fill in name, owner, vendor, connections, interaction and the date of the last test yourself. Background: the guide to AI agents and the law. If you want help, you can hire Zahed Ashkara as an AI and privacy legal adviser.
Frequently asked questions about the agent register
Sources
Newsletter
Every Tuesday, the AI Act week ahead in 5 minutes
A practical briefing on deadlines, new guidance and enforcement, so you know what matters this week. No spam and you can unsubscribe in one click.
Practical and short · No spam · One-click unsubscribe