Authority Architecture: Designing AI Governance That Holds at Execution

The failure this architecture prevents

The failure is rarely dramatic. A model produces output, the pipeline accepts it, the system executes, and no one explicitly granted that authority. The action is taken before anyone reviews what happened. There is no rogue model and no adversarial attack. The system simply proceeds, because nothing in the architecture required it to stop.

Authority architecture becomes particularly important as organisations move from AI assistants to agentic systems capable of initiating actions across multiple applications and workflows. An assistant suggests, while an agent executes, and once a system can act across applications without a human reviewing each step, who authorised the action becomes the governing question rather than a theoretical one.

This is the governance failure most enterprises are living with, and most have not named it. The root cause is structural: execution happens by inertia because the architecture never required an explicit authorisation before output became action.

That points to a more productive governing question. Instead of asking how a system behaves, ask who is allowed to make the decision. Behaviour can be observed with dashboards and logs. Authority has to be enforced before a decision executes. The rest of this document describes the architecture that makes authority explicit, enforced, and evidenced at the point of execution.

The four authority questions

For any AI system making consequential decisions, four questions determine whether the governance is substantive or cosmetic. Treat them as the requirements specification the architecture has to satisfy. Each maps directly onto one of the four control gates introduced later.

An organisation that cannot answer all four for each consequential system has only the appearance of governance over a system that assumed its own authority because nothing required it to ask.

The governance stack: where most programmes stop

The architecture sits inside a three-layer governance stack. Most programmes invest heavily in the first two layers and stop at the boundary of the third.

The policy layer holds governance documentation, oversight committees, regulatory frameworks, and accountability policies. The process layer holds approval workflows, post-hoc audits, monitoring dashboards, model reviews, and human-in-the-loop sign-offs. The enforcement layer holds technical controls, execution boundaries, deterministic control points, override architecture, and runtime guardrails.

The enforcement layer is where authority is actually granted or withheld. The distinction is simple: a dashboard tells you what happened, while a gate determines what is allowed to happen. The dashboards that show you what happened will not protect you when a regulator or a board asks who authorised the action. This document specifies the enforcement layer and its interface to the evidence layer. Policy and process are upstream inputs to it.

The governance chain: from principle to evidence

The three-layer stack expands into a six-link chain that traces a governance decision from intent to operational proof.

Principles, Capabilities, Risks, and Controls are produced in the policy and process layers. Enforcement and Evidence are the two links this architecture operationalises. The chain makes one distinction visible: specifying a control and verifying that it remains active in production are different artifacts requiring different infrastructure.

Singapore's Agentic Risk and Capability (ARC) Framework is a particularly useful input layer, because it provides a structured way to classify agent capabilities, risks, and controls that can then be operationalised at runtime. That taxonomy is what tells the enforcement layer what to enforce.

The reference pattern: the financial transaction model

Financial systems solved this problem long ago. A payment proceeds only after it has cleared a sequence of designed controls, and the default at each control is halt. Intent alone never moves the transaction. This is the pattern AI governance needs to replicate at the decision boundary.

The pattern is four control gates, each answering one of the four authority questions, ending at a deterministic execution boundary.

None of these gates are advisory. They determine what the system is allowed to do, and if an action fails a gate it stops. This is the canonical pattern. The rest of the architecture is about applying it selectively to decisions that cross a risk threshold, rather than to every model output.

The enforcement layer in detail

The enforcement layer is a small set of components. Each consumes inputs from the policy and process layers and contributes to the four-gate pattern. The description here is conceptual and vendor-neutral, specifying what each component does rather than which product implements it.

These components are rarely a single new system. In most enterprises the gates are placed into the enforcement points the stack already has: the model platform's native guardrails, the agent framework's tool and permission controls, the application layer, and the human ratification step. AI runs in too many places for any single runtime chokepoint to govern it. The discipline is the placement itself, specifying across a fragmented stack where each gate sits and what it must enforce, so that authority holds consistently whichever point executes the action.

What the architecture catches that infrastructure does not

A fully sovereign infrastructure stack, with hardware attestation, enterprise-held keys, data residency, policy-as-code, and immutable logging, governs the environment an agent runs in. It does not govern what the agent is permitted to do inside it. Two scenarios show the gap.

Traditional governance asks whether each system behaved correctly. Authority architecture asks whether the resulting authority state was legitimate. Both scenarios pass the first test and fail the second. The full narrative is in Your AI Infrastructure Can Pass Every Audit. Your Governance Can Still Fail.

Applying the architecture

The path from recognition to implementation runs in sequence. The architecture applies to decisions that cross a risk threshold, not to every model output. Over-gating low-risk autonomy defeats the purpose.

1. 1
   Inventory consequential decisions. Identify the AI systems making decisions that cross a risk threshold. An ARC assessment is the recommended input.
2. 2
   Define the authority matrix. Answer the four questions for each consequential decision class, in a form a system can enforce.
3. 3
   Place the gates. Decide where in each pipeline the four control gates sit, and where the deterministic execution boundary is. The gates are implemented in the enforcement points the stack already has, the platform guardrails, the agent framework, the application layer, and human ratification, rather than in a new plane built alongside them. Placement across those points is the design work.
4. 4
   Define the Suspended Handoff State. For each system category, specify the trigger conditions, ratifier information, time constraint, and the default on no response.
5. 5
   Wire the evidence binding. Generate the authority trail at decision time so it travels with the decision into the evidence layer.
6. 6
   Test against realistic scenarios. Include aggregate and temporal failure modes before the system reaches production.

Regulatory alignment in Singapore and Southeast Asia

Each of the frameworks the audience answers to expects oversight that is demonstrable. The enforcement layer and the evidence layer are what make oversight demonstrable rather than asserted.

Risk leaders in regulated institutions already operate a second line of defence that defines required controls, verifies they are present, and owns the evidence, while the first line runs them. Authority architecture is how that second line expresses itself for agentic AI. The enforcement layer specifies where authority must bind and the evidence layer owns the proof, while the institution's own systems execute the controls.

This also answers a common concern that runtime control addresses only one obligation. Authority architecture spans the risk-identification step through the risk-threshold classifier, the oversight obligation through the Suspended Handoff State, and the evidence obligation through binding at decision time. It covers identification, oversight, and proof together, which is what each framework actually requires.

For a control-by-control mapping of the MAS expectations, see the MAS AIRG guide.