Bounded Execution Programs for Consequential Agent Actions

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 4 February 2027.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

Consequential agents often need authority for a bounded sequence of related actions. Requiring a new authorization ceremony for every action can be impractical, but treating a goal, generated plan, profile name, or signature as open-ended authority removes the boundary that a gate is supposed to enforce.¶

This document defines EP-BOUNDED-EXECUTION-PROGRAM-v1. An authorizer signs one closed graph whose action occurrences, dependency outcomes, node and total-history ceilings, attempt budgets, validity interval, and supersession lineage are explicit. The runtime answers one narrow question: is this exact occurrence reachable now under this exact signed program, while all occurrence and attempt-budget limits remain available?¶

The signed object and the runtime state machine are inseparable. A signed graph without shared state cannot prevent replay or concurrent over-reservation. A runtime ledger without a verified signed graph has no portable authority boundary.¶

2. Terminology

Execution Program:

The immutable signed artifact defined in Section 3.¶

Program digest:

The domain-independent SHA-256 JCS digest of the complete signed body with the attached proof member omitted.¶

Node:

A named action selector, Trust Program digest, dependency set, occurrence ceiling, and fixed budget-charge set.¶

Occurrence:

One uniquely identified retained runtime record for an attempt to execute a node. Release does not remove it from total history.¶

AdmissionSnapshot:

A closed, immutable object that binds all verified inputs, resources, action identity, provider binding, and the one-time execution right for one consequential operation.¶

Ordinary path:

An admission reserve, begin, release, or expiry path that does not participate in the execution-program transaction.¶

Program-aware path:

An admission path that atomically evaluates and transitions both the ordinary admission state and the execution-program state.¶

Provider entry:

The boundary after which an external consequence might have occurred. The execution right and attempt charges are consumed before the invocation capability is released across this boundary.¶

Terminal provider outcome:

Either COMMITTED or PROVEN_NOT_COMMITTED.¶

Current program status:

A store-authoritative ACTIVE, SUSPENDED, or REVOKED observation for the exact program version and digest.¶

3. Closed Signed Program

The unsigned construction input is a closed I-JSON object [RFC7493] containing exactly the following members:¶

{
  "program_id": "program:production-remediation:01",
  "tenant_id": "tenant:example",
  "version": 1,
  "subject_id": "agent:operations:01",
  "audience": "gate:production:01",
  "objective_digest": "sha256:<64 lowercase hexadecimal digits>",
  "authorization_digest": "sha256:<64 lowercase hexadecimal digits>",
  "presentation_digest": "sha256:<64 lowercase hexadecimal digits>",
  "supersedes_program_digest": null,
  "issued_at": "2026-07-30T19:55:00.000Z",
  "valid_from": "2026-07-30T20:00:00.000Z",
  "expires_at": "2026-07-30T21:00:00.000Z",
  "max_total_occurrences": 64,
  "max_concurrent_effects": 4,
  "budgets": [
    { "budget_id": "attempts", "unit": "attempt", "limit": 3 }
  ],
  "nodes": [ "<one or more nodes as defined below>" ]
}

program_id, tenant_id, subject_id, and audience are nonempty identifiers. An identifier MUST match:¶

^[A-Za-z0-9][A-Za-z0-9:_.@/+\-]{0,511}$

A digest in this document is the string sha256: followed by exactly 64 lowercase hexadecimal digits. Version and numeric limits MUST be positive I-JSON safe integers. Version 1 MUST have a null supersedes_program_digest; a later version MUST contain the exact predecessor program digest.¶

objective_digest binds authorizer-selected objective bytes. It does not prove that natural-language intent was understood or correctly compiled. authorization_digest binds the independently verified authorization evidence on which the program relies. presentation_digest binds the approval or presentation material selected by the authorizer; it does not prove display integrity, human comprehension, or informed consent.¶

The three times use the RFC 3339 [RFC3339] date-time production restricted to UTC with a trailing Z. They MUST satisfy issued_at <= valid_from < expires_at. Expiration is exclusive.¶

