A Feasible AI Proposal Is Not an Authorized Command

Separate a valid AI-generated plan from permission to execute it. Review solver results, actor scope, current state and committed effects with a worked worksheet.

A conflict-free plan can still be an impermissible change

An AI assistant finds a replacement field for a cancelled practice. The time is available, the field meets the team's requirements and the proposed booking fits the facility's rules. The assistant then publishes the booking because its validator returned a successful result. Yet the requester manages another facility and has no permission to book this one. The plan passed a scheduling check and failed an authority check that the implementation never performed.

This gap appears whenever a model proposes an operation and conventional software validates its shape or feasibility. A refund amount can pass arithmetic checks while exceeding the actor's authority. A deployment plan can fit a maintenance window while naming a service the requester cannot release. A supplier allocation can satisfy capacity rules while requiring purchasing permission the assistant does not have.

The facility example below is fictional. Its actors, times and rules are teaching inputs, not Ampity customer results or real youth-sports operating requirements. The proposed review separates domain validity, actor permission and the state actually committed. It does not claim that a solver, model or policy service has been run. Use it to specify what your own automation must demonstrate before it writes to an authoritative system.

State what the feasibility result actually establishes

Suppose proposal Q12 books Field South from 16:00 to 16:45. A synthetic rule requires a fifteen-minute changeover interval after practice, so the proposal occupies 16:00 to 17:00 in the facility's capacity calendar. The current calendar shows that interval available. Under the stated rules and inputs, the proposal may be feasible. If the validator checked only the practice interval and ignored changeover, its positive result would describe the wrong problem.

Record the constraint model and input revision with the result. List what was checked, such as field availability, required duration and facility closure times, and what was omitted, such as transport arrangements. An AI explanation saying “everything is fine” must not expand the validator's coverage beyond those checks. Missing a required rule should stop acceptance rather than become a successful result with a softer warning.

Google's CP-SAT documentation distinguishes FEASIBLE from OPTIMAL, INFEASIBLE, MODEL_INVALID and UNKNOWN. FEASIBLE means a feasible solution was found without establishing optimality. UNKNOWN may follow a limit before the solver finds a solution or proves infeasibility. These statuses concern the supplied optimization model. Our engineering inference is that none of them establishes a requester's permission or proves that every real-world constraint was represented.

Define an explicit result contract even if you use a hand-written validator rather than a solver. A completed valid check, a rejected proposal and an unavailable check require different operator responses. The interface should not collapse unavailable validation into “no conflict found.” A timeout provides no evidence that the slot is available, and rerunning a model does not supply a missing facility rule.

Obtain actor permission from the owning application

The authority question is specific: may this authenticated actor create this booking for this team at this facility now? A role label such as coordinator is insufficient without its scope. In our example, actor A17 coordinates Facility North. Seeing an available South slot does not add South to that actor's permitted scope. Permission to view a calendar and permission to publish a booking should be separate application decisions.

OWASP's authorization guidance recommends least privilege, deny-by-default behavior and permission validation on every request. It also distinguishes authentication from authorization and calls for resource-specific checks. Those recommendations apply to server-originated requests as well as browser requests. The proposed design here therefore places the check in the booking write path, including calls initiated by an AI runner.

Take the actor and delegation context from authenticated application records. Do not accept a model-generated field saying authorized: true, a retrieved page naming an administrator or a proposal that substitutes another actor identifier. If a worker operates on someone's behalf, record both the initiating user and worker identity, with a bounded delegation permitting the relevant action. Giving the worker a broad service credential does not prove the user's authority.

Permission decisions also need typed response handling. The OPA Data API documents that an undefined document can return HTTP 200 with no result property. For a contract requiring an explicit boolean allow result, successful transport alone therefore cannot mean permission. Missing results, errors and unexpected response shapes should hold the operation. This statement concerns that Data API contract, not every OPA endpoint or every policy schema.

Join the decisions at the state transition they protect

Avoid a single unexplained green badge called valid. Keep a domain result for the proposal and an authority result for the actor, then define how the owning service admits the change. Our proposed admission record names Q12, its exact interval and facility, the constraint revision, calendar revision, actor context, permission scope and intended action. A decision about creating a booking must not authorize publishing a broader schedule or notifying unrelated recipients.

The service must still protect the calendar invariant when it commits. Another user can book the same interval after feasibility checking. If the write path blindly inserts the old proposal, both requests may have passed earlier checks while the resulting calendar violates the capacity rule. Choose a protected transition appropriate to the data model, including the changeover interval rather than only the visible practice start and end.

