Approval Authority Policy for AI-Enabled Work

State the control objective and scope

Use an observable control objective: governed AI actions occur only after a current authorized decision for the exact object, version, scope, and conditions; rejected, expired, changed, or unauthorized requests cannot proceed. Name the accountable policy owner, approving authority, effective date, review date, and systems and business units in scope.

Define the governed objects rather than using a vague phrase such as “AI approval.” Objects may include a use case, model or service version, data class, connector, workflow, external output, deployment stage, residual-risk acceptance, exception, or restart after an incident. For each decision class, name the consequence and the threshold that invokes a different authority.

The NIST AI RMF Core says leadership should take responsibility for AI risk decisions and that roles, responsibilities, communication, and human-AI oversight should be documented. Its AI actor-task appendix distinguishes governance, oversight, procurement, domain, operation, and evaluation work. These voluntary resources support clear responsibility but do not establish a legal allocation of authority for an organization.

Sources: [1] [2]

Publish the authority schedule and evidence minimums

Attach an authority schedule with one row per decision. Include: prepares, advises, verifies, recommends, approves, executes, monitors, and is informed; scope limits; value, data, geography, impact, duration, and risk thresholds; permitted delegates; incompatible duties; evidence minimums; approval lifetime; escalation; and system enforcement point.

The policy should require an approval packet containing a stable request ID, decision requested, current object version or hash, intended use, people and systems affected, data boundary, material risks and controls, specialist advice, unresolved issues, test evidence, recommendation, conditions, approver identity, decision time, expiry, and next review. A status label without those bindings is not adequate evidence.

NIST’s RMF authorize step describes a senior official making a risk-based authorization decision from an authorization package and recording terms and conditions. Use this as a design reference for evidence-bound decisions, not as a claim that an ordinary organizational approval is a federal authorization to operate.

Sources: [3]

Define the operating procedure

The requester submits the packet through the governed route. The workflow resolves the current authority schedule, verifies role assignment and thresholds, checks incompatible duties, and obtains required specialist advice. The approver records approve, conditionally approve, reject, or return for more evidence. The execution system verifies the current decision and conditions at action time. Monitoring then records changes, expiries, incidents, and threshold breaches.

Material change invalidates approval. Define material change for each object: a new model or supplier, expanded purpose, broader data class, changed integration, higher-consequence population, modified control, or exceeded threshold may require a fresh decision. Do not let an approval for a public-data pilot silently authorize confidential data or production scale.

Delegation must identify decision classes, limits, delegate, start, expiry, conflicts, and revocation. Emergency authority must be narrow, time-limited, logged, followed by prompt notification and retrospective review, and unable to become standing authority by repetition. Technical permissions should match the policy; where they cannot, compensating checks and an accountable remediation date are required.

Control exceptions and test operation

An exception request must identify the exact policy clause, business need, duration, affected object, incremental risk, compensating controls, owner, approver, expiry, and closure evidence. The person seeking an exception should not be the sole approver. Expired exceptions must stop the governed action or trigger the documented safe route.

At least each review period, reconcile the complete request and execution populations. Test high-consequence, rejected, conditional, delegated, emergency, changed, and threshold-adjacent cases. For each sampled event, connect request, valid authority at decision time, decision packet, and downstream enforcement. Test controlled negative cases such as an absent approver, expired delegate, changed object, expanded data class, and expired condition.

The current NIST SP 800-53 Revision 5 provides a broad catalog of security and privacy controls, including policy, access-control, assessment, authorization, and accountability concepts. Tailoring those concepts does not make this policy a NIST assessment, certification, or evidence of legal compliance.

Sources: [4]

Worked policy decision

A synthetic organization uses an AI assistant to summarize public product documentation. The authority schedule lets a product owner approve public-data pilots below a fixed cost threshold after security and privacy advice. Confidential customer notes require executive residual-risk acceptance; production connectors require security approval; external release requires a content owner.

The product owner approves pilot version 1.3 for public documentation for 60 days. The packet binds the decision to the model version, public-data connector, review procedure, cost ceiling, and stop conditions. Two weeks later, an operator requests confidential support notes to improve answer quality. The workflow detects the changed data class, invalidates the existing approval, and routes a new packet to the executive and privacy owner. No connector change can execute from the old decision.

An urgent service incident then requires temporary disabling of AI-generated suggestions. The operations lead uses narrow emergency authority to suspend the feature for 24 hours; this reduces risk and is logged for after-action review. Restoring the feature still requires the original conditions to remain current. The policy record retains the request IDs, object hashes, decisions, execution logs, emergency action, exception status, and next review date.

The example demonstrates the intended route, not control effectiveness. Effectiveness would require reconciled operating populations, event testing, exception analysis, remediation, and retest over a defined period.

Maintain, review, and retire the policy

The policy owner reviews the authority schedule after role, system, supplier, data, regulatory, or organizational change and on the stated periodic date. Review evidence should include current assignments, delegation and exception registers, population reconciliation, negative tests, incidents, overdue conditions, permission mismatches, and repeat failures. Changes receive a version, rationale, approval, effective date, communication record, and implementation test.

Retire obsolete authorities and revoke associated system permissions. Preserve prior versions and the decisions made under them for the applicable retention period. Qualified legal, regulatory, privacy, security, employment, and contractual owners should review requirements for the relevant jurisdiction and context.

Two Prune can simulate policy application and observe how a participant classifies a decision, assembles evidence, checks authority, handles exceptions, uses AI support, and communicates conditions. That produces assessment evidence about observed work in the simulation. It is not a legal opinion, compliance determination, security certification, control attestation, proof of control effectiveness, or an automated employment decision.