Access-Control Design
Template Library
Access-Control Design Template
Define roles, permissions, protected actions, protected data, denied behavior, review authority, escalation, and audit evidence.
ES-105
Access Control
Authority + Evidence
Template purpose
Use this template to define who may do what, under what conditions, and what evidence is produced.
Access control is not only a security feature. It is part of accountability, governance, privacy, operational control, and human oversight.
Project
<Project name>
Document control
| Field |
Value |
| Artifact owner |
<owner> |
| Primary reviewers |
<reviewers> |
| Status |
<draft / in review / accepted / revised> |
| Last updated |
<YYYY-MM-DD> |
| Related Engineering Stage |
ES-105 — Detailed Design |
| Project workspace target |
docs/project-workspace/design/access_control_design.md |
Role register
| Role |
Description |
Allowed Actions |
Restricted Actions |
Evidence / Audit Notes |
<role> |
<description> |
<actions> |
<restricted> |
<notes> |
Permission matrix
| Action / Resource |
Role 1 |
Role 2 |
Role 3 |
Evidence Produced |
<action or resource> |
<allow / deny / conditional> |
<allow / deny / conditional> |
<allow / deny / conditional> |
<evidence> |
Protected actions
| Action |
Required Role / Condition |
Denied Behavior |
Evidence |
<action> |
<role/condition> |
<behavior> |
<evidence> |
Protected data
| Data |
Access Rule |
Rationale |
Evidence / Audit |
<data> |
<rule> |
<rationale> |
<evidence> |
Human approval and override
| Action |
Approval Required? |
Approver |
Override Rule |
<action> |
<yes / no / conditional> |
<approver> |
<rule> |
Use this section if AI can access data, produce outputs, recommend actions, or influence workflow behavior.
| AI Capability / Interaction |
Allowed Data |
Restricted Data |
Human Review |
Evidence |
<AI capability> |
<data> |
<data> |
<review> |
<evidence> |
Denied access behavior
<What happens when access is denied, expired, invalid, escalated, or disputed?>
Audit and monitoring
| Event |
Evidence Produced |
Reviewer / Consumer |
<access attempt, denied action, approval, override, role change> |
<log, record, alert> |
<reviewer> |
Open access questions
| ID |
Question |
Owner |
Needed By |
| ACQ-001 |
<question> |
<owner> |
<date or stage> |
Review checklist
- [ ] Roles are defined.
- [ ] Protected actions are identified.
- [ ] Protected data is identified.
- [ ] Permission rules are explicit.
- [ ] Denied behavior is defined.
- [ ] Human approval and override are addressed.
- [ ] AI-related access rules are addressed where relevant.
- [ ] Audit evidence is defined.
Continue to AI Interaction Design
Define AI input rules, output handling, human review, acceptance, rejection, and failure behavior.
Open AI Interaction Design →