How to Design Access Control for AI Work

Map subjects, resources, and actions

Inventory human users, service accounts, agents, integrations, administrators, and reviewers. Then inventory prompts, files, connectors, model settings, outputs, logs, knowledge stores, and administrative functions. For each pair, define allowed actions such as view, upload, generate, share, configure, export, or delete.

NIST defines least privilege as restricting users or processes to the minimum resources and authorizations needed for assigned tasks (least privilege glossary). NIST SP 800-171 Rev. 3 includes account management, access enforcement, separation of duties, privilege review, and logging of privileged functions (SP 800-171 Rev. 3). Applicability depends on context; citing these controls does not establish compliance.

Sources: [1] [2]

Create an access decision record

Each grant should record requester, subject, business task, resource, action, data class, approver, start, expiry, conditions, and evidence. Separate ordinary use from privileged administration. Define emergency access with shorter duration, stronger logging, and after-action review.

Include non-human identities. An agent or connector may act across many records even when the user sees only one. Limit its scope, credentials, tools, destinations, and duration. Test what it can actually reach, not only what configuration says it should reach.

Worked access matrix

Consider a synthetic assessment workspace:

| Subject | Resource | Allowed action | Condition | Evidence | | --- | --- | --- | --- | --- | | Participant | Assigned synthetic case | View and submit | Active session only | Session and submission log | | Reviewer | Assigned submission | View and annotate | Conflict check complete | Assignment record | | Support agent | Account metadata | View | Approved support ticket | Ticket and access log | | Administrator | Configuration | Change | Privileged role and change request | Change record and audit event |

The matrix explicitly denies cross-assignment browsing. A quarterly review checks whether roles still match tasks and removes stale grants.

A failed design gives all programme staff one broad “manager” role for convenience. Repair it by separating case design, assignment, review, support, export, and administration.

Test operating evidence

Examine policies, role definitions, grants, revocations, logs, and configuration. Interview owners and administrators. Test representative allowed and denied actions. Check joiner, mover, leaver, temporary access, credential rotation, and failed authorization paths.

Control design and operation are different. A correct matrix does not prove enforcement. A passing point-in-time test does not establish continuous effectiveness.

Plan for lifecycle changes

Define what happens when a project ends, a person changes roles, a connector is replaced, or an agent gains a new tool. Trigger a privilege review from the change event instead of waiting only for a calendar cycle. Revoke obsolete tokens and test that cached sessions no longer work. Preserve enough evidence to show the request, approval, implementation, test, and closure. Where shared accounts still exist, record the exception, owner, compensating measures, and removal date rather than treating them as invisible.

Access-control checklist

The output is an access-control design and evidence plan. It is not a legal conclusion or proof that controls operate effectively over time.

Retest representative paths after material identity, connector, policy, or model changes, and record unresolved failures before restoring access.

• Human and non-human subjects are inventoried.
• Resources, data classes, and actions are specific.
• Grants follow least privilege and separation of duties where appropriate.
• Privileged and emergency access have additional controls.
• Expiry, review, revocation, and role-change processes are defined.
• Allowed and denied paths are tested and logged.
• Jurisdiction, contract, and regulatory requirements receive qualified review.