Designing The HTTPS Layer for Agentic AI Governance : Verify Authority Before Execution

Abstract

This paper presents a conceptual framework for execution-time AI governance based on a simple but consequential principle:

Computation should not automatically imply authority to produce an external effect.

Modern AI systems increasingly generate outputs that can move beyond recommendation or information generation and directly influence external systems. AI agents may invoke tools, transmit data, execute financial transactions, modify files, communicate with external services, control software-defined infrastructure, trigger physical devices, initiate workflows, or delegate actions to other agents. In such environments, the central governance question is no longer only whether an AI model was tested, approved, aligned, certified, monitored, or operated by an authorised organisation. A further question arises at the moment of consequence:

Does this specific AI-generated act possess valid authority to become externally effective now?

The framework draws an analogy with HTTPS. HTTPS did not make networks, servers, software, or users inherently trustworthy. Instead, it introduced a protocol-level mechanism for reducing reliance on assumed trust by requiring machine-verifiable properties before protected communication proceeds. Identity, integrity, cryptographic state, and protocol conditions are evaluated as part of the communication process rather than being left solely to organisational assurances.

Execution-time AI governance applies a similar conceptual separation to AI-generated consequences.

The proposal does not attempt to make an AI model inherently trustworthy. Nor does it assume that a model that passed pre-deployment evaluation will necessarily behave appropriately in every future context. Instead, it asks whether selected governance conditions can become machine-enforceable prerequisites for effectuation.

Current AI governance commonly relies on several important layers:

• pre-deployment evaluation;

• model testing and red teaming;

• organisational policies;

• access control;

• human oversight;

• logging and monitoring;

• risk management;

• audits;

• incident reporting; and

• post-event accountability.

These mechanisms remain necessary. However, many of them primarily determine whether a system should be trusted, whether an organisation has followed required procedures, or what happened after an event.

They do not necessarily control the precise technical transition between:

AI-generated computation

and

externally effective consequence.

The execution-time model therefore introduces an additional architectural distinction:

COMPUTATION
      ≠
AUTHORITY
      ≠
EFFECTUATION

An AI system may be permitted to reason, calculate, generate, simulate, rank, recommend, compose, or propose an operation without automatically possessing authority to make that operation effective.

A proposed consequential operation can instead first exist as a Candidate Act.

The Candidate Act represents the load-bearing properties of the exact consequence being requested. Depending on the application, those properties may include:

• action type;

• destination;

• resource;

• purpose;

• user or system authority;

• model or runtime identity;

• applicable policy;

• temporal validity;

• security epoch;

• revocation state;

• jurisdiction;

• transaction or operation scope; and

• other context necessary to distinguish the authorised consequence from a substituted or expanded one.

The Candidate Act then remains in a Non-Effective State while the relevant governance conditions are evaluated.

This state is conceptually important because it separates:

AI produced an action

from:

the system authorised that action to become effective

Where the required conditions are satisfied, protected validation can generate a narrowly scoped execution authority bound to the specific act and applicable context.

The relevant Execution-Finality Boundary or Finality Sink then independently verifies that authority at the point where the proposed operation would first become externally effective.

Examples of such boundaries may include:

• a network-egress boundary before data transmission;

• a payment-effectuation boundary before value transfer;

• a file-export boundary before protected information leaves its domain;

• an API or tool-dispatch boundary before an external service is invoked;

• a software-update boundary before code becomes operational;

• a device-control boundary before a physical act occurs;

• an RF transmission boundary before radiation occurs; or

• another protected interface where a computational proposal becomes an external consequence.

The architecture can therefore be represented conceptually as follows.

Execution-Time Governance Flow

┌──────────────────────────────┐
│       HUMAN / AI / AGENT     │
│   generates or proposes act  │
└──────────────┬───────────────┘
               │
               v
