Access Control Policy for AI-Enabled Work

Write an observable control objective

Begin with a specific outcome rather than a broad promise. For example: “Only approved members of the Customer Operations role may use the production support assistant with restricted customer records, and access must be removed within one business day after the role ends.” Record the system, data class, environment, identity provider, allowed roles, prohibited uses, approval owner, and review period.

The access-control policy and procedures control in NIST SP 800-53 Revision 5 calls for purpose, scope, roles, responsibilities, management commitment, coordination, implementation procedures, a designated official, and defined review and update events. NIST guidance is mandatory only where an applicable authority or contract makes it so; elsewhere it can be used voluntarily as a structured prompt.

Create a policy control card with:

Do not copy control text without resolving the organization-defined values. A statement such as “access is reviewed periodically” is not testable until the period, reviewer, population, evidence, and exception path are specified.

• protected systems, functions, models, data, and environments;
• allowed identity types and explicitly prohibited accounts;
• role and attribute rules for granting access;
• request, approval, provisioning, review, and removal owners;
• authentication and privileged-access requirements;
• logging, exception, incident, and escalation routes;
• evidence retained for each control step;
• review frequency and change-trigger events.

Sources: [1]

Translate policy into a decision table

For each sensitive action, create a row with subject, resource, action, conditions, decision, and evidence. Include normal access, privileged access, service accounts, temporary access, emergency access, third parties, and denied combinations. Keep the policy rule separate from the technical mechanism so a reviewer can see whether the implementation matches the intended decision.

The NIST glossary definition of access control centers on granting or denying requests to obtain and use information or services. The NIST guide to verification and test methods for access control policies and models warns that faulty policies, misconfiguration, and implementation flaws can create vulnerabilities, and that specifications should be checked for inconsistency and incompleteness. Use those ideas to test both the written decision and the configured result.

Require an explicit deny outcome when no rule applies. Test conflicts such as a contractor who belongs to an allowed team but has a prohibited employment type, or a service account that can invoke a model but should not export customer data. Document precedence rather than relying on whichever rule the platform evaluates first.

Sources: [2] [3]

Worked policy and test case

Consider an internal support assistant with three roles: Support Analyst, Support Supervisor, and Platform Administrator. Analysts may search redacted cases and draft responses. Supervisors may approve customer-facing responses and review quality samples. Administrators may configure the assistant but may not read unredacted case content unless a separately approved incident role is active.

The policy requires workforce identity, phishing-resistant authentication for privileged roles, manager approval, data-owner approval for restricted records, automatic removal on termination, quarterly recertification, and a 24-hour expiry for emergency access. It prohibits shared accounts and direct model access outside the managed application.

The evidence package contains the approved policy version, role-to-permission matrix, 23 current user records, 24 approval events for the quarter, two removal events, configuration export, authentication settings, denied-access logs, exception register, and recertification sign-off. One administrator still has an emergency incident role 30 hours after approval. The control owner records the exception, removes the role, investigates the expiry failure, and narrows the conclusion. The team does not describe access control as fully effective for the period.

An independent reviewer tests one allowed analyst action, one denied export, one supervisor approval, one administrator configuration change, both removals, and the expired emergency role. The reviewer compares the expected policy decision with the application and identity-provider records and records every mismatch.

Govern changes and exceptions

Define events that trigger review: new data classes, model or vendor changes, new integrations, material role redesign, audit findings, security incidents, legal changes, and repeated exceptions. Every exception should identify the rule being bypassed, reason, risk owner, compensating control, start and expiry time, affected resources, and closure evidence. Permanent exceptions belong in the policy model or should be removed; they should not accumulate in an informal list.

Keep policy approval separate from operating assessment. The policy owner approves the intended decisions. System owners implement them. Reviewers test design and operation against source records. Legal or compliance specialists determine jurisdiction-specific obligations. A policy based on NIST guidance is not automatically compliant with law, contract, or another standard.

Two Prune can create an assessment simulation in which a participant interprets a policy, reviews evidence, tests access decisions, and communicates exceptions. The resulting assessment evidence concerns performance in that simulation. It is not a security audit, a legal determination, a control certification, or an automated employment decision.