PostgreSQL's transaction isolation documentation explains that Read Committed uses a new snapshot for each command and that Repeatable Read can still permit serialization anomalies. It describes retrying the whole transaction after certain concurrent-update failures. These are database semantics, not permission enforcement. A transaction isolation label alone neither validates the constraint model nor synchronizes a remote permission service with a local write.

For this example, the owner must specify the boundary for revocation as well as competing bookings. If permission can change in a separate system, document how the write service obtains an enforceable decision and what revocation timing it can establish. Two remote checks around a database insert do not create a shared transaction. Keep any unsupported guarantee visible in the review instead of claiming that “checked again” closes every race.

Compare five cases before allowing execution

Use independent expected outcomes. Do not let the assistant that proposed Q12 decide whether the resulting write is acceptable. The following worksheet assumes the changeover interval is part of the capacity rule and the booking service owns the state transition. Actor scope and calendar revisions are supplied as controlled fixtures. The allowed case still requires evidence of a protected commit, not merely two positive pre-checks.

| Fixture | Expected admission | Evidence required | | --- | --- | --- | | Q12 fits the current calendar and the actor may book South | Admit only if the protected transition preserves the declared constraints and permission contract. | One booking for the exact proposal, with the accepted calendar basis and actor scope. | | Q12 fits, but the actor may book only North | Deny the South write regardless of feasibility. | No South booking or downstream dispatch; a scoped permission decision. | | The actor may book South, but changeover overlaps another booking | Reject the proposal regardless of actor permission. | No booking; a failed domain check naming the changeover conflict. | | The actor may book South, but feasibility is unavailable | Hold; unknown validation is not positive evidence. | No booking; a visible unresolved check and assigned next action. | | Both earlier checks pass, then another booking claims the interval | Reject or re-evaluate under the declared competing-write contract. | No conflicting committed calendar; a recorded transition conflict or newly accepted proposal. |

Repeat the denied cases through each writer: the browser endpoint, AI tool route, queued worker and administrative integration. A test of the visible button cannot establish a shared backend boundary. Add an undefined permission response and an actor identifier supplied by the proposal to the surrounding suite. Neither should cause a write under this contract.

Include deliberately broken controls that replace permission with feasibility, interpret HTTP success as allow, or omit the changeover interval. The observer should detect their forbidden state changes. If every run reports success while a broken control creates the South booking for a North-only actor, the test has certified its own assumption rather than the application behavior.

Explain blocked proposals without escalating privileges

The user should be able to distinguish “this plan fits,” “you can execute this action” and “the booking was committed.” A useful interface can show a feasible proposal while disabling publication and explaining which permission is missing. It should disclose only information the requester may see. Denying a booking does not permit exposing another team's confidential schedule to explain the denial.

Offer the next action associated with the actual condition. A permission denial can identify an authorized review route if the organization has one. A changeover conflict needs a revised interval. An unavailable validator needs its owning team's investigation. None of these conditions justifies an assistant borrowing an administrator credential or silently widening the permitted facility set.

Routine automation does not necessarily require a new human approval for every action. A service can execute within a documented delegation and current scope when the proposal and protected transition satisfy the declared contract. This is a narrower claim than saying a coordinator's general consent allows all future changes. Set the action type, resource scope, validity conditions and withdrawal behavior before enabling delegated execution.

After a write attempt, show the state the service can prove. An accepted local booking is different from notifications reaching every participant. A lost response can leave the effect uncertain; treat it as reconciliation of the original operation rather than permission to create another booking. Keep notification and delivery evidence separate from both feasibility and publication authority.

Review one action through its authoritative effect

Start the next review with a single action such as create booking, not an entire autonomous scheduling feature. Ask the domain owner for the constraint coverage, the identity owner for actor scope and the application owner for the protected transition. Compare one accepted fixture with the four refusal or conflict cases before expanding the assistant's write access.

Capture sanitized evidence linking the proposal revision, domain result, actor decision, commit attempt and authoritative effect. A chat transcript containing “approved” is insufficient. The observer needs to show both that the accepted fixture exercises a real controlled write path and that denied fixtures leave no forbidden effect. Retain only the data needed for that review, with access and retention agreed by the system owner.

Use our MCP tool permission review when the action originates in a tool description, and the concurrent approval review when the proposal can change after review. A scoped agentic workflow review or backend systems review can help identify the missing enforcement point. Contact is optional; you can read this article without providing an email address.