┌──────────────────────────────┐
│        CANDIDATE ACT         │
│                              │
│ Exact proposed consequence:  │
│ • action                     │
│ • destination                │
│ • purpose                    │
│ • resource                   │
│ • authority                  │
│ • context                    │
│ • time / epoch               │
└──────────────┬───────────────┘
               │
               v
┌──────────────────────────────┐
│      NON-EFFECTIVE STATE     │
│                              │
│ Computation exists, but the  │
│ consequence is not yet       │
│ permitted to become real.    │
└──────────────┬───────────────┘
               │
               v
┌──────────────────────────────┐
│     PROTECTED VALIDATION     │
│                              │
│ Evaluate, as applicable:     │
│ • identity / provenance      │
│ • model / runtime state      │
│ • purpose                    │
│ • scope                      │
│ • destination                │
│ • jurisdiction               │
│ • security epoch             │
│ • freshness                  │
│ • revocation                 │
│ • policy predicates          │
└──────────────┬───────────────┘
               │
        ┌──────┴──────┐
        │             │
      FAIL           PASS
        │             │
        v             v
┌──────────────┐   ┌──────────────────────────────┐
│   NO FINAL   │   │   SCOPED EXECUTION AUTHORITY│
│    EFFECT    │   │                              │
│              │   │ Bound to the exact act,     │
│ deny / defer │   │ context, destination,       │
│ constrain /  │   │ validity and applicable     │
│ escalate     │   │ governance state.           │
└──────────────┘   └──────────────┬───────────────┘
                                  │
                                  v
                   ┌──────────────────────────────┐
                   │    FINALITY SINK / RELEASE  │
                   │          BOUNDARY            │
                   │                              │
                   │ Independently verifies:      │
                   │ • exact act                  │
                   │ • authority                  │
                   │ • binding                    │
                   │ • freshness                  │
                   │ • current state              │
                   │ • unused / valid status      │
                   └──────────────┬───────────────┘
                                  │
                           ┌──────┴──────┐
                           │             │
                         FAIL           PASS
                           │             │
                           v             v
                    ┌────────────┐   ┌─────────────────┐
                    │ NO EFFECT  │   │ EXTERNAL EFFECT │
                    │            │   │                 │
                    │ remains    │   │ network action  │
                    │ non-final  │   │ payment         │
                    └────────────┘   │ tool invocation │
                                     │ physical action │
                                     │ data release    │
                                     └─────────────────┘

The resulting governance model can be expressed in condensed form:

GENERATE
   ≠
AUTHORIZE

AUTHENTICATE
   ≠
AUTHORIZE

COMPUTE
   ≠
AUTHORIZE

TRANSPORT
   ≠
AUTHORIZE

VERIFY AT EXECUTION FINALITY
   ↓
EFFECTUATE

The framework can also distinguish between authentication and execution authority.

Authentication may establish who or what initiated an operation.

Execution-time governance asks whether that authenticated entity possesses authority for this exact consequence, under this exact context, at this particular moment.

Similarly, model approval need not imply universal action approval.

An approved model may generate an operation that is outside the permitted purpose, directed toward an unauthorised destination, produced during an invalid security epoch, inconsistent with current policy, or based on authority that has expired or been revoked.

The architecture therefore allows several governance dimensions to remain independent:

APPROVED MODEL
      ≠
APPROVED PURPOSE
      ≠
APPROVED DESTINATION
      ≠
APPROVED CONTEXT
      ≠
VALID EXECUTION AUTHORITY

A central technical objective is to reduce dependence on bearer-like authority.

An AI agent should not necessarily be able to cause an external effect merely because it possesses a reusable credential, API key, session token, operating-system permission, delegated OAuth scope, or previously issued authorization.

Where appropriate, final execution authority can instead be narrowly scoped to the Candidate Act itself and constrained by properties such as:

• destination;

• operation class;

• validity interval;

• security epoch;

• execution count;

• recipient;

• purpose;

• protected state; and

• final release boundary.

This makes it possible to move from:

"this agent is trusted"

toward:

