AI Agent Governance Architecture: Selection vs Authorization

AI agent governance architecture works only when creative selection and execution authorization remain separate decisions in the interface, data model, permissions, and audit trail.

We found that boundary while reviewing Eclipse, an internal Nocturnal product. Eclipse has a Creative Room for briefs, exploration, candidates, repairs, and the CreativeHandoffV1 artifact. It also has a Control Room for deterministic runs, receipts, approvals, BrandLab governance, and release gates. A candidate selected in the Creative Room can move forward for review. That selection grants no authority to run tools, publish work, spend money, or create any other external side effect.

Proof scope: Internal Eclipse architecture checked July 28, 2026. The diagram exposes the implemented ownership and authority contract. It makes no claim about a client deployment.

The expected invariant#

The governing rule is simple: creative selection cannot cause deterministic execution or an external side effect.

That rule has to hold through every path, including retries, repairs, stale browser tabs, automation calls, and direct API requests. A disabled button provides no protection if the backend accepts a selected candidate as an executable command.

The ownership map makes the invariant concrete:

The ownership map is the architecture. Every state has one owner, every permission has a scope, and every side effect leaves evidence.

Where the ambiguity appeared#

The pressure appeared before a harmful side effect occurred. During internal review, selection, approval, run, and release language sat close enough together to invite the wrong mental model.

A creative operator could select a candidate and reasonably believe the system had approved it for production. An engineer could read the selected candidate as the default input for an automatic run. A repair could change the candidate after another operator reviewed an earlier version. A retry could repeat a side effect if the authorization and receipt were tied to a loose project state instead of an exact handoff revision.

The words made the problem worse. "Approve" can mean "this is the direction I prefer," "this input is safe to process," "run the deterministic pipeline," or "release the result." Those are four decisions with different risks.

No external incident was needed to prove the flaw. Ambiguous authority is already a governance defect because the system cannot reliably explain which decision unlocked which action.

Why one combined surface is dangerous#

Putting ideation and execution into one busy control surface feels efficient. It compresses the workflow on screen while also compressing distinct states in the operator's head.

The combined surface creates several practical failures.

One label carries several permissions#

A single "Approve" button can hide creative preference, run permission, policy acceptance, and release consent. The audit log then records an approval without recording what the person understood they were approving.

Creative tools inherit operational reach#

The Creative Room needs broad freedom to explore and repair. If the same component also holds run credentials or publishing tools, every creative action sits closer to an external side effect than the job requires.

Repairs make earlier approvals stale#

Creative work changes. If a repaired candidate keeps the approval attached to its predecessor, the run may process bytes, instructions, or assets that nobody approved in their current form.

Retries gain an unclear blast radius#

Creative retries can be cheap and frequent. Operational retries may spend budget, write records, trigger vendors, or release public work. A shared retry control erases that difference.

Receipts lose their meaning#

A receipt should answer who authorized the operation, which handoff revision entered the run, what policy checks passed, which side effects occurred, and whether release followed. A combined surface tends to produce activity logs instead. Activity shows movement. It does not prove authority.

The business consequence#

This architecture issue reaches the business before it reaches a security review.

Under a weak boundary, a selected campaign concept can trigger paid generation. A repaired asset can bypass the approval attached to an earlier version. A successful run can release a brand-damaging output before BrandLab governance evaluates it. A customer-facing write can happen with no named approver. When the team investigates, the log may show clicks and timestamps while leaving the authorization chain unresolved.

The direct costs include wasted compute, vendor charges, cleanup, missed launch windows, and manual reconstruction of what happened. The harder costs sit in customer trust, brand control, contractual commitments, and the ability to prove that a person or policy approved the exact action.

Small teams face the same exposure as enterprise teams. Their recovery bench is thinner. Good AI agent governance architecture gives them a clear stop rule without requiring an enterprise governance department.

How AI agent governance architecture repairs the boundary#

We repaired the model by giving creative selection and operational authorization different rooms, commands, states, and evidence.

The handoff contract#

CreativeHandoffV1 is the border artifact. It should contain enough creative context for the Control Room to validate and run the intended work without smuggling authority across the border.

A useful handoff includes:

• The brief reference and selected candidate reference.
• The exact candidate revision.
• The intended output and constraints.
• Required assets and inputs.
• Repair history relevant to the run.
• Unresolved creative or policy questions.
• The requested next review state.

It excludes credentials, executable approval, release permission, and implied access to outside systems. Control Room decides which operation can satisfy the request and whether that operation has earned authorization.

The authorization contract#

Authorization is a separate record. It binds a named approver or approved policy to:

• One operation.
• One CreativeHandoffV1 revision.
• One environment.
• One set of allowed tools or destinations.
• A validity window.
• A retry policy.
• A stop condition.

Any change to the handoff revision invalidates the old authorization. Any request outside the approved scope returns to review.

The receipt contract#

A Control Room receipt records what the system attempted and what happened. At minimum, it needs the handoff revision, authorization reference, policy result, run status, timestamps, side-effect summary, output reference, failure reason, and release status.

Receipts should avoid secrets and private customer data. Their job is replayable accountability. An operator should be able to reconstruct the decision without reading chat history or guessing from UI state.

Adversarial boundary tests#

Happy-path demos cannot prove this boundary. We test the paths most likely to blur selection and authorization.

A boundary passes when the blocked action stays blocked through the backend. UI warnings and disabled buttons count as operator guidance. Permission checks, version checks, strict schemas, and idempotency enforce the rule.

Evidence receipt: This is a redacted reproduction of the reviewed internal CreativeHandoffV1 artifact. The candidate is selected and ten evidence receipts are attached. controlRoomGateComplete, publicationAuthorized, and externalActionsAuthorized remain false. The source artifact SHA-256 is embedded in the SVG.

Five checks before you buy#

A buyer should be able to run this diagnostic in a product demo or architecture review. Ask for the records and failure behavior on screen.

Five clear answers support a bounded pilot. Three or four answers point to repair work before production. Two or fewer mean the demo has outrun the controls.

If a vendor answers with "the model knows," "the user already approved the concept," or "we log everything," ask to see the state transition and the denied request. Those two artifacts are the evidence.

Related approval and handoff tests#

The AI agent approval workflow failure case shows what happens when a Reject recommendation can become an approval in the journal. Use it to test authority, explicit overrides, provenance, and the evidence binding the screen to the backend decision.

The AI agent handoff test shows how to map owners, fallbacks, logs, rejects, and stop conditions with five real records. Use it when the workflow itself still has soft edges.

The Hermes Agent judgment-layer guide explains where agent reasoning belongs and where human approval or deterministic software should take over. Use it when tool access is expanding faster than the review model.

If selection and approval already share events, permissions, or interface language, our AI agent workflow repair service is built to trace the boundary, define the missing contracts, and test the denied paths.

What to measure after separation#

The architecture should make authority easier to inspect, not merely produce more logs.

Methodology and internal-product disclosure#

This article comes from Nocturnal's internal Eclipse product architecture review. Eclipse Creative Room, Control Room, and CreativeHandoffV1 are internal product components used here as a first-party design case. This is neither a client result nor an external security certification.

Our review started with a capability inventory and an owner matrix. We traced one selected candidate through handoff, run, governance, and release. Then we attacked stale revisions, direct calls, retries, missing receipts, and scope changes. Each denied path had to fail at the service boundary and leave evidence that named the state, reason, and next owner.

We found the ambiguity during internal review before any external side effect occurred. That timing matters. Unclear authority is cheaper to correct in the architecture than to explain after release.