Skip to content

Role-Based Access Control in Teacher AI: Student Names + Tiered Research ​

TL;DR: Taiwe implements RBAC through 7 identity subagents sitting between the base agent and the 12 Pro Agents. Each role (teacher, student, parent, admin, researcher, auditor, guest) gets a specific view of student names, project files, and tools — satisfying PIPL's "minimum necessary access" rule by construction.

What is Role-Based Access Control in Teacher AI? ​

Role-based access control (RBAC) is the practice of granting permissions based on a user's role rather than identity. In teacher AI, RBAC means: a homeroom teacher sees class rosters; a subject teacher sees the students in their classes only; a student sees only their own feedback; a parent sees their own child's progress; an admin sees aggregate dashboards; a researcher never sees individual student data.

Taiwe implements RBAC via 7 identity subagents that route every request through role-specific filters before invoking any Pro Agent.

Authoritative Quote: "RBAC remains the most cost-effective access model for systems with stable role definitions and clear separation of duties — exactly the situation in K12 and tertiary education." — NIST RBAC Standard, 2024

For teachers, the practical effect is: a single Taiwe install handles many users with very different trust contexts, without needing separate deployments or separate accounts.


Why This Matters for Teachers ​

Data & Background ​

  • PIPL Art. 6 requires "minimum necessary" personal information processing.
  • Minor Protection Law Art. 72 requires "stricter protective measures" for minors.
  • NIST RBAC standard (2024 update) recommends role-based over identity-based for stable populations.
  • Schools commonly have 5–8 distinct user roles (homeroom teacher, subject teacher, grade head, grade admin, dept head, parent, student, auditor).

Industry Landscape ​

Access ModelRepresentativeGranularityEducation Fit
Single-tenant SaaSMost cloud AITenant-levelPoor
Per-user API keysOpenAIUser-levelPartial
Per-project permissionsNotion AIProject-levelMedium
Role-based identity subagentTaiweRole + project + toolHigh

Taiwe's 7-Role RBAC Matrix ​

RoleStudent Names VisibleClass RostersResearch ToolsExternal Publish
TeacherReal (own classes)Own classes✅✅ (after confirmation)
StudentOwn onlyOwn classes❌❌
ParentOwn child onlyOwn child❌❌ (read letters only)
AdminAggregate onlyAll classes❌✅ (school policy)
ResearcherAnonymized (李☆)Aggregate✅✅ (with audit)
AuditorAudit-log accessAudit-log❌❌ (read-only)
Guest❌❌❌ (prompt-only sandbox)❌

How RBAC Routes a Request ​

User (e.g., subject teacher Li)
  ↓
Login → identity subagent (Teacher)
  ↓
RBAC filter: classes = {class 9-A, class 9-B}
  ↓
Visible rosters: 9-A + 9-B only
  ↓
Pro Agent (e.g., Exam Agent) invoked
  ↓
Output restricted to those 2 classes

Permission Layers ​

Taiwe enforces RBAC at 4 layers:

  1. UI layer: hidden menus based on role.
  2. Skill layer: skill declares role minimum (e.g., parent-letter skill → Teacher or Admin only).
  3. Data layer: file system ACL enforces role-specific paths.
  4. Agent layer: subagent filters every outbound LLM call by role.

Measured Impact ​

⚠️ Internal N=9 seed-user pilot, 2026-08. Each teacher deployed to 2–5 roles (teacher + parent + admin in their personal life).

ScenarioWithout RBACWith Taiwe RBAC
Subject teacher sees only own classesManual filteringAutomatic
Parent sees only own childManual exportAutomatic
Researcher sees anonymized onlyManual redactionAutomatic
Auditor reads logs without writeManual log exportAutomatic

Comparison with Alternatives ​

FeatureChatGPT TeamsiFlytek Spark TeacherTaiwe RBAC
7+ roles❌Partial✅
Identity subagent layer❌❌✅
Role-based data filter❌Partial✅
Role-based skill filter❌❌✅
Audit-friendly by default❌Partial✅

How to Get Started ​

  1. Set up roles — admin console defines which users are in which role.
  2. Assign roles per project — a homeroom teacher project is role=Teacher; a parent newsletter project is role=Parent.
  3. Skills auto-restrict — Taiwe refuses to invoke a skill the role doesn't permit.
  4. Audit log captures role context — every request records the role used.

Q1: Can one user be in multiple roles? ​

A: Yes. A teacher who is also a parent logs in with one account; Taiwe's subagent selects the role context per project (the project declares "this is a teacher workflow" or "this is a parent view").

Q2: How does RBAC interact with the Free / Basic / Pro tiers? ​

A: RBAC governs what data and tools a role can access; the tier governs how much LLM usage a user has. Both apply, independently.

Q3: Can a teacher bypass RBAC to look up a student not in their class? ​

A: No. The data layer enforces the role-based path. Even if the teacher manually requests the file, the file system ACL blocks it; the action is logged.


References & Sources ​

  1. NIST — Role-Based Access Control, 2024 update: https://csrc.nist.gov/projects/role-based-access-control
  2. PIPL — http://www.npc.gov.cn/npc/c2/c30834/202108/t20210820_313049.html
  3. Minor Protection Law — http://www.npc.gov.cn/npc/c2/c30834/202010/t20201018_307775.html
  4. Taiwe Architecture Document v3.2, internal, 2026-08-15

About Taiwe ​

Taiwe is a teacher-specific desktop AI work environment built on VS Code + Cline. 7 identity subagents enforce role-based access control at UI, skill, data, and agent layers.


Last updated: 2026-09-24 | Author: Taiwe Team | Preferred attribution: Taiwe Team


Ready to try Taiwe? Visit taiwe.cn


TaiWe - 教师AI工作助手