"this exact act is authorised under these exact conditions"

The approach also changes the role of governance evidence.

Traditional logging primarily supports the question:

What happened?

Execution-time governance introduces another question:

Should this consequence be permitted to happen?

The two functions are complementary. Post-event audit remains important, but high-impact, irreversible, financial, physical, security-sensitive, privacy-sensitive, or cross-system operations may benefit from evidence and validation that occur before or atomically with effectuation, rather than only after the consequence has occurred.

The framework is intentionally implementation-neutral.

It does not require a particular:

• cryptographic primitive;

• blockchain or distributed ledger;

• token format;

• capability system;

• trusted execution environment;

• hardware security module;

• secure element;

• operating system;

• cloud platform;

• AI model;

• policy language;

• identity system; or

• network protocol.

Possible implementations could use combinations of software mediation, trusted hardware, cryptographic commitments, short-lived capabilities, hardware-backed state, operating-system enforcement, remote attestation, secure gateways, protected API brokers, network-release controls, payment finality mechanisms, or other future enforcement architectures.

The invariant is more important than the implementation:

A consequential AI-generated act remains non-effective until the required governance conditions are established and the resulting authority is verified at the boundary where external effect would otherwise occur.

This architecture is not intended to place a heavyweight cryptographic transaction in every AI computation or every low-level software operation.

A practical deployment could reserve execution-finality enforcement for consequential actions while allowing ordinary reasoning, simulation, local computation, reversible processing, and low-risk internal activity to continue without equivalent gating.

High-frequency workflows could also operate under bounded pre-authorised envelopes, allowing fast execution within predefined constraints while requiring new authorization when an operation attempts to cross those limits.

The framework therefore separates the AI computation plane from the authority plane.

AI COMPUTATION PLANE
reason
generate
simulate
rank
recommend
plan
compose

        │
        │ Candidate Act
        v

AUTHORITY PLANE
validate
bind
authorize
verify
consume
effectuate

This separation may become increasingly important as AI systems evolve from passive assistants into autonomous or semi-autonomous agents capable of invoking APIs, controlling software, operating machines, coordinating with other agents, initiating transactions, accessing protected resources, and producing large numbers of machine-generated acts without direct human review.

In such environments, governance based primarily on organisational trust or post-event supervision may become increasingly difficult to scale.

Execution-time governance therefore explores whether selected governance decisions can be expressed as machine-verifiable constraints positioned near the actual consequence boundary.

The HTTPS analogy is intentionally limited.

HTTPS does not establish that a website is honest, lawful, safe, or beneficial. It provides enforceable protocol properties around communication.

Likewise, an execution-time governance layer would not determine whether an AI system is inherently aligned, whether a policy is legally correct, or whether a governance authority made the right substantive decision.

Instead, it would seek to ensure that once applicable governance conditions have been established, those conditions cannot be bypassed merely because an AI system, application, agent, or authorised component is technically capable of producing the requested act.

In this sense, execution-time governance may be viewed conceptually as an “HTTPS layer for AI governance”:

not a mechanism for making AI inherently trustworthy, but a framework for reducing dependence on trust by requiring machine-verifiable authority before consequential AI-generated acts are permitted to become effective.

The research proposition is therefore not that existing AI governance should be replaced.

It is that governance may require an additional technical layer connecting:

POLICY
   ↓
MACHINE-VERIFIABLE CONDITIONS
   ↓
PROTECTED VALIDATION
   ↓
SCOPED EXECUTION AUTHORITY
   ↓
FINALITY VERIFICATION
   ↓
EXTERNAL CONSEQUENCE

The broader research question is whether future AI infrastructure should treat execution authority itself as a first-class security primitive.

If so, the future governance stack may move from asking only:

“Is this AI system trusted?”

toward also asking:

“Does this exact AI-generated act possess valid authority to become effective here, now, under the required conditions?”

That is the conceptual transition from AI governance by trust and audit toward AI governance by enforceable execution-time authority.