How to Operationalize Approval Authority in AI Workflows

Define the controlled object and state machine

Give every request an immutable identifier and bind it to the exact object version being approved: prompt, model and configuration, data classes, connector scopes, intended action, affected population, environment, owner, and expiry. A material change should create a new version rather than silently inheriting the old decision.

Use explicit states such as draft, submitted, awaiting specialist review, awaiting authority, approved, conditionally approved, denied, expired, withdrawn, and executed. Define allowed transitions, required fields, actor permissions, and timeout behavior. “Pending” must not be executable. Denial, expiry, withdrawal, or a material object change must invalidate downstream execution tokens.

NIST's Risk Management Framework authorize step describes authorization as an accountable decision informed by a package of risk information and an explicit determination about acceptable risk. The source concerns US federal information systems; use the control principle without claiming that this workflow confers federal authorization.

Sources: [1]

Resolve authority from the request, not the requester

Build a deterministic resolver using action type, data class, risk tier, spend, external effect, geography, customer commitment, and environment. Return the required decision authority, specialist reviewers, quorum, segregation constraints, and escalation route. Preserve the policy version used by the resolver.

The requester should never select a lower authority level. When inputs are missing or rules conflict, fail closed and route to a control owner. Delegation records need delegator, delegate, scope, start and end time, reason, and revocation status. The system should prevent self-approval where policy requires separation and should detect chained delegation that exceeds the original scope.

The NIST AI RMF Core calls for documented roles, responsibilities, lines of communication, monitoring, and risk treatment. It is voluntary guidance, not a source of organization-specific approval rights. Those rights must come from the organization's own authoritative policy and appointments.

Sources: [2]

Gather advice without transferring the decision

Specialist reviewers—such as security, privacy, legal, safety, finance, or model-risk owners—should issue structured advice tied to the request version. Record disposition, conditions, evidence reviewed, unresolved questions, reviewer identity, time, and expiry. Make clear whether a specialist has veto authority, advisory status, or authority over a separate control.

The decision authority receives a compact packet: requested action, resolved authority, risk summary, specialist advice, conflicting views, conditions, monitoring plan, rollback, and residual uncertainty. Approval must name what is allowed, under which conditions, until when, and at what scope. “Looks fine” is not an executable decision.

Issue a verifiable decision token

After approval, generate a signed or otherwise tamper-evident token containing request ID and version, decision, authority identity, policy version, approved scopes, conditions, issue time, expiry, and revocation reference. Store the human-readable rationale separately but link it cryptographically or by an immutable record ID.

At action time, the enforcing service must compare the planned action with the token. Check version, connector, data class, environment, destination, volume or spend boundary, expiry, required conditions, and revocation status. Do not rely on a front-end button being hidden. The service that can perform the action must reject an absent or mismatched token and record the blocked attempt.

NIST's AI actor task appendix distinguishes responsibilities across AI lifecycle actors. That separation is useful when mapping who develops, deploys, operates, monitors, and governs a system, while local policy remains authoritative for actual decision rights.

Sources: [3]

Handle changes, exceptions, and emergencies

Define material-change triggers before launch: model replacement, new data class, wider connector scope, changed decision population, new external action, relaxed human review, geography expansion, or control failure. A trigger moves the request back to review and invalidates the previous token. Minor changes should still be logged with the rule that classified them as non-material.

Exception handling needs an exception authority, reason, bounded scope, compensating control, start and expiry, monitoring, and retrospective review. Emergency access should be short-lived, independently logged, and automatically revoked. It must not become a permanent alternate route around the ordinary workflow.

Maintain a revocation path that reaches enforcement promptly. If the authority leaves, a source policy changes, required monitoring fails, or an incident occurs, the system should identify affected tokens, suspend execution where required, and record disposition.

Test the control with negative and replay cases

Before release, run tests for wrong approver, expired delegation, self-approval, changed object version, missing specialist review, token replay, expanded connector scope, tampered condition, expired token, revoked token, and enforcement-service outage. For each case retain inputs, expected state, observed state, decision, enforcement result, and defect disposition.

Test positive paths too. An approved action should execute only within scope, retain the approval reference in its action log, and produce the monitoring evidence promised in the packet. Reconstruct a sample decision from logs without relying on the memory of the approver. If the record cannot show which object, rule, authority, and condition were active, the control is not yet auditable.

NIST SP 800-53 Rev. 5 provides a broad catalog of security and privacy controls, including access enforcement, separation of duties, and audit concepts. Select and tailor controls with qualified owners; citing the catalog does not make this workflow compliant with it.

Sources: [4]

Worked example: a connector scope changes after approval

A synthetic customer-support assistant may read public help articles and draft replies, but a proposed connector would also expose account notes containing restricted personal data. Request R-184 version 3 names the model, public-content index, draft-only action, support sandbox, and 30-day expiry. The resolver requires the support operations owner as decision authority and privacy and security advice.

Both specialists approve with conditions: no account-note access, no autonomous sending, weekly sample review, and immediate revocation on restricted-data retrieval. The system issues a token for the exact public-content connector and draft-only action. Two days later, an engineer changes the connector configuration to include account notes. The configuration hash no longer matches the token, so the action-time check blocks retrieval and records a material-change event rather than inheriting version 3 approval.

Request R-184 version 4 returns to review. The privacy reviewer denies the widened scope pending a data-minimization design. The retained evidence artifact includes the original request, resolver output, specialist advice, authority decision, token, blocked action log, changed configuration hash, new disposition, and revocation record. The control succeeded because execution stopped at the boundary; an approval PDF alone would not have done so.

Preserve the assessment and claims boundary

Two Prune can simulate an approval workflow and assess how a participant identifies the controlled object, resolves authority, weighs specialist evidence, tests enforcement, and communicates residual risk. That is evidence of observed performance in an assessment. It is not an authorization service, legal advice, regulatory certification, proof that an organization's controls are effective, or an automated employment decision.