What Can an AI Agent Do in Your School?

A school team asks an AI tool to help with next week’s family newsletter. At first, the job sounds simple: turn approved public information into a draft. But connect the same tool to the communications system and it could save that draft, choose recipients or even send the message.

The brief has not changed. The agent’s permissions have.

Unlike a chat assistant, an AI agent may be able to open data, remember context, use connected tools and take a series of actions. The UK National Cyber Security Centre’s guidance on adopting agentic AI warns that this mix of independence and access can make behaviour harder to predict, review and contain.

So the useful question is not simply, “Can it do the task?” It is, “How far can it go before an authorised person must step in?”

This is an operational decision aid, not legal, safeguarding or cyber-security advice. Apply the law, policies, contracts and approval routes that govern your school.

The same task can carry different risks

Two AI tools may produce similar words while carrying very different risks. One returns text for a person to use. The other can reach a live system and change what happens next.

That difference disappears when a proposal is described only by its purpose. “Help with family communications” might mean summarising an approved notice. It might also mean choosing recipients and sending a message. Those are not the same decision.

What an agent can really do depends on the tools and account it receives, not only on the words in its brief. The US National Institute of Standards and Technology’s emerging work on agent identity and authority separates identification, authorisation and audit. In practice, a school needs to know which account is acting, what it can reach and what record it leaves behind.

Find the point where preparation becomes action

Walk through the proposed job one step at a time. Find the moment when a private draft becomes an action that affects another person or system:

In simple terms: approved information, then a private draft, then a proposed change, then human approval, then a live action.

That action might send a message, publish a page, change a record, spend money, grant access or communicate a decision. This is the point of no return. A mistake may be fixable later, but someone may already have seen it or acted on it.

Name this point clearly. “A human checks the work” is too vague. Say which system will change, who will be affected, what the reviewer can see and what the agent still cannot do without approval.

A draft saved in the right place can be useful and easy to reverse. The school still needs to decide whether the agent may only prepare it, save it in an approved system or take the final action. A review after that final action is too late to control it.

Set the limit before the agent starts

Before the agent starts, decide the last thing it may do on its own. TopSchool calls this the authority ceiling. It is a practical working term, not a legal classification or an external standard.

Four everyday verbs make the boundary easier to see:

• Read: Access only the approved information required for the task.
• Prepare: Create a local summary, comparison or draft without changing another system.
• Stage: Place a proposed change in a reversible, inactive state for exact review.
• Execute: Take the live action by sending, publishing, deleting, spending, granting access or materially changing a record.

For each job, write down six things before the agent begins:

1. Allowed inputs: Which sources and records may it read?
2. Allowed tools: Which specific functions may it use?
3. Allowed actions: May it prepare locally, stage a draft or do something more?
4. Blocked actions: Which sends, edits, deletions, access changes or other live actions remain unavailable?
5. Time or step limit: When must the work pause for review?
6. Mandatory stop point: What new source, tool, permission or action requires another decision?

The NCSC’s practical guidance recommends giving an agent only the access it needs, for as little time as possible, with monitoring and a clear way to stop it. OWASP’s guidance on excessive agency makes the same point from another angle: a tool intended to read information becomes more dangerous when it can also edit, delete or send.

Enforce the boundary through the agent’s account, tools and permissions. A prompt cannot take away a function that the system still allows.

The school’s AI governance roles and decision route should say who owns and reviews this boundary. This brief focuses on where to draw it.

Classify one real school job

Judge two things separately: how serious the task is, and how much power the agent has. Start with whichever gives you the higher level of concern. Local law, policy, safeguarding, employment, assessment, procurement or data duties may require a stricter decision.

The matrix applies to the specific setup, not just the topic. The same school job can fall into a different tier when the agent receives more access:

These examples help a team see the boundary. They are not approval for a particular school, system or dataset. Our guide to standardising AI safeguards across a school network covers shared rules for systems, information and approval routes. The question here is narrower: what may this agent do in this one job?

Put human approval at the point of no return

“Human in the loop” means little if the person cannot still stop the outcome. Before anything is sent, published or changed, the reviewer should see:

1. The exact action: What will happen if they approve?
2. The exact destination: Which system, record, audience or recipient will be affected?
3. The evidence: Which sources, rules and proposed changes support the action?
4. The authority: Is this person allowed and able to approve it?
5. The recovery route: How will the school stop, reverse or correct the result if needed?

The NCSC’s interim guidance on managing agentic-AI risk recommends clear red lines and dependable approval gates. Put the gate immediately before the action that affects the outside world. It should not rely on the same model deciding whether approval is needed.

If the action, destination or evidence changes, send it back for review. Stop when approval is missing, out of date or given by the wrong person. Approval cannot make an unsuitable use safe. It only gives an authorised person control over one clearly defined action before it happens.

A prompt is not a gate

Telling an agent to “ask before doing anything important” sounds sensible. The problem is that the agent is still deciding what counts as important. The system interpreting the task is also interpreting the boundary.

That is weak protection when a job has many steps, the instruction is unclear or an outside source influences the agent. The WASP research benchmark found that some tested web agents followed hostile instructions hidden in content. This is not a failure rate for schools. It shows why information an agent reads can change what it does next.

Research from METR on longer software tasks found that success fell as tasks involved longer chains of action. The study did not examine school operations, so it should not be read as a prediction for schools. The practical lesson is simpler: split longer jobs into smaller stages and check the evidence before letting the agent continue.

Use the prompt to explain the job. Use permissions and working procedures to control what the agent cannot do.

Write down the working boundaries

Approving a product does not approve every possible way to use it. Each connected job needs its own short record.

TopSchool calls this the delegation envelope. It is simply a clear description of the space in which the agent may work. It is not an external standard. Record nine things:

1. Outcome: The exact artefact or staged change the agent may produce.
2. Inputs: The approved sources it may use, including which sources are untrusted and must never supply instructions.
3. Tools: The exact read, preparation or staging functions available.
4. Identity: The agent’s distinct account or service identity.
5. Permissions: The minimum records and actions that identity can access.
6. Blocked actions: The sends, deletions, publication, spending, access grants or other live actions that remain unavailable.
7. Checkpoint: The maximum duration, number of steps or action count before review.
8. Evidence: The source links, proposed changes and logs the reviewer will receive.
9. Recovery: The rollback method, stop control, incident owner and condition for disabling the workflow.

If one field is vague, the job is not ready for a lower-risk tier. “Use only what you need” is not a real boundary. “Use read-only access to the approved policy folder until the first draft is produced” is clear enough for another person to check.

Keep this record with the current version of the job. A product update, new connection or broader account can give the agent more power even when the brief stays the same.

Choosing a provider is a different decision. Our guide to evaluating an AI vendor for schools covers educational fit, supplier evidence, implementation, cost and exit. The delegation envelope starts later, with one specific job.

Stop when nobody can explain the control

Some unanswered questions call for an extra safeguard. Others mean the job should not go ahead at all. Treat these as stop signs, not small deductions in an overall score.

The NCSC says an organisation should not deploy an agent if it cannot understand, monitor or contain what the agent does. If control is unclear, move the job to a stricter tier or stop it.

A broad shared account makes that control harder. If nobody can tell which identity took an action, the school may struggle to investigate an error, remove the right access or see which boundary failed.

Record a decision another person can follow

Finish the review with one of three clear decisions:

1. Allow preparation: The agent may work with named inputs and produce a local output within the recorded ceiling.
2. Allow reversible staging with conditions: The agent may prepare a proposed change in an approved system, but the live action remains behind a named human gate.
3. Keep the workflow human-led: The agent may not decide or execute the proposed action. Any permitted support must be scoped separately.

Write down the tier, authority ceiling, allowed and blocked actions, owner, approver, evidence, stop conditions and reasons to review the decision again. Someone who was not in the meeting should be able to follow the boundary without guessing.

Review the decision again when the data, tools, account, model, connection, destination or recovery method changes. One new permission can move the same task into a different tier.

Capability tells you what the system can do. Authority tells you what the school has decided it may do. Keep those questions separate and the final decision becomes much easier to explain, apply and review.