Design of the HTTPS Layer for AI Governance by Machine-Verifiable Authority Before Consequential Action | Zenodo
Skip to main
You are using an outdated browser. Please upgrade your browser to improve your experience.
Published August 16, 2026
| Version v1
Dataset
Open
Design of the HTTPS Layer for AI Governance by Machine-Verifiable Authority Before Consequential Action
Authors/Creators
Das, Sangam
Description
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<br>≠<br>AUTHORITY<br>≠<br>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...