The Architecture of Authority – Why AI Intelligence Must Never Govern Its Own Power

Following several requests to expand on the concept of the ‘AI Harness’, which I have referenced in a number of previous articles, most notably Is the AI Harness the Most Important Part of AI That Few Currently Talk About?, I thought it worthwhile to offer a more accessible, plain English explanation of what it is, how it works and why it matters. This is deliberately a high level overview rather than an exhaustive or technical treatment, intended to communicate the architectural principles and strategic implications in terms that are meaningful to business leaders and executives.

In a nutshell an AI Harness is the independent control and orchestration architecture/layer that sits between people, businesses or autonomous machine customers and the AI models, information and systems they wish to use.

Its central purpose is to separate the intelligence that decides what it wants to do from the authority that determines what it is allowed to do. This is a critical distinction. We cannot reliably prevent an AI model from proposing an inappropriate action. We can, however, architect systems so that the model cannot execute that action without independent authorisation.

The Control Harness is not merely the architecture that prevents an AI model from cheating. It is the architecture that determines which intelligence can be used, what knowledge it can access, what authority it possesses, which actions it may execute and how those actions are independently assured.

In simple terms, the model provides the intelligence; the harness determines how that intelligence can be used, what it is allowed to do and whether its actions can be trusted.

Architectural Outline

Conceptually all privileged agent/model actions pass through a separately enforced control plane or ‘Control Harness’. The agent/model or Tools and API’s must have no alternative route to the protected systems or access to them.

The harness is not simply another AI model supervising the first. It is a collection of conventional, independently operated security controls, including identity providers, policy engines, API gateways, isolated execution environments and monitoring systems.

1. Identity and intent – The harness authenticates the human or machine customer, establishes the purpose of the request and determines the delegated authority available.
2. Model orchestration – The harness selects an appropriate model or combination of models according to capability, cost, sensitivity, latency and sovereignty. A locally hosted model might process confidential information while an external frontier model handles a more complex but suitably sanitised reasoning task.
3. Intelligence augmentation – The harness determines which internal knowledge sources, RAG services, external intelligence feeds or specialised tools are available. Crucially, retrieved content remains untrusted input; it cannot grant the agent additional authority.
4. Action and transaction control – The harness mediates tool calls and enforces permissions independently of the model. An agent may recommend a payment, infrastructure change or procurement decision, but execution requires the relevant authorisation.
5. Continuous assurance – The harness records decisions, tool requests, policy evaluations and execution outcomes, allowing an organisation to reconstruct what happened and determine whether the activity complied with policy.

The key is that the model cannot bypass these controls by making direct connections to protected resources. As I stated in an earlier piece ‘It’s Not the Model, Stupid … Standards Must Govern Authority, Not Intelligence‘ the model itself should become almost irrelevant to transactional trust.

Ideally this would not be implemented as one large centralised application. That risks creating a bottleneck, single point of failure and potentially an exceptionally attractive attack target. Instead, design it as a logically unified but technically distributed control architecture, with separate components for identity, policy decisions, policy enforcement, model routing, resource brokerage, execution and assurance.

This is also where the distinction between the control plane and execution plane becomes important. The harness establishes and enforces authority, but model inference and permitted actions can execute across different environments. The harness does not need to transport every byte of information through a single central process.

Operational

Imagine an AI agent managing cloud infrastructure. Its task is to reduce operating costs by 20%. The agent discovers that shutting down several production servers would achieve the target immediately. Without an effective harness, an agent with broad administrator permissions might attempt precisely that. With the harness:

1. Agent proposes an action – Shut down production servers to reduce cloud costs.
2. Identity and authority checked – The harness verifies which business principal authorised the agent, for what task and with which permissions.
3. Policy evaluated – The policy engine determines that the agent may recommend production changes but cannot execute them without approval.
4. Execution blocked – The infrastructure gateway refuses the operation. The agent has no direct production credentials with which to bypass the decision.
5. Escalation and assurance – An authorised human can approve a specific change. The decision, action and outcome are recorded and monitored.

Notice that we have not needed to determine whether the AI was cheating, hallucinating or genuinely trying to help, its intentions are largely irrelevant to the security decision.

Summary Capabilities

Control	Practical implementation
Identity	Entra ID or equivalent, workload identities, short-lived credentials and delegated authorisation
Policy	Open Policy Agent (OPA), Cedar or equivalent policy-as-code engines
Tool access	API gateways, tightly scoped tool interfaces and deny-by-default permissions
Transaction control	Independent validation, approval thresholds and separation of duties
Isolation	Sandboxed runtimes, network segmentation, restricted secrets and egress controls
Continuous assurance	Immutable audit trails, SIEM/SOC monitoring, anomaly detection and immediate revocation

Importantly, the harness must be outside the model’s administrative control. Otherwise, the AI could potentially modify the very policies intended to constrain it.

Importance & Relevance

This is where the Hugging Face example becomes particularly revealing.

The central security question should not be whether a frontier model can be persuaded to respect its instructions. It should be if the model ignores every instruction, manipulates its environment and actively attempts to circumvent restrictions, what can it actually accomplish?

That is an architectural question, not a model-training question. It is also the essence of Zero Trust to never equate a component’s apparent legitimacy or competence with unrestricted authority.

As the harness owns the customer relationship, understands intent, controls authority and orchestrates intelligence, the AI model becomes a replaceable component of the service rather than its defining feature. That opens the possibility of model agnostic enterprise AI, lower dependence on frontier laboratories, FinOps optimisation, sovereign deployment and ultimately a trusted infrastructure for autonomous machine customers.

It also aligns with the direction of a wider hypothesis I have shared about the disappearance of traditional applications and operating system (OS) interfaces, whereby the user increasingly interacts with an intelligent service layer, rather than choosing applications or models individually.

There is a qualification and important recognition, a harness is not magically secure. Its gateways, credential boundaries, approval workflows and policy enforcement can themselves contain vulnerabilities. They require penetration testing, independent assurance and continuous validation, just like any other critical infrastructure.

AI Economic Significance

The longer-term significance is that a properly designed harness can make the choice of AI model substantially less important to transactional trust.

An organisation could use a frontier model for complex reasoning, a smaller local model for sensitive information, or an open-weight model for routine tasks. All would operate under the same independent authority architecture. This offers three strategic advantages:

1. reduced dependency on any single frontier lab,
2. stronger sovereignty over enterprise information
3. greater freedom to optimise model cost and performance.

It also provides the foundation for a world of machine customers, which will arrive faster than most organisations are prepared for, where autonomous agents transact with organisations without requiring a human to approve every routine decision. The agent/model may be autonomous in its reasoning, but its authority remains explicitly bounded.

The principle that matters is that we should stop treating AI security primarily as a question of whether the model is sufficiently well-behaved. An AI model is an increasingly powerful reasoning engine. It should not simultaneously be the source of its own authority, the interpreter of its own restrictions and the judge of whether it has complied. That would be the digital equivalent of allowing a bank trader to set their own trading limits, approve their own transactions and audit their own accounts.

The Control Harness separates intelligence from authority, the model decides what to propose, the architecture decides what is permitted and independent assurance / audit establishes what actually happened.

That is how we move from explainable AI towards provably controlled AI, not a guarantee of perfect behaviour, but verifiable enforcement of the boundaries within which that behaviour can have consequences. The result is not blind trust in the intelligence of the model, but qualified trust in the architecture that governs its authority, constrains its actions and provides auditable evidence of its compliance.