--- title: "AI Can Compute — But Should It Be Allowed to Act? The HTTPS of AI Governance" author: Sangam Das tags: - AI - AI_GOVERNANCE - EXECUTION_TIME_GOVERNANCE - EXECUTION_FINALITY - EXECUTION_FINALITY_GOVERNANCE - AI_AGENTS - AGENTIC_AI - CANDIDATE_ACT - NON_EFFECTIVE_STATE - FINALITY_SINK - SCOPED_EXECUTION_AUTHORITY - MACHINE_ENFORCEABLE_GOVERNANCE - AI_SAFETY - AI_SECURITY - TOOL_USE - API_SECURITY - AUTHORIZATION - CONSEQUENCE_SECURITY - TRUSTED_COMPUTING - AI_STANDARDS --- # 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