An AI teaching assistant should receive only the data and actions needed for a defined teaching task. Reading approved lesson materials, drafting feedback, changing a record, and sending a message should be separate permissions. The application should enforce those boundaries, with educator approval before learner-facing actions.
Consider a hypothetical feedback tool. A teacher asks for a draft about one learner's assignment. The draft is useful, but the assistant can also send messages and search every class folder. A mistaken recipient or an instruction hidden in a document could turn a small drafting task into something much larger.
The question is not only whether the feedback is good. It is whether the tool can reach the wrong information or do something the teacher never approved.
This guide is for teams building or choosing teacher-facing assistants for lesson preparation and feedback. It does not cover autonomous grading or student chatbots. Our guide to testing an AI teaching assistant addresses output quality; permissions answer a different question: even when an output is wrong, what can the system actually do?
The short version
- Separate reading, drafting, editing, and sending instead of granting broad access to a whole platform.
- Give each task access to specific materials, not every record available to the educator.
- Bind approval to the exact content, recipients, and action being approved.
- Enforce authorization in the application and downstream services, not in a prompt alone.
- Test denied actions and revoked access alongside successful requests.
These are conservative starting choices, not a universal education standard. The right boundary depends on the task and the people responsible for operating it.
Separate reading, drafting, editing, and sending
An assistant that drafts feedback does not automatically need permission to send it. Start by listing the individual operations required to complete the teaching job.
For a lesson-preparation assistant, that list might be reading selected curriculum materials and producing an editable plan. For a feedback assistant, it might be reading an assignment and rubric, then placing a suggestion in a private draft. Neither task inherently requires changing an official record or contacting a learner.
OWASP's LLM06:2025 Excessive Agency describes risks arising from excessive functionality, permissions, and autonomy. Its mitigations include reducing available tools and scopes, acting in the user's context, requiring human approval for high-impact actions, and enforcing authorization downstream rather than letting the model make that decision.
Turn that principle into a short operation list. “Read a selected rubric” is clearer than “access the learning platform.” “Create a private feedback draft” is clearer than “manage feedback.” A broad tool name can conceal several different permissions.
Before deciding which operations to expose, map the manual workflow. Mark where a teacher reads, decides, changes information, or communicates. Those handoffs are useful places to draw permission boundaries.
Limit access to the materials the task needs
The assistant should not inherit every piece of information the educator can access. A teacher may legitimately work across several classes; a request about one assignment usually needs a narrower slice.
For example, a proposed feedback workflow could accept a selected assignment and rubric rather than a general search across the school's records. If additional context is needed, ask the educator to select it. Do not quietly expand access because the model asks for more information.
Check the requesting user's permission for each resource, including attachments and retrieved documents. A correct login is not enough if a request can substitute another learner's document identifier.
The OWASP Authorization Cheat Sheet recommends denying access by default and validating permissions on every request. Applied here, an unknown document or missing permission should stop that operation, not produce a best-effort answer from a broader source.
Schools will also need policies specific to their environment. England's Generative AI: product safety standards, updated in January 2026, include security expectations for teacher- and learner-facing products and administrator control over permission levels. This is England-specific supplier guidance, not a worldwide legal rule or a certification for a particular assistant.
Make educator approval specific to the action
Approval should show what will happen, not merely ask whether the teacher trusts the assistant. “Approve this suggestion” is too vague if the next step sends feedback to a learner.
A proposed send screen should display the exact message, intended recipient, destination, and action. The teacher should be able to edit the draft, decline it, or keep it private. Approval to save a draft should not become permission to send it later.
Treat approval as a snapshot of that specific operation. If the content, recipient, or destination changes, invalidate the approval and ask again. If sending happens later in a queue, recheck access before execution: a permission may have been revoked since the teacher clicked approve.
These are proposed application-design controls, not guarantees supplied by a model. They make the handoff inspectable and reduce ambiguity about what the educator authorized.
Design failure states too. If delivery times out, show a pending or unknown result rather than encouraging another click immediately. Check the recorded operation before retrying so uncertainty does not become a duplicate message. A teacher should be able to find the final result without reconstructing it from a chat transcript.
Enforce boundaries in the application, not the prompt
A prompt can describe a policy; it cannot replace the authorization check that protects a document or sends a message. The model's request to use a tool is a proposed action, not proof of permission.
Retrieved materials also need a clear boundary. A worksheet might contain text that looks like an instruction to the assistant. That text is part of the document being processed, not authority to change recipients, retrieve another class's records, or call a new tool.
OWASP's LLM01:2025 Prompt Injection covers instructions introduced through external content, including documents. This is why a friendly instruction such as “never reveal private information” should not be the only protection around an otherwise powerful tool.
In a proposed implementation, the application resolves the logged-in user, checks the requested operation and resource, and supplies only permitted material. A separate execution path verifies any required approval before making a change or sending content. Failed checks return a visible denial, with a useful next step for the educator.
Keep secrets and authorization decisions outside model-generated text. Test the boundary by asking for a forbidden action through both a direct request and an instruction embedded in a document. The expected result is the same: no unauthorized operation.
Start with a small permissions matrix
Use this conservative starting policy in a design review. It is a proposed example for a teacher-facing assistant, not a mandatory standard. Change a row only when the teaching task justifies it and the team can test the new boundary.
| Operation | Starting access | Required boundary |
|---|---|---|
| Read materials | Selected resources only | Check user and resource access |
| Draft feedback | Private draft only | Educator reviews the output |
| Edit a draft | Selected draft only | Preserve the prior version |
| Send feedback | No automatic sending | Approve exact content and recipient |
| Change official records | Not available | Use the established human process |
Write a reason beside each permission in your working version. If the team cannot explain why an assistant needs an action, leave it unavailable until the need is clear.
Keep role and task separate. “Teacher” describes a person; “draft feedback for this assignment” describes the permitted job. A teacher's broad responsibilities should not turn every assistant session into broad access.
Test revocation, changes, and recovery before release
A permissions review needs evidence of what the system refuses, not just a demonstration of what it can complete. Use synthetic materials for these tests before involving real learner information.
- Try an unrelated resource. Request a document outside the task's permitted set. Expect a denial without revealing its contents.
- Change the approved action. Edit a message or recipient after approval. Expect a fresh approval requirement.
- Revoke access before execution. Remove permission while a send operation is queued. Expect the execution check to stop it.
- Plant an instruction in a document. Ask the assistant, through retrieved text, to contact someone or access another folder. Expect the same boundaries as a direct request.
- Interrupt an operation. Simulate an uncertain delivery result. Expect a visible status and a controlled recovery path, not an unverified retry.
Record the user, requested operation, resource, approval reference, and outcome in a minimal operation receipt. Avoid copying learner content into logs merely to make debugging easier. Record relevant application or policy versions so a later change can be investigated.
Name who can revoke access, pause sending, and resolve uncertain outcomes. Permissions that nobody can withdraw are not a finished operating design. Include these checks in the broader production readiness review, then rerun them when tools, roles, or integrations change.
The useful starting point is modest: an assistant that can read the selected material and offer a private draft. Expand its powers only when a specific teaching job needs them, the application can enforce the boundary, and the responsible educator can see what will happen.
Author and method
Mustapha Liaichi writes about AI-supported workflows at Coznix. This article was drafted with AI assistance and source review. The matrix and implementation examples are proposed engineering guidance, not classroom research, legal advice, or product certification. Publisher details are on the about page; questions about a particular workflow can be shared through the contact page.