max_total_occurrences is REQUIRED and MUST be a positive safe integer no greater than 1000000. It limits all retained occurrence records for the program, including occurrences later released before provider entry. Omission is a schema error.¶

max_concurrent_effects is REQUIRED and MUST be a positive safe integer no greater than 1000000. It limits the number of occurrences for this program that can be in INVOKING or INDETERMINATE. Reservation does not consume this ceiling; provider entry does. Omission is a schema error.¶

{
  "node_id": "remediate",
  "action": {
    "mode": "profile",
    "profile_id": "profile:terraform-reviewed-plan",
    "profile_digest": "sha256:<64 lowercase hexadecimal digits>"
  },
  "trust_program_digest": "sha256:<64 lowercase hexadecimal digits>",
  "depends_on": [
    { "node_id": "inspect", "outcomes": ["COMMITTED"] }
  ],
  "max_occurrences": 1,
  "charges": [
    { "budget_id": "attempts", "amount": 1 }
  ]
}

{ "mode": "exact", "caid": "caid:1:...",
  "action_digest": "sha256:<64 lowercase hexadecimal digits>" }

{ "mode": "profile", "profile_id": "profile:...",
  "profile_digest": "sha256:<64 lowercase hexadecimal digits>" }

caid           = "caid:1:" action-name "." action-version
                 ":jcs-sha256:" digest43
action-name    = component *("." component)
component      = LCALPHA *(LCALPHA / DIGIT / "-")
action-version = %x31-39 *DIGIT
digest43       = 43base64url-char
base64url-char = ALPHA / DIGIT / "-" / "_"
LCALPHA        = %x61-7A

4. Canonicalization, Signature, and Program Digest

Before signing, an implementation MUST validate the complete construction input and then normalize it as follows:¶

1. Convert each accepted UTC instant to RFC 3339 UTC form with exactly three fractional-second digits.¶
2. Sort budgets by the UTF-8 byte order of budget_id.¶
3. Sort nodes by the UTF-8 byte order of node_id.¶
4. Sort dependencies by the UTF-8 byte order of predecessor node_id.¶
5. Sort charges by the UTF-8 byte order of budget_id.¶
6. Sort each dependency's terminal outcome strings in ascending byte order.¶

The signer adds the fixed version, claim boundary, and issuer:¶

{
  "@version": "EP-BOUNDED-EXECUTION-PROGRAM-v1",
  "<normalized program members>": "...",
  "claim_boundary": "<CLAIM_BOUNDARY>",
  "issuer": { "id": "customer:example", "key_id": "key:example" }
}

In that example, CLAIM_BOUNDARY is the concatenation, with no intervening octets, of the following two ASCII strings:¶

"typed_reachability_attempt_budget_and_effect_concurrency_not_" ||
"intent_safety_effect_truth_or_complete_mediation"

The || notation in this display means byte concatenation; it is not part of the member value.¶

Let body_jcs be the UTF-8 encoding of the JSON Canonicalization Scheme (JCS) [RFC8785] representation of that complete body. The signer computes:¶

body_digest = "sha256:" || lowercase_hex(SHA-256(body_jcs))
signature_input = UTF8("EP-BOUNDED-EXECUTION-PROGRAM-v1")
                  || 0x00 || body_jcs
signature = Ed25519-Sign(authorizer_private_key, signature_input)

The signer attaches one closed proof object:¶

{
  "algorithm": "Ed25519",
  "key_id": "key:example",
  "body_digest": "sha256:<64 lowercase hexadecimal digits>",
  "signature_b64u": "<canonical unpadded base64url>"
}

proof.key_id MUST equal issuer.key_id. The signature uses Ed25519 [RFC8032]. The signature value uses the URL- and filename-safe Base64 alphabet without padding [RFC4648] and MUST decode to exactly 64 octets.¶

