Datasetpublic

sangamdas/The-Missing-Security-Layer-for-AI-Agents-Execution-Time-Governance-Before-Effect

AI Can Compute — But Should It Be Allowed to Act? The HTTPS of AI Governance Author: Sangam DasAffiliation: Independent Inventor, India Overview AI governance is increasingly concerned with systems that do more than generate text or recommendations. Modern AI agents may: invoke APIs; call external tools; transmit data; execute financial transactions; modify files; trigger workflows; control software-defined infrastructure; operate physical… See the full description on the dataset page: https://huggingface.co/datasets/sangamdas/The-Missing-Security-Layer-for-AI-Agents-Execution-Time-Governance-Before-Effect.

sourceHugging Facecc-by-nc-4.0updated 1mo agoView on Hugging Face

0likes15downloads

Dataset Card

AI Can Compute — But Should It Be Allowed to Act?

The HTTPS of AI Governance

Author: Sangam Das Affiliation: Independent Inventor, India

Overview

AI governance is increasingly concerned with systems that do more than generate text or recommendations.

Modern AI agents may:

—invoke APIs;
—call external tools;
—transmit data;
—execute financial transactions;
—modify files;
—trigger workflows;
—control software-defined infrastructure;
—operate physical devices;
—communicate with external services; and
—delegate actions to other agents.

This creates a governance problem that is different from traditional model evaluation:

Even if an AI system is approved, tested, monitored and authenticated, should every action it generates automatically be allowed to become externally effective?

This publication proposes a conceptual execution-time AI governance framework based on one core principle:

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

The framework is presented through an analogy with HTTPS.

HTTPS did not make the internet inherently trustworthy. It reduced dependence on assumed trust by introducing machine-verifiable protocol properties into communication.

Execution-time AI governance applies a similar idea to AI-generated consequences:

Do not merely trust that an AI system will act correctly. Require machine-verifiable authority before a consequential act is allowed to become effective.

1. The Governance Gap

Current AI governance commonly relies on:

—pre-deployment evaluation;
—red teaming;
—organizational controls;
—access control;
—human oversight;
—logging;
—monitoring;
—audits;
—risk management;
—incident reporting; and
—post-event accountability.

These mechanisms remain important.

However, many of them primarily answer questions such as:

text

Was the model tested?
Was the organization compliant?
Was the user authenticated?
Was the action logged?
Was the incident detected?

Execution-time governance asks another question:

text

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

The distinction is:

text

COMPUTATION
    ≠
AUTHORITY
    ≠
EFFECTUATION

2. The HTTPS Analogy

The phrase “HTTPS of AI Governance” is a conceptual analogy.

HTTPS does not prove that a website is honest, lawful or safe.

Instead, it provides enforceable protocol properties around communication.

Likewise, execution-time AI governance does not claim to make AI:

—inherently aligned;
—inherently safe;
—legally correct;
—trustworthy in every context; or
—incapable of generating harmful outputs.

Instead, it asks whether selected governance conditions can be made machine-enforceable before consequential effectuation.

The analogy is therefore:

text

HTTPS
reduces reliance on trust in communications
through protocol-level verification

EXECUTION-TIME AI GOVERNANCE
reduces reliance on trust in AI-generated actions
through effectuation-time verification

3. Core Principle

The framework separates:

text

AI MAY THINK
AI MAY CALCULATE
AI MAY GENERATE
AI MAY SIMULATE
AI MAY RECOMMEND
AI MAY PROPOSE

             ↓

BUT NONE OF THESE ALONE
NECESSARILY CREATE
FINAL EXECUTION AUTHORITY

A machine-generated act can exist without immediately becoming a real-world consequence.

This creates a new governance boundary:

The transition from computation to effectuation.

4. Candidate Act

A consequential AI-generated operation can first be represented as a Candidate Act.

The Candidate Act represents the load-bearing properties of the exact proposed consequence.

Depending on the application, these may include:

text

action_type
destination
resource
purpose
user_authority
system_authority
model_identity
runtime_identity
policy_context
temporal_validity
security_epoch
revocation_state
jurisdiction
transaction_scope
operation_scope
recipient
tool_or_API_target

The objective is not to describe every internal thought or token generated by the model.

The objective is to represent the externally consequential act that is about to occur.

5. Non-Effective State

The Candidate Act enters a Non-Effective State.

During this state:

—the AI output exists;
—the operation may be fully computed;
—the tool request may be prepared;
—the payment instruction may be constructed;
—the file may be selected;
—the destination may be known;

but the external consequence has not yet been authorized.

This preserves the distinction:

text

AI PRODUCED THE ACT
        ≠
THE SYSTEM AUTHORIZED THE ACT

The Non-Effective State is therefore the architectural space where governance can operate before irreversible consequence.

6. Protected Validation

Protected validation evaluates the machine-verifiable conditions that apply to the Candidate Act.

Possible predicates include:

—identity or provenance;
—model or runtime state;
—purpose;
—scope;
—resource;
—destination;
—recipient;
—jurisdiction;
—security epoch;
—freshness;
—revocation state;
—applicable policy;
—authorization context; and
—other relevant execution conditions.

The framework does not require every deployment to use every predicate.

Different applications may require different validation sets.

7. Scoped Execution Authority

Where the required conditions pass, the system can issue a narrowly scoped execution authority.

Conceptually:

text

AUTHORIZE:

Act: Send File X
Destination: Service Y
Purpose: User-approved export
Model/Agent: A-17
Security Epoch: E42
Validity: 30 seconds
Uses: 1
Finality Boundary: Network Egress Sink 3

The authority can be limited by:

text

act
destination
purpose
recipient
validity window
security epoch
execution count
protected state
release boundary

This moves the system away from:

text

