How should you govern your AI agents?

1. Why manage an agent like a user account?

Because an agent acts with access rights. A conversational assistant answers and stops. An AI agent reads a file, drafts, writes into software, sends an email. It therefore needs the same things as an account: an identity, rights, a review of those rights, an end date.

Your IT department already applies this cycle to people. For IT leaders, the Work Trend Index 2026 draws a consequence: treat agents as managed entities, with identities, permissions, policy enforcement and lifecycle management, extending the rigour already applied to people and applications¹. The correspondence, line by line:

One difference calls for more rigour with agents: the scale of error. When each file goes through a person's hands, an error is individual (identifiable, attributable, correctable). An agent repeats the same error on every file with the same profile, until someone notices. One wrong email to a student is corrected with a phone call; a thousand wrong emails become a crisis. The same report puts it this way: approving one bad output is manageable, while letting bad outputs through at scale compounds the risk¹.

The CNIL and the CIANum, in their exploratory note of 20 July 2026 on agentic AI, name two risks: responsibilities shared among several parties, which the three owners designated for each agent address (section 4), and cybersecurity risks extended to all the services connected to the agent, which limiting access addresses (section 3)².

2. How many agents do you have in service, and which ones?

You probably do not know. Agents come in through several doors: a team's prototype, a feature added to software you have already bought, a personal account. The answer lies in a register, one sheet per application.

In the header: the application, the three names (design, monitoring, sign-off), the person who keeps the sheet, the date on which the DPO was informed. Then one line per task given to an agent:

For the “Type of agent” column, four values are enough: 1) it answers on its own; 2) it reads your documents; 3) it reads, writes and sends; 4) it shares out work among several agents. The level of autonomy is defined in the next section.

Two rules make the sheet useful: an agent missing from the register has no right to operate, and neither does a task without an owner.

The sheet also serves for the AI Act. High risk is assessed use by use (Annex III, point 3: access and admission, the evaluation of learning outcomes, the level of education, exam proctoring), with obligations from 2 December 2027³. Add an “Annex III: yes or no” column and justify the answer in one sentence. Your internship agreements are not covered; your admissions process is.

3. What access should you give them, and what access never?

An agent is made of three elements: a model that reasons, what it is given to read, the tools it is granted. Set its autonomy according to the tools and access opened to it. The model's capability has no bearing on that choice.

Feng, McDonald and Zhang (2025) propose five levels of autonomy, defined by what remains with the person and decided at design time⁴:

1. 1)Operator: the person acts, the agent suggests.
2. 2)Collaborator: the agent produces, the person reviews everything and acts.
3. 3)Consultant: the agent acts, the person is consulted when a case falls outside the framework.
4. 4)Approver: the agent prepares the action, the person approves it before it goes out.
5. 5)Observer: the agent acts alone, the person reads the dashboard.

In a student records office: reading the FAQ and proposing an answer that an administrator copies is level 1 or 2; drafting a reply that an administrator reviews and sends themselves, level 4; replying directly to the student, level 5. Without a written setting, an assistant put into service can end up at level 5 without anyone having decided it.

Three rules are for your leadership to decide:

1. 1)The maximum level per type of action. For example: level 4 at most towards a student or an applicant; level 5 towards a colleague, with 10% of outputs reviewed; level 2 at most for anything that prepares a decision about a person. These thresholds are proposals, for you to set.
2. 2)Changing level. Moving up a level means opening one more access: a written decision, signed by a named person, reversible. Moving down is done on a simple decision by the person responsible for monitoring, the same day.
3. 3)Technical access. One account per agent, rights limited to its task and withdrawn when it is stopped, no password or key in an instruction. Ask your IT department which account each agent in service uses, and check that it is not the account of the person who built it.

What an agent never does: decide about a person. For an admission, a grade or an exemption, the agent prepares and records, the committee or the person in charge decides.

Among the control practices described by Shavit et al. (2023), five actions are to be checked for each agent in the register⁵: 1) restrict the agent's scope of action; 2) require human approval for sensitive actions; 3) be able to review why the agent did what it did; 4) attribute each action to an agent and its owner; 5) be able to stop it immediately.

Access opened today is still there tomorrow. In 2026, a model succeeds on its own, one time in two, at a task that takes an expert 16 hours; this duration doubles every seven months and would reach 64 hours by the end of 2027 if the curve holds⁶. Access granted this year would then serve, by the end of 2027, agents capable of carrying out on their own tasks four times longer: limit it to the task right now.

4. Who is accountable for what an agent does?

Three people, named per agent:

1. 1)Who designs: writes the instructions, decides on access, keeps every version.
2. 2)Who monitors: reads the log, sets the thresholds, can stop the agent.
3. 3)Who signs: is accountable for what goes out (the reply to the applicant, the certificate, the letter).

Write the name of a person, never a role. “The student records office” or “management” are accountable for nothing. After an incident, these three names tell you who wrote the instruction, who should have seen the error and who let the output go.

Two texts apply. For a public institution in France, any individual decision taken on the basis of algorithmic processing must say so to the person concerned (Code des relations entre le public et l'administration, Article L. 311-3-1)⁷. For a high-risk use, from 2 December 2027, the AI Act requires effective human oversight (Article 14) and makes the deploying institution responsible for assigning this oversight to competent people (Article 26(2)), keeping logs for at least six months (Article 26(6)) and informing staff before the system is put into service (Article 26(7))³.

The access review takes place at three intervals, as for accounts:

1. 1)Every week, the person who monitors reads the log. Three indicators are enough to start with: the share of outputs approved and the approval time (an administrator who approves everything in three seconds is no longer reviewing); drift (cases handled correctly last month that fail today with no change of instruction); out of scope (the requests the agent could not handle, which show where the rule is missing).
2. 2)Every month, the IT department and the DPO review the register, the access rights, the costs and the drift of all agents.
3. 3)Every year, or after an incident, an independent audit checks that the rules are applied, that the register is complete and that evidence of human oversight exists. An external inspection will probably ask for this evidence first.

That leaves the departure: stopping the agent, possible at any time, by at least two authorised people, one of whom is outside the team that built it. Do it once as a test before the agent goes into service.

This cycle overlaps with the four functions of the NIST AI Risk Management Framework (AI RMF 1.0, 2023): govern (the rules in section 3), map (the register), measure (the log that is read), manage (move up, move down, stop)⁸.