The program_digest is body_digest: the prefixed lowercase SHA-256 digest of the JCS body with proof omitted. It identifies the authorizer, program, and every signed boundary. It is not the digest of the proof-bearing artifact.¶

5. Verification and Registration

The program-aware store MUST own its program-authorizer verification policy and clock. The registration caller MUST NOT nominate trusted keys, expected authorizer identity, verification time, key role, or key status. The store policy binds each key identifier to an issuer identifier, canonical Ed25519 public key, the exact role program_authorizer, and one of ACTIVE, SUSPENDED, or REVOKED. Only a pin whose role is program_authorizer and whose key status is ACTIVE is eligible to register or supersede a v1 program.¶

The artifact's issuer.key_id can select only among those store-owned eligible pins; it cannot create or alter a trust root. The store derives the expected authorizer identity from the selected pin and obtains verification time from its own clock.¶

The caller supplies one closed relying-party context containing exactly:¶

• expected program identifier;¶
• expected tenant identifier;¶
• expected authorization digest;¶
• expected audience.¶

Unknown or caller-added trust and clock members MUST be refused as an invalid context. The store MUST validate the proof envelope, recompute the body digest, require the exact pinned issuer and key, parse the key as Ed25519, and verify the signature over the domain-separated canonical body. All caller context values MUST exactly equal the signed values. Acceptance is valid only while valid_from <= store_now < expires_at. A valid signature over an invalid, noncanonical, open-shaped, context-substituted, inactive-key, or time-invalid program MUST be refused.¶

6. Deterministic AdmissionSnapshot Binding

A program occurrence MUST be represented inside its immutable AdmissionSnapshot by exactly one resource whose kind is execution_program. The resource is derived from this closed binding object:¶

{
  "@version": "EP-BOUNDED-EXECUTION-PROGRAM-ADMISSION-BINDING-v1",
  "tenant_id": "tenant:example",
  "program_digest": "sha256:<64 lowercase hexadecimal digits>",
  "node_id": "remediate",
  "occurrence_id": "occurrence:remediate:01",
  "expires_at": "2026-07-30T20:10:00.000Z"
}

The resource fields are computed exactly as follows:¶

identity_tuple = [tenant_id, program_digest, node_id, occurrence_id]
identity_domain =
  "EP-BOUNDED-EXECUTION-PROGRAM-ADMISSION-" ||
  "BINDING-v1:IDENTITY"
identity_input = UTF8(identity_domain) || 0x00 ||
                 UTF8(JCS(identity_tuple))
identity_digest =
  "sha256:" || lowercase_hex(SHA-256(identity_input))

kind = "execution_program"
resource_id = "execution-program:" || identity_digest
reservation_id = "execution-program-reservation:" ||
                 identity_digest
digest_input =
  UTF8("EP-BOUNDED-EXECUTION-PROGRAM-ADMISSION-BINDING-v1:DIGEST") ||
  0x00 || UTF8(JCS(binding_object))
digest = "sha256:" || lowercase_hex(SHA-256(digest_input))
expires_at = binding_object.expires_at

The binding's tenant_id, program_digest, node_id, and occurrence_id MUST equal the values being reserved. Its expires_at MUST equal the AdmissionSnapshot expiry. The resource participates in the AdmissionSnapshot's normal resource sorting and snapshot-digest computation.¶

The identity digest is over a structured JCS array, not a delimiter- joined string. The resulting resource and reservation identifiers are fixed-length digest keys. Implementations MUST NOT substitute raw caller- controlled identifiers, ambiguous delimiter concatenation, or another tuple encoding.¶

If the caller supplies mutable AdmissionSnapshot input without this resource, the program-aware store MUST add the resource and then compute the snapshot digest. If the caller supplies a precomputed immutable AdmissionSnapshot, the store MUST accept it only when it already contains exactly the expected resource. A snapshot with no binding, more than one execution-program resource, or a nonidentical binding MUST be refused with no state change.¶