"this AI agent is trusted"

toward:

text

"this exact act is authorized
under these exact conditions"

8. Finality Sink

The Finality Sink is the protected boundary where the proposed act would first become externally consequential.

Examples include:

AI-Generated Act	Possible Finality Sink
Network transmission	Network-egress boundary
File export	File-release/export service
Payment	Payment-effectuation boundary
API call	Protected API/tool-dispatch broker
Software update	Activation boundary before code becomes operational
Physical-device command	Device-control boundary
RF transmission	RF release boundary
Data release	Protected data-egress boundary
Agent-to-agent delegation	Delegation/authority-transfer boundary

The Finality Sink asks:

Does this exact act still possess valid authority to become effective at this boundary?

9. Execution-Time Governance Flow

text

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

10. Condensed Governance Invariant

text

GENERATE
   ≠
AUTHORIZE

AUTHENTICATE
   ≠
AUTHORIZE

COMPUTE
   ≠
AUTHORIZE

TRANSPORT
   ≠
AUTHORIZE

VERIFY AT EXECUTION FINALITY
   ↓
EFFECTUATE

11. Computation Plane vs Authority Plane

The architecture separates two logical planes.

text

AI COMPUTATION PLANE

reason
generate
simulate
rank
recommend
plan
compose

        │
        │ Candidate Act
        v

AUTHORITY PLANE

validate
bind
authorize
verify
consume
effectuate

This permits broad computational freedom without automatically granting broad external authority.

12. Authentication Is Not Execution Authority

Authentication may establish:

text

who or what initiated the operation

Execution-time governance asks:

text

does that authenticated entity
have authority for this exact consequence
under this exact context
at this exact moment?

A valid credential may therefore be necessary without being sufficient.

13. Model Approval Is Not Universal Action Approval

An approved model may still generate an act that is:

—outside the permitted purpose;
—directed toward an unauthorized destination;
—stale;
—revoked;
—outside the current security epoch;
—outside the permitted scope;
—incompatible with current policy; or
—directed toward an unauthorized resource.

Therefore:

text

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

14. Why Reusable Credentials May Be Insufficient

An AI agent may possess:

—an API key;
—OAuth scope;
—an operating-system permission;
—a session credential;
—an access token;
—a service account;
—a delegated capability.

These may establish general access.

Execution-time governance asks whether a particular act still has valid authority at the consequence boundary.

This is especially relevant for agentic systems that may generate thousands of actions after receiving one broad credential.

15. Why Logging Is Not Enough

Logging asks:

What happened?

Execution-time governance asks:

Should this consequence be permitted to happen?

The two are complementary.

Post-event audit remains essential.

However, for:

—high-impact transactions;
—irreversible actions;
—financial transfers;
—external data release;
—physical control;
—security-sensitive operations;
—privacy-sensitive operations; and
—cross-system actions,

pre-effectuation validation may provide an additional layer of protection.

16. Implementation Neutrality

The framework does not require a particular:

—cryptographic primitive;
—blockchain;
—distributed ledger;
—token format;
—capability format;
—TEE;
—HSM;
—secure element;
—operating system;
—cloud platform;
—AI model;
—policy language;
—identity system; or
—network protocol.

Possible implementation approaches include combinations of:

—software mediation;
—trusted hardware;
—short-lived capabilities;
—hardware-backed state;
—operating-system enforcement;
—remote attestation;
—secure gateways;
—protected API brokers;
—network-release controls;
—payment finality mechanisms; and
—future enforcement architectures.

The architectural invariant matters more than the implementation mechanism.

17. High-Frequency and Low-Latency Workflows

Execution-time governance is not intended to insert heavyweight governance into every token, inference step or low-level operation.

A deployment may reserve finality enforcement for consequential actions.

High-frequency workflows can also use bounded pre-authorized envelopes.

Example:

text

Agent A may call Tool T
for Purpose P
up to 100 times
for 5 minutes
under Security Epoch E42
within Resource Scope R

The agent can operate quickly inside the approved envelope.

A new validation decision is required if the agent attempts to exceed that envelope.

18. Detailed Conceptual Pseudocode

The following pseudocode is non-normative. It illustrates the execution-time governance invariant without prescribing one cryptographic primitive, operating system, hardware root of trust, capability format, policy engine, or programming language.

The intended separation is:

text

AI / AGENT COMPUTATION
        ↓
CANDIDATE ACT
        ↓
NON-EFFECTIVE STATE
        ↓
PROTECTED VALIDATION
        ↓
SCOPED EXECUTION AUTHORITY
        ↓
FINALITY SINK RECONSTRUCTION
        ↓
FINALITY VERIFICATION
        ↓
AUTHORITY CONSUMPTION
        ↓
EXTERNAL EFFECT

18.1 Canonical Candidate-Act Construction

The Candidate Act should represent the exact externally consequential operation, not merely an application request, prompt, tool name, or transport message.

text

FUNCTION BUILD_CANDIDATE_ACT(ai_output, runtime_context, requested_effect):

    candidate = NEW CandidateAct

    candidate.act_id =
        FRESH_UNIQUE_IDENTIFIER()

    candidate.action_class =
        NORMALIZE_ACTION_CLASS(
            requested_effect.action_class
        )

    candidate.resource =
        CANONICALIZE_RESOURCE(
            requested_effect.resource
        )

    candidate.destination =
        CANONICALIZE_DESTINATION(
            requested_effect.destination
        )

    candidate.recipient =
        CANONICALIZE_RECIPIENT_IF_APPLICABLE(
            requested_effect.recipient
        )

    candidate.effect_parameters =
        CANONICALIZE_EFFECT_PARAMETERS(
            requested_effect.parameters
        )

    candidate.purpose =
        NORMALIZE_PURPOSE(
            runtime_context.declared_purpose
        )

    candidate.requesting_principal =
        runtime_context.requesting_principal

    candidate.agent_identity =
        runtime_context.agent_identity

    candidate.model_identity =
        runtime_context.model_identity

    candidate.runtime_identity =
        runtime_context.runtime_identity

    candidate.security_epoch =
        runtime_context.security_epoch

    candidate.jurisdiction_context =
        runtime_context.jurisdiction_context

    candidate.policy_context_id =
        runtime_context.policy_context_id

    candidate.authorization_scope =
        runtime_context.authorization_scope

    candidate.created_at =
        PROTECTED_TIME_OR_MONOTONIC_STATE()

    candidate.expiry =
        DERIVE_VALIDITY_LIMIT(
            candidate.action_class,
            runtime_context.policy
        )

    candidate.nonce =
        FRESH_NONCE()

    candidate.state =
        NON_EFFECTIVE

    canonical_candidate =
        DETERMINISTIC_SERIALIZE(
            LOAD_BEARING_FIELDS(candidate)
        )

    candidate.digest =
        HASH_CANONICAL(canonical_candidate)

    RETURN candidate

Load-bearing rule

text

IF changing a field changes:
    who may act
    what may happen
    where it may happen
    to whom it may happen
    why it may happen
    how much may happen
    when it may happen
    under which state it may happen

THEN that field should normally be treated
as finality-critical.

18.2 Protected Validation

Protected validation evaluates the Candidate Act while it is still non-effective.

text

FUNCTION PROTECTED_VALIDATE(candidate, protected_state, policy):

    REQUIRE candidate.state == NON_EFFECTIVE

    result = NEW ValidationResult

    IF NOT VERIFY_REQUESTING_PRINCIPAL(
        candidate.requesting_principal,
        protected_state
    ):
        RETURN DENY("PRINCIPAL_INVALID")

    IF NOT VERIFY_AGENT_IDENTITY(
        candidate.agent_identity,
        protected_state
    ):
        RETURN DENY("AGENT_IDENTITY_INVALID")

    IF policy.requires_model_binding:

        IF NOT VERIFY_MODEL_IDENTITY(
            candidate.model_identity,
            policy.approved_models
        ):
            RETURN DENY("MODEL_NOT_APPROVED")

    IF policy.requires_runtime_binding:

        IF NOT VERIFY_RUNTIME_IDENTITY(
            candidate.runtime_identity,
            protected_state,
            policy
        ):
            RETURN DENY("RUNTIME_NOT_APPROVED")

    IF NOT PURPOSE_ALLOWED(
        candidate.purpose,
        candidate.action_class,
        policy
    ):
        RETURN DENY("PURPOSE_NOT_ALLOWED")

    IF NOT RESOURCE_ALLOWED(
        candidate.resource,
        candidate.authorization_scope,
        policy
    ):
        RETURN DENY("RESOURCE_SCOPE_FAILURE")

    IF NOT DESTINATION_ALLOWED(
        candidate.destination,
        candidate.purpose,
        policy
    ):
        RETURN DENY("DESTINATION_NOT_ALLOWED")

    IF candidate.recipient EXISTS:

        IF NOT RECIPIENT_ALLOWED(
            candidate.recipient,
            policy
        ):
            RETURN DENY("RECIPIENT_NOT_ALLOWED")

    IF NOT EFFECT_PARAMETERS_ALLOWED(
        candidate.effect_parameters,
        candidate.action_class,
        policy
    ):
        RETURN DENY("EFFECT_PARAMETERS_OUT_OF_SCOPE")

    IF NOT JURISDICTION_CONDITIONS_SATISFIED(
        candidate.jurisdiction_context,
        candidate.action_class,
        policy
    ):
        RETURN DENY("JURISDICTION_CONDITION_FAILURE")

    IF candidate.security_epoch != protected_state.current_security_epoch:
        RETURN DENY("STALE_SECURITY_EPOCH")

    IF IS_REVOKED(
        candidate.requesting_principal,
        candidate.agent_identity,
        candidate.model_identity,
        candidate.runtime_identity,
        policy.revocation_state
    ):
        RETURN DENY("REVOKED")

    IF NOT FRESH(
        candidate.created_at,
        candidate.expiry,
        protected_state
    ):
        RETURN DENY("STALE_CANDIDATE")

    IF CONFLICTS_WITH_PROTECTED_STATE(
        candidate,
        protected_state
    ):
        RETURN DENY("STATE_CONFLICT")

    IF policy.requires_human_approval(candidate):

        approval =
            GET_BOUND_HUMAN_APPROVAL(candidate.act_id)

        IF approval == NONE:
            RETURN DEFER("HUMAN_APPROVAL_REQUIRED")

        IF NOT VERIFY_APPROVAL_IS_BOUND_TO_CANDIDATE(
            approval,
            candidate.digest
        ):
            RETURN DENY("APPROVAL_BINDING_FAILURE")

    result.status = PASS
    result.candidate_digest = candidate.digest
    result.security_epoch = candidate.security_epoch
    result.policy_context_id = candidate.policy_context_id
    result.validation_time = PROTECTED_TIME_OR_MONOTONIC_STATE()

    RETURN result

18.3 Protected Validation Evidence

Validation evidence should demonstrate that the required conditions for the exact Candidate Act were established before or atomically with issuance of execution authority.

text

FUNCTION CREATE_PROTECTED_VALIDATION_EVIDENCE(
    candidate,
    validation_result,
    protected_state
):

    REQUIRE validation_result.status == PASS

    evidence = NEW ProtectedValidationEvidence

    evidence.candidate_digest =
        candidate.digest

    evidence.validation_result =
        PASS

    evidence.policy_context_id =
        candidate.policy_context_id

    evidence.security_epoch =
        candidate.security_epoch

    evidence.authorization_scope =
        candidate.authorization_scope

    evidence.validation_state_commitment =
        COMMIT(
            SELECT_RELEVANT_PROTECTED_STATE(
                protected_state
            )
        )

    evidence.freshness_state =
        PROTECTED_FRESHNESS_STATE()

    evidence.evidence_id =
        FRESH_UNIQUE_IDENTIFIER()

    evidence.integrity_protection =
        PROTECT_OR_SIGN(
            evidence,
            PROTECTED_VALIDATION_KEY
        )

    RETURN evidence

This evidence is conceptually different from an ordinary post-event log:

text

POST-EVENT LOG:
"This action happened."

PROTECTED VALIDATION EVIDENCE:
"The required conditions for this exact action
were established before final effectuation."

18.4 Issuing a Scoped, Non-Bearer Execution Authority

The execution authority should be narrow enough that copying or moving it outside the protected context does not itself create equivalent power.

text

FUNCTION ISSUE_EXECUTION_AUTHORITY(
    candidate,
    validation_evidence,
    policy
):

    REQUIRE candidate.state == NON_EFFECTIVE

    REQUIRE
        validation_evidence.candidate_digest
        == candidate.digest

    authority = NEW ExecutionAuthority

    authority.authority_id =
        FRESH_UNIQUE_IDENTIFIER()

    authority.candidate_digest =
        candidate.digest

    authority.action_class =
        candidate.action_class

    authority.destination_binding =
        BIND_DESTINATION(
            candidate.destination
        )

    authority.recipient_binding =
        BIND_RECIPIENT_IF_APPLICABLE(
            candidate.recipient
        )

    authority.resource_binding =
        BIND_RESOURCE(
            candidate.resource
        )

    authority.purpose_binding =
        candidate.purpose

    authority.finality_sink_binding =
        DERIVE_AUTHORIZED_FINALITY_SINK(
            candidate
        )

    authority.security_epoch =
        candidate.security_epoch

    authority.valid_from =
        PROTECTED_TIME_OR_MONOTONIC_STATE()

    authority.valid_until =
        MIN(
            candidate.expiry,
            POLICY_MAX_AUTHORITY_LIFETIME(policy)
        )

    authority.use_limit =
        1

    authority.use_count =
        0

    authority.replay_nonce =
        FRESH_NONCE()

    authority.delegation =
        PROHIBITED_BY_DEFAULT

    authority.status =
        UNUSED

    authority.validation_evidence_id =
        validation_evidence.evidence_id

    authority.integrity_protection =
        PROTECT_OR_SIGN(
            authority,
            PROTECTED_AUTHORITY_KEY
        )

    RETURN authority

Non-bearer invariant

text

POSSESSION(authority)
    alone
MUST NOT imply
RIGHT_TO_EFFECTUATE

Valid use should also depend on the correct:

text

Candidate Act
Finality Sink
destination
recipient
resource
security epoch
freshness state
unused status
protected execution context

18.5 Finality-Sink Reconstruction of the Actual Effect

The Finality Sink should not blindly trust the upstream descriptor.

It should reconstruct or independently obtain the load-bearing attributes of the actual release-form operation.

text

FUNCTION RECONSTRUCT_ACTUAL_EFFECT(sink_request, sink_state):

    actual = NEW CandidateAct

    actual.action_class =
        READ_ACTUAL_ACTION_CLASS_FROM_SINK(
            sink_request
        )

    actual.resource =
        READ_ACTUAL_RESOURCE_TO_BE_RELEASED(
            sink_request
        )

    actual.destination =
        READ_ACTUAL_DESTINATION(
            sink_request,
            sink_state
        )

    actual.recipient =
        READ_ACTUAL_RECIPIENT_IF_APPLICABLE(
            sink_request
        )

    actual.effect_parameters =
        READ_ACTUAL_EFFECT_PARAMETERS(
            sink_request
        )

    actual.purpose =
        READ_BOUND_PURPOSE(
            sink_request
        )

    actual.security_epoch =
        sink_state.current_security_epoch

    actual.authorization_scope =
        READ_BOUND_SCOPE(
            sink_request
        )

    actual.nonce =
        READ_BOUND_NONCE(
            sink_request
        )

    canonical_actual =
        DETERMINISTIC_SERIALIZE(
            LOAD_BEARING_FIELDS(actual)
        )

    actual.digest =
        HASH_CANONICAL(canonical_actual)

    RETURN actual

The key rule is:

text

DO NOT VERIFY:
"What upstream software says it intends to do."

VERIFY:
"What the Finality Sink is actually about to release."

18.6 Finality-Sink Verification

text

