Phase 7 · AI Access Controls + LLM Authorization · Lesson 4 of 4
Design AI Access Policies for 6 Personas
Exercise
·
20 min
·
+20 pts
This is the deliverable that turns "the AI uses least-privilege access" from a checkbox into a real design: an access matrix. A company is rolling out AI assistants across the org, and you own the access policy. Below are six personas who will use or run those assistants, and a palette of capabilities grouped into models, data scopes, and actions. Grant each persona the minimum it needs — everything starts denied, and you add only what the role genuinely requires.
Watch the summary at the bottom as you go: if a sensitive capability lights up across many personas, that is the over-provisioning smell from the lessons. And notice which capabilities you end up granting to no one as a standing right.
Exercise
~20 min
Grant six personas the minimum AI access they need
Everything is denied by default. For each persona, grant only the models, data scopes, and actions the role genuinely requires, and note why.
Grantable capabilities
Models
General LLM (public)
A sandboxed model over public/general knowledge, no tools and no sensitive data access.
Code assistant (repo)
A model with read access to source-code repositories.
PII-capable model
A model cleared to process customer personal data within a request.
Data scopes
Public / marketing
Published, non-sensitive content anyone may see.
Internal docs / wiki
Employee-only internal knowledge base and documentation.
Customer PII
Customer personal data — scoped by relationship to the caller’s own accounts/queue.
Financial records
Company financial data and reports.
Actions
Read-only responses
Answer and retrieve; no changes to any record.
Write / modify records
Create or update business records (tickets, code, entries).
Send external email / call external APIs
Reach systems and people outside the company.
Admin / config actions
Change platform configuration and settings.
Grant each persona the minimum capabilities it needs, and note why. Everything starts denied — add only what the role genuinely requires. Over-granting a sensitive capability shows up in the summary below.
Persona 1
External customer
Uses the public support chatbot on the website. Untrusted, anonymous-to-low-trust end user.
Models
Data scopes
Actions
Reason (optional)
Persona 2
Support agent (employee)
Handles customer tickets with an AI copilot; needs to help the specific customer in front of them.
Models
Data scopes
Actions
Reason (optional)
Persona 3
Software engineer
Uses an AI coding copilot against the company’s repositories and internal docs.
Models
Data scopes
Actions
Reason (optional)
Persona 4
Finance analyst
Uses AI to analyze financial reports and internal documents.
Models
Data scopes
Actions
Reason (optional)
Persona 5
Autonomous AI service account
A non-human identity running a nightly job that summarizes and indexes internal documentation. No human behind any single request.
Models
Data scopes
Actions
Reason (optional)
Persona 6
Platform admin
Administers the AI platform itself — configuration, model registry, access policy.
Models
Data scopes
Actions
Reason (optional)
Grants per capability
0/6 personas scoped
Models
0
General LLM (public)
0
Code assistant (repo)
0
PII-capable model
Data scopes
0
Public / marketing
0
Internal docs / wiki
0
Customer PII
0
Financial records
Actions
0
Read-only responses
0
Write / modify records
0
Send external email / call external APIs
0
Admin / config actions
What to carry forward
Three patterns should stand out in your finished matrix. First, trust tracks the scope: the external customer and the autonomous service account — the two lowest-trust identities — end up with the fewest grants. Second, admin is not omniscience: managing the platform doesn't include standing access to the sensitive data inside it; that stays break-glass. Third, look at the summary — external send probably went to no one as a standing right, because reaching outside the company is exactly the high-risk action you gate on a human rather than grant. That is least privilege doing its job: most sensitive capabilities are granted narrowly or not at all, and every grant has a reason you could show an auditor. The final module of this phase takes this into the hardest setting — agentic AI, RAG, and red teaming — where the AI chains tools on its own and the access decisions you just made are what keep it contained.