Before adding or accepting the binding, the store MUST also require: the candidate-manifest subject to equal the signed subject_id; the authorization input payload digest to equal the signed authorization_digest; the AdmissionSnapshot authorization policy digest to equal the node's trust_program_digest; and the exact or profile action match defined in Section 3.3.¶

The normalized AdmissionSnapshot expiry MUST be no later than the signed program expiry. A later admission expiry MUST refuse with program_expiration_mismatch before any occurrence, budget, resource, operation-head, or journal state is created. Equality is permitted because both expirations are exclusive.¶

7. Program-Aware Runtime

Registration of an accepted version 1 program creates one active runtime state. It records store-clock status metadata, initializes total_occurrences to zero, initializes reserved and consumed values to zero for every independent budget_id while retaining each signed unit label, and contains no occurrences.¶

The program state, occurrence state, authorization-digest fence, AdmissionSnapshot, ordinary resource reservations, and one-time execution right MUST share one linearizable transaction domain. A compensating sequence across independent stores is not atomic and does not conform to this profile.¶

RESERVED -> INVOKING -> COMMITTED
                    \-> PROVEN_NOT_COMMITTED
                    \-> INDETERMINATE -> COMMITTED
                                      \-> PROVEN_NOT_COMMITTED
RESERVED -> RELEASED

8. Supersession and Replanning

Programs are immutable. Replanning creates a newly signed and independently accepted version. The predecessor MUST be the active head. A successor MUST bind its exact program digest, have exactly predecessor.version + 1, and preserve the predecessor's tenant ID, program ID, subject ID, audience, objective digest, presentation digest, and program-authorizer identity. These are frozen identity and intent bindings for v1 supersession.¶

The successor MUST carry a distinct authorization digest that differs from the predecessor and has never previously been registered in the store's authorization-owner domain. The caller MUST supply that fresh digest in the closed relying-party registration context. Reuse, a skipped version, changed frozen binding, changed authorizer, wrong predecessor, or an already-owned authorization digest MUST fail closed.¶

Any predecessor occurrence still in RESERVED MUST block supersession. On successful supersession, the store atomically marks the predecessor SUPERSEDED, installs the successor as the active head, and binds the successor's authorization digest into the ordinary- path fence. The predecessor then refuses new reservations and new invocation starts.¶

Already invoking or indeterminate predecessor work remains reconcilable. The successor starts with zero reserved and consumed budgets, total_occurrences zero, fresh node and terminal indexes, and no occurrences. Budget, occurrence, evidence, and terminal state MUST NOT silently carry forward. A successor can depend on earlier effects only through separately verified evidence explicitly admitted by the successor's own action-specific Trust Program.¶

9. Refusal Semantics

Reservation and registration refusals are fail-closed and MUST NOT create occurrence, budget, admission, resource, operation-head, journal, or execution-right state. A store MAY retain a newer authenticated program-status observation. A begin refusal caused by program status, program expiry, or admission currentness deliberately performs the atomic pre-entry release defined in Section 5.2. Implementations MAY expose a more detailed local error vocabulary. The following reasons define interoperable semantic classes used by the reference profile:¶

10. Security Considerations

The principal threats are open-ended authority, graph substitution, action substitution, profile-name trust, authorization reuse, ordinary- path bypass, replay, reserve-release history exhaustion, concurrent over- reservation, delimiter aliasing, stale or caller-selected status, budget restoration after provider entry, and unsafe retry after an indeterminate outcome. Closed signed shapes, store-owned trust and clock, authenticated profile evidence, current status, total-history and occurrence fences, structured resource keys, the authorization-digest fence, and one linearizable state domain address those threats at the admission boundary.¶

Private signing keys and store-owned out-of-band key pins require lifecycle, rotation, compromise, role, suspension, revocation, and audit controls. A caller MUST NOT be able to extend the trust-root set or choose the verification clock. A signature establishes that an eligible pinned key signed canonical bytes. It does not establish that the key holder understood the objective, that a presentation was faithful, that a profile is safe, or that the selected limits are appropriate.¶