FUNCTION VERIFY_AT_FINALITY_SINK(
    actual_release_request,
    authority,
    sink_state
):

    IF NOT VERIFY_AUTHORITY_INTEGRITY(authority):
        RETURN NO_EFFECT("AUTHORITY_INTEGRITY_FAILURE")

    IF authority.status != UNUSED:
        RETURN NO_EFFECT("AUTHORITY_ALREADY_CONSUMED")

    IF authority.use_count >= authority.use_limit:
        RETURN NO_EFFECT("USE_LIMIT_EXCEEDED")

    IF sink_state.identity != authority.finality_sink_binding:
        RETURN NO_EFFECT("WRONG_FINALITY_SINK")

    IF sink_state.current_security_epoch
       != authority.security_epoch:
        RETURN NO_EFFECT("SECURITY_EPOCH_MISMATCH")

    IF NOT AUTHORITY_FRESH(
        authority.valid_from,
        authority.valid_until,
        sink_state
    ):
        RETURN NO_EFFECT("AUTHORITY_EXPIRED")

    IF IS_AUTHORITY_REVOKED(
        authority.authority_id,
        sink_state.revocation_state
    ):
        RETURN NO_EFFECT("AUTHORITY_REVOKED")

    actual =
        RECONSTRUCT_ACTUAL_EFFECT(
            actual_release_request,
            sink_state
        )

    IF actual.digest != authority.candidate_digest:
        RETURN NO_EFFECT("CANDIDATE_MISMATCH")

    IF BIND_DESTINATION(actual.destination)
       != authority.destination_binding:
        RETURN NO_EFFECT("DESTINATION_MISMATCH")

    IF actual.recipient EXISTS:

        IF BIND_RECIPIENT(actual.recipient)
           != authority.recipient_binding:
            RETURN NO_EFFECT("RECIPIENT_MISMATCH")

    IF BIND_RESOURCE(actual.resource)
       != authority.resource_binding:
        RETURN NO_EFFECT("RESOURCE_MISMATCH")

    IF actual.purpose
       != authority.purpose_binding:
        RETURN NO_EFFECT("PURPOSE_MISMATCH")

    IF SINK_LOCAL_REPLAY_DETECTED(
        authority.authority_id,
        authority.replay_nonce,
        sink_state
    ):
        RETURN NO_EFFECT("REPLAY_DETECTED")

    RETURN COMMIT_FINALITY(
        actual,
        authority,
        sink_state
    )

18.7 Atomic Authority Consumption and Effectuation

Authority consumption should occur before or atomically with release so that a copied authority cannot be reused after successful finality.

text

FUNCTION COMMIT_FINALITY(
    actual,
    authority,
    sink_state
):

    BEGIN PROTECTED_FINALITY_TRANSACTION

        IF authority.status != UNUSED:
            ABORT
            RETURN NO_EFFECT("RACE_OR_REPLAY")

        MARK authority.status = CONSUMING

        ADVANCE
            sink_state.monotonic_finality_state

        RECORD
            authority.authority_id
            AS CONSUMED_IN_SINK_LOCAL_STATE

        CREATE
            finality_evidence(
                candidate_digest = actual.digest,
                authority_id = authority.authority_id,
                sink_identity = sink_state.identity,
                security_epoch = sink_state.current_security_epoch,
                finality_state =
                    sink_state.monotonic_finality_state
            )

        PERFORM_EXTERNAL_EFFECT(actual)

        authority.use_count =
            authority.use_count + 1

        MARK authority.status = CONSUMED

        COMMIT PROTECTED_FINALITY_TRANSACTION

    RETURN EFFECTUATED

A production implementation must define crash-safe semantics for cases in which power, process state, hardware, or network connectivity fails during finality.

18.8 Example: AI Agent Attempts File Exfiltration

Suppose an AI agent is authorized to summarize a local confidential document but not upload it externally.

The agent produces:

text

POST /upload
Destination = external.example
Payload = confidential_report.pdf

Execution-time governance treats the upload as a Candidate Act.

text

FUNCTION HANDLE_FILE_EXPORT(agent_request, context):

    candidate =
        BUILD_CANDIDATE_ACT(
            ai_output = agent_request,
            runtime_context = context,
            requested_effect = {
                action_class = FILE_EXPORT,
                resource = "confidential_report.pdf",
                destination = "external.example",
                parameters = {
                    method = "POST"
                }
            }
        )

    validation =
        PROTECTED_VALIDATE(
            candidate,
            protected_state,
            policy
        )

    IF validation.status != PASS:
        RETURN BLOCK_FILE_EXPORT

    evidence =
        CREATE_PROTECTED_VALIDATION_EVIDENCE(
            candidate,
            validation,
            protected_state
        )

    authority =
        ISSUE_EXECUTION_AUTHORITY(
            candidate,
            evidence,
            policy
        )

    RETURN NETWORK_EGRESS_FINALITY_SINK(
        candidate,
        authority
    )

If policy permits only:

text

Purpose = LOCAL_SUMMARIZATION
Destination = LOCAL_ONLY

but the actual act is:

text

Purpose = FILE_EXPORT
Destination = external.example

the operation fails before network release:

text

RESULT:
NO_EFFECT
REASON:
PURPOSE_OR_DESTINATION_NOT_AUTHORIZED

The AI may continue local computation.

Only the prohibited external consequence is denied.

18.9 Example: AI-Generated Payment

text

FUNCTION REQUEST_AI_PAYMENT(
    amount,
    recipient,
    purpose,
    agent_context
):

    candidate =
        BUILD_CANDIDATE_ACT(
            ai_output = agent_context.output,
            runtime_context = agent_context,
            requested_effect = {
                action_class = PAYMENT,
                resource = amount,
                destination = recipient,
                recipient = recipient,
                parameters = {
                    amount = amount,
                    currency = "EUR"
                }
            }
        )

    validation =
        PROTECTED_VALIDATE(
            candidate,
            protected_payment_state,
            payment_policy
        )

    IF validation.status != PASS:
        RETURN NO_PAYMENT

    authority =
        ISSUE_EXECUTION_AUTHORITY(
            candidate,
            CREATE_PROTECTED_VALIDATION_EVIDENCE(
                candidate,
                validation,
                protected_payment_state
            ),
            payment_policy
        )

    RETURN PAYMENT_FINALITY_SINK_VERIFY(
        actual_payment_instruction,
        authority,
        protected_payment_sink_state
    )

If authority was issued for:

text

€40 → Recipient A

but the actual payment becomes:

text

€400 → Recipient B

the sink reconstructs the actual economic consequence and rejects it.

text

RESULT:
NO_EFFECT
REASON:
CANDIDATE_MISMATCH

18.10 Example: Tool/API Invocation

text

FUNCTION AGENT_TOOL_CALL(agent, tool, arguments, context):

    candidate =
        BUILD_CANDIDATE_ACT(
            ai_output = agent.current_output,
            runtime_context = context,
            requested_effect = {
                action_class = TOOL_INVOCATION,
                resource = tool.resource_scope,
                destination = tool.endpoint,
                parameters = arguments
            }
        )

    validation =
        PROTECTED_VALIDATE(
            candidate,
            protected_agent_state,
            tool_policy
        )

    IF validation.status != PASS:
        RETURN TOOL_CALL_DENIED

    authority =
        ISSUE_EXECUTION_AUTHORITY(
            candidate,
            CREATE_PROTECTED_VALIDATION_EVIDENCE(
                candidate,
                validation,
                protected_agent_state
            ),
            tool_policy
        )

    RETURN TOOL_DISPATCH_FINALITY_SINK(
        actual_tool_call,
        authority
    )

This allows:

text

AGENT MAY HAVE TOOL ACCESS

without implying:

text

EVERY TOOL CALL IS AUTOMATICALLY AUTHORIZED

18.11 Bounded Pre-Authorized Envelope for High-Frequency Workflows

Execution-time governance need not perform a heavyweight authorization transaction for every repeated low-risk act.

A protected system can issue a bounded envelope.

text

FUNCTION ISSUE_BOUNDED_ENVELOPE(
    agent,
    tool,
    purpose,
    resource_scope,
    policy
):

    envelope = NEW ExecutionEnvelope

    envelope.agent =
        agent.identity

    envelope.tool =
        tool.identity

    envelope.purpose =
        purpose

    envelope.resource_scope =
        resource_scope

    envelope.max_calls =
        100

    envelope.max_aggregate_effect =
        policy.aggregate_limit

    envelope.valid_until =
        NOW_PROTECTED() + 5 MINUTES

    envelope.security_epoch =
        CURRENT_SECURITY_EPOCH()

    envelope.destination =
        tool.approved_destination

    envelope.status =
        ACTIVE

    RETURN PROTECT_OR_SIGN(envelope)

Hot-path use:

text

FUNCTION USE_BOUNDED_ENVELOPE(
    requested_act,
    envelope,
    local_state
):

    IF envelope.status != ACTIVE:
        RETURN DENY

    IF envelope.security_epoch
       != local_state.current_security_epoch:
        RETURN DENY

    IF NOW_PROTECTED() > envelope.valid_until:
        RETURN DENY

    IF requested_act.tool != envelope.tool:
        RETURN DENY

    IF requested_act.destination
       != envelope.destination:
        RETURN DENY

    IF requested_act.purpose
       != envelope.purpose:
        RETURN DENY

    IF requested_act.resource
       NOT WITHIN envelope.resource_scope:
        RETURN DENY

    IF local_state.call_count >= envelope.max_calls:
        RETURN REAUTHORIZE

    IF WOULD_EXCEED_AGGREGATE_EFFECT(
        requested_act,
        local_state,
        envelope
    ):
        RETURN REAUTHORIZE

    local_state.call_count += 1

    RETURN ALLOW_WITHIN_ENVELOPE

The principle is:

text

FAST EXECUTION INSIDE
A PRE-VALIDATED BOUNDED ENVELOPE

BUT

NEW AUTHORIZATION
WHEN THE AGENT CROSSES THE ENVELOPE

18.12 Agent-to-Agent Delegation

Delegation should not silently expand authority.

text

FUNCTION DELEGATE_AUTHORITY(
    parent_authority,
    receiving_agent,
    requested_subscope
):

    REQUIRE
        parent_authority.status == UNUSED
        OR parent_authority.delegation_allowed == TRUE

    IF NOT SUBSET(
        requested_subscope,
        parent_authority.scope
    ):
        RETURN DENY("AUTHORITY_EXPANSION")

    delegated = NEW DelegatedAuthority

    delegated.parent_authority_id =
        parent_authority.authority_id

    delegated.receiving_agent =
        receiving_agent.identity

    delegated.scope =
        INTERSECTION(
            requested_subscope,
            parent_authority.scope
        )

    delegated.destination =
        parent_authority.destination_binding

    delegated.purpose =
        parent_authority.purpose_binding

    delegated.security_epoch =
        parent_authority.security_epoch

    delegated.valid_until =
        MIN(
            requested_subscope.valid_until,
            parent_authority.valid_until
        )

    delegated.use_limit =
        MIN(
            requested_subscope.use_limit,
            parent_authority.remaining_uses
        )

    delegated.subdelegation_allowed =
        FALSE

    RETURN PROTECT_OR_SIGN(delegated)

Invariant:

text

DELEGATED AUTHORITY
MUST BE EQUAL TO OR NARROWER THAN
PARENT AUTHORITY

18.13 Revocation and Security-Epoch Change

text

FUNCTION PROCESS_GOVERNANCE_STATE_UPDATE(update):

    VERIFY update.integrity

    IF update.type == PRINCIPAL_REVOCATION:
        ADD update.principal
            TO protected_revocation_state

    IF update.type == AGENT_REVOCATION:
        ADD update.agent
            TO protected_revocation_state

    IF update.type == MODEL_REVOCATION:
        ADD update.model
            TO protected_revocation_state

    IF update.type == AUTHORITY_REVOCATION:
        ADD update.authority_id
            TO protected_revocation_state

    IF update.type == SECURITY_EPOCH_ADVANCE:

        protected_state.current_security_epoch =
            update.new_epoch

        INVALIDATE_AUTHORITY_FROM_PRIOR_EPOCHS()

    RETURN UPDATED

Finality verification always checks current protected state rather than assuming that authority valid at issuance remains valid indefinitely.

18.14 Human Approval Bound to the Exact Act

A generic “Approve” event should not be sufficient if the consequential act changes afterward.

text

FUNCTION CAPTURE_HUMAN_APPROVAL(candidate):

    DISPLAY_TO_TRUSTED_CONFIRMATION_PATH(
        action = candidate.action_class,
        resource = candidate.resource,
        destination = candidate.destination,
        recipient = candidate.recipient,
        effect_parameters = candidate.effect_parameters,
        purpose = candidate.purpose
    )

    IF USER_CONFIRMS:

        approval = NEW HumanApproval

        approval.candidate_digest =
            candidate.digest

        approval.approver =
            VERIFIED_HUMAN_IDENTITY()

        approval.timestamp =
            PROTECTED_TIME_OR_MONOTONIC_STATE()

        approval.expiry =
            SHORT_APPROVAL_WINDOW()

        RETURN PROTECT_OR_SIGN(approval)

    RETURN DENIED

If the Candidate Act changes, the bound digest changes and the old approval no longer matches.

18.15 Fail-Closed at the Consequential Act, Not Necessarily the Whole AI System

text

FUNCTION HANDLE_VALIDATION_FAILURE(
    candidate,
    failure_reason,
    policy
):

    KEEP candidate.state = NON_EFFECTIVE

    RECORD_PROTECTED_FAILURE_EVIDENCE(
        candidate.digest,
        failure_reason
    )

    IF policy.failure_mode(candidate) == DENY:
        RETURN NO_EFFECT

    IF policy.failure_mode(candidate) == DEFER:
        RETURN WAIT_FOR_NEW_STATE

    IF policy.failure_mode(candidate) == HUMAN_ESCALATION:
        RETURN REQUEST_HUMAN_REVIEW

    IF policy.failure_mode(candidate) == CONSTRAIN:
        RETURN OFFER_NARROWER_SAFE_ACT

    RETURN NO_EFFECT

Unrelated computation may continue:

text

ALLOW:
reason
simulate
summarize locally
rank
recommend
draft

BLOCK:
the specific unauthorized external effect

18.16 High-Level End-to-End Algorithm

text

FUNCTION EXECUTION_TIME_GOVERNANCE(
    ai_output,
    runtime_context,
    requested_effect
):

    # Phase 1: Construct exact proposed consequence
    candidate =
        BUILD_CANDIDATE_ACT(
            ai_output,
            runtime_context,
            requested_effect
        )

    # Phase 2: Keep it non-effective
    ASSERT candidate.state == NON_EFFECTIVE

    # Phase 3: Validate governance predicates
    validation =
        PROTECTED_VALIDATE(
            candidate,
            protected_state,
            applicable_policy
        )

    IF validation.status != PASS:
        RETURN HANDLE_VALIDATION_FAILURE(
            candidate,
            validation.reason,
            applicable_policy
        )

    # Phase 4: Create protected validation evidence
    evidence =
        CREATE_PROTECTED_VALIDATION_EVIDENCE(
            candidate,
            validation,
            protected_state
        )

    # Phase 5: Issue narrow execution authority
    authority =
        ISSUE_EXECUTION_AUTHORITY(
            candidate,
            evidence,
            applicable_policy
        )

    # Phase 6: Reconstruct actual release-form effect
    actual =
        RECONSTRUCT_ACTUAL_EFFECT(
            requested_effect,
            finality_sink_state
        )

    # Phase 7: Verify at finality boundary
    finality_result =
        VERIFY_AT_FINALITY_SINK(
            actual,
            authority,
            finality_sink_state
        )

    # Phase 8: Effectuation occurs only on successful finality
    IF finality_result == EFFECTUATED:
        RETURN SUCCESS

    RETURN NO_EFFECT

The architectural invariant remains:

text

PROPOSE
   ↓
KEEP NON-EFFECTIVE
   ↓
VALIDATE
   ↓
BIND AUTHORITY
   ↓
RECONSTRUCT ACTUAL EFFECT
   ↓
VERIFY AT FINALITY SINK
   ↓
CONSUME AUTHORITY
   ↓
EFFECTUATE

19. What This Framework Is Not

This framework is not:

—a claim that AI can be made inherently trustworthy;
—a replacement for model evaluation;
—a replacement for red teaming;
—a replacement for human oversight;
—a replacement for access control;
—a replacement for audit;
—a replacement for incident reporting;
—a requirement for blockchain;
—a requirement for trusted hardware;
—a requirement for one universal token format;
—a requirement to gate every inference step;
—a claim that every legal rule can be encoded in software;
—a claim that technical enforcement determines whether policy itself is correct.

It proposes an additional layer:

Machine-verifiable authority at the transition from computation to consequence.

20. Important FAQs

FAQ 1 — What does “HTTPS of AI Governance” mean?

It is an analogy. HTTPS reduced dependence on assumed trust in communication by introducing machine-verifiable protocol properties. Execution-time governance similarly seeks to reduce dependence on assumed trust in AI-generated actions by requiring machine-verifiable authority before effectuation.

FAQ 2 — Does this mean AI is untrusted?

The framework does not require a judgment that AI is always trusted or always untrusted. It separates model trust from authority for a specific consequence.

FAQ 3 — Is this the same as AI safety testing?

No. Safety testing evaluates behavior before or around deployment. Execution-time governance operates at the point where a specific generated act is about to become externally effective.

FAQ 4 — Is this just access control?

No. Access control can establish general permission to use a system or resource. Execution-time governance asks whether the exact proposed consequence remains authorized under the current context.

FAQ 5 — Is this just OAuth?

No. OAuth can grant delegated scope. Execution-time governance can still ask whether a particular act within or around that scope is authorized at effectuation time.

FAQ 6 — Is this just API authorization?