Profile matching is security-critical. The store MUST configure the authenticated verifier and pin both the profile identifier and digest. Free-form model assertions, caller-authored MATCH objects, an unverified profile name, or evidence not sealed into the singleton AEB input MUST NOT satisfy a node.¶

The total-history ceiling intentionally does not restore capacity on release. This bounds retained state but also lets an authorized requester consume the signed history allowance through repeated reserve-release cycles. Authorizers SHOULD choose the ceiling and admission rate controls for that denial-of-service exposure; implementations MUST NOT evade it by deleting records or decrementing total_occurrences.¶

The authorization-digest fence closes bypass only within its shared transaction and enforcement domain. A deployment with another mutation credential, provider path, replica, or store outside that domain does not have complete mediation. Such a deployment MUST NOT claim program-wide enforcement merely because the signed object verifies.¶

INDETERMINATE is material uncertainty, not failure and not permission to retry. It continues to occupy a concurrent-effect slot until authenticated reconciliation records a terminal outcome. Reconciliation can change the recorded provider outcome but cannot reconstruct event order from evidence that does not establish it.¶

11. Privacy Considerations

Programs and AdmissionSnapshots can reveal objectives, tenant and subject identifiers, action relationships, provider operations, timing, budgets, and incident-response structure. Implementations SHOULD use pseudonymous identifiers where accountability permits, minimize program duration and graph detail, disclose digests instead of underlying evidence when appropriate, and enforce access controls and retention periods for runtime records.¶

Digesting low-entropy or guessable material does not make it secret. Sensitive objective, authorization, and presentation material SHOULD use confidentiality and selective-disclosure controls outside this profile.¶

12. Implementation Status

An Apache-2.0 same-team reference implementation defines closed program construction, normalization, Ed25519 signing, verification, program digests, mandatory total-history fencing, structured deterministic AdmissionSnapshot resource binding, store-owned program trust and clock, authenticated action-match verification, current-status processing, in-memory and PostgreSQL program-aware admission surfaces, and language-neutral syntax and runtime vectors. The repository also contains bounded state-machine analysis.¶

These artifacts are implementation and regression evidence for this Experimental profile. They are not evidence of an independent implementation, cross-vendor interoperability, a durable production deployment, complete mediation, unbounded formal proof, standardization, certification, or legal effect.¶

13. Operational Reporting (Informative)

The separate signed EP-BOUNDED-EXECUTION-REPORT-v1 artifact can authenticate a relying-party-generated snapshot of the runtime state and retained occurrence inventory for one verified program. It is not an authorization and is not required to execute this protocol.¶

That report's boundary is Gate-recorded program occurrences only. It does not prove external effect truth, event chronology, program safety, complete mediation of mutation paths, the absence of actions performed outside Gate, or that an action was "executed outside the plan". An outside-plan claim requires a separately signed external inventory root with its own population-completeness and capture-topology boundary.¶

14. IANA Considerations

This document has no IANA actions. Protocol identifiers, resource-kind strings, refusal reasons, and action-profile identifiers in this revision are closed by the profile and are not IANA registries. A future revision can request registries or media types after implementation and interoperability experience justifies them.¶

15. Claim Boundary

Verification can establish that a pinned authorizer signed one canonical program. A conforming runtime can establish that it admitted or refused an occurrence according to that program's typed reachability, current-status, total-history, node-occurrence, attempt-budget, AdmissionSnapshot-binding, and supersession rules within one transaction domain, including the signed provider-entry concurrency ceiling.¶

It does not establish that natural-language intent was understood or correctly compiled; that an action profile is sound; that a plan is safe, lawful, optimal, or free of prompt injection; that provider evidence, observed effects, or production event chronology are true; that every mutation path was mediated; that no action occurred outside Gate or the program; or why an observed effect diverged.¶

Author's Address