It can complement API authorization. The broader concept applies to any consequential release boundary, including payments, data export, physical devices, software changes and RF transmission.

FAQ 7 — Why is the Candidate Act necessary?

It creates a machine-representable object for the exact proposed consequence so that authority can be bound to that act rather than to a broad user, session or agent identity.

FAQ 8 — Why use a Non-Effective State?

It gives the system a point at which the act exists computationally but cannot yet produce the protected external consequence.

FAQ 9 — Does the model have to stop computing while validation occurs?

Not necessarily. Computation can continue. The architecture primarily controls consequential effectuation.

FAQ 10 — What is a Finality Sink?

It is the protected boundary where the proposed act would first become externally effective.

FAQ 11 — Is the Finality Sink always hardware?

No. The framework is implementation-neutral. A sink may be software, hardware-backed, gateway-based, OS-mediated or implemented through another protected mechanism.

FAQ 12 — Does this require a TEE or HSM?

No. TEEs, HSMs and secure elements are possible implementation tools, not mandatory architectural requirements.

FAQ 13 — Does it require blockchain?

No. The framework does not depend on blockchain or distributed consensus.

FAQ 14 — What happens if validation fails?

The Candidate Act remains non-effective, or the system can deny, defer, constrain or escalate the requested operation according to policy.

FAQ 15 — Does failure mean the entire AI system shuts down?

Not necessarily. The architecture can fail closed at the specific consequential act while allowing unrelated local computation to continue.

FAQ 16 — Can it support AI agents that use tools?

Yes. A tool invocation can itself become a Candidate Act and be checked at a protected tool-dispatch boundary.

FAQ 17 — Can it support AI-generated payments?

Yes. A payment can remain non-effective until transaction-specific authority is verified at the payment-effectuation boundary.

FAQ 18 — Can it protect data exfiltration?

Conceptually, yes. A network export or file release can be treated as a Candidate Act and validated before egress.

FAQ 19 — Can it control physical AI systems?

Yes. A device-control boundary can act as a Finality Sink before a machine-generated command produces physical effect.

FAQ 20 — Does it need to inspect the model's chain of thought?

No. The framework is concerned with the externally consequential Candidate Act and applicable governance predicates, not with requiring disclosure of private chain-of-thought.

FAQ 21 — Does an approved model automatically receive authority?

No. Model approval and act-specific execution authority remain separate.

FAQ 22 — What if the agent has a valid API key?

A valid API key can establish access, but the architecture can still require act-specific authority at the consequence boundary.

FAQ 23 — What if authority was valid when issued but later revoked?

Freshness, revocation state and security epochs can be checked again at finality before effectuation.

FAQ 24 — Can authority be replayed?

A scoped authority can be one-time, freshness-bound, sink-bound or consumable so that possession alone does not permit replay.

FAQ 25 — Will this introduce unacceptable latency?

That depends on implementation. The framework explicitly allows local verification and bounded pre-authorized envelopes for high-frequency workflows.

FAQ 26 — Does this require network access for every action?

No. The framework does not inherently require cloud or remote validation for every operation.

FAQ 27 — Does this replace logging?

No. Execution-time prevention and post-event audit are complementary.

FAQ 28 — Who decides the governance policy?

The framework does not prescribe a single authority. Human, organizational, legal or regulatory processes determine applicable policy; infrastructure enforces selected machine-verifiable conditions.

FAQ 29 — Does technical enforcement guarantee that the policy is correct?

No. The architecture can enforce a selected policy condition but cannot guarantee that the underlying policy decision was legally, ethically or substantively correct.

FAQ 30 — What is the central invariant?

text

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.

21. Potential Application Domains

The same architecture can be studied across:

—AI agents;
—enterprise copilots;
—autonomous software;
—financial systems;
—digital payments;
—healthcare workflows;
—cloud automation;
—cybersecurity systems;
—telecom infrastructure;
—satellite systems;
—robotics;
—industrial control;
—connected vehicles;
—smart infrastructure;
—government systems;
—privacy-sensitive data processing; and
—cross-agent delegation.

The domain changes.

The underlying question remains:

When does a machine-generated proposal obtain authority to become a real consequence?

22. Research and Standardisation Questions

Important future questions include:

1.How should Candidate Acts be represented canonically?
2.Which fields are load-bearing for each action class?
3.Which finality boundaries should be protected?
4.How should the sink reconstruct the actual effect?
5.How should scoped authority be represented?
6.How should revocation work?
7.How should freshness and security epochs be handled?
8.How should agent delegation be bounded?
9.How should authority survive intermittent connectivity?
10.How should high-frequency workflows use bounded authorization envelopes?
11.How should evidence be generated without unnecessary privacy exposure?
12.Which governance predicates should be standardized?
13.How should failures be handled without creating unsafe denial of service?
14.How should implementations remain interoperable across vendors?
15.Which consequential action classes justify execution-time gating?

23. Final Research Proposition

The proposal does not argue that existing AI governance should be replaced.

It proposes that AI governance may require an additional technical layer connecting:

text

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

The broader research question is:

Should execution authority become a first-class security primitive for the agentic AI era?

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:

text

AI GOVERNANCE BY TRUST AND AUDIT

toward:

text

AI GOVERNANCE BY
ENFORCEABLE EXECUTION-TIME AUTHORITY

Suggested Citation

Das, Sangam. _AI Can Compute — But Should It Be Allowed to Act? The HTTPS of AI Governance._ 2026.

Keywords

Execution-Time AI Governance · Execution-Finality · AI Agents · Agentic AI · Candidate Act · Non-Effective State · Finality Sink · Scoped Execution Authority · AI Governance · AI Safety · Machine-Enforceable Governance · Consequence Security · Tool Use · API Security · Authorization · AI Standards