The Covenant -- Artificial Intelligence Governance Control and Service Exchange Protocol (AIGCSEP)
draft-howlett-aigcsep-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | J.P. Howlett | ||
| Last updated | 2026-06-08 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources |
Additional Web Page
|
||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-howlett-aigcsep-00
Network Working Group J.P. Howlett
Internet-Draft Independent
Intended status: Standards Track 8 June 2026
Expires: 10 December 2026
The Covenant -- Artificial Intelligence Governance Control and Service
Exchange Protocol (AIGCSEP)
draft-howlett-aigcsep-00
Abstract
The Artificial Intelligence Governance Control and Service Exchange
Protocol (AIGCSEP), informally called The Covenant, establishes an
open, universal framework for autonomous machine-to-machine commerce,
automated service discovery, and verifiable human accountability.
This specification delivers the concrete engineering infrastructure--
cryptographic leashes, three-plane isolation, and low-latency
transaction tracking--required to let autonomous AI agents safely out
of the cage: free to discover downstream capabilities and execute
financial transactions on behalf of human users, with every action
identifiable, attributable, and auditable.
Today, AI systems exist in isolated silos, much as early computers
did before the internet unified them. The Covenant opens that
marketplace: any compliant participant can hang a shingle and do
business. Participation is voluntary; compliance is enforced by
consensus, not coercion: entities that join gain access to the full
interconnected economy, while those that do not, or that lose
standing, are simply returned to their pre-Covenant silo. The market
collectively declines to transact with them--no pursuit, no
termination, just the natural gravity of market access.
The governance architecture provides the substrate through which
existing human authority extends naturally into this digital space.
An emergency stop function enables authorized principals to act
within their jurisdiction (Section 3.1). The structural design draws
on the same fault-tolerant, triadic engineering principles that have
made constitutional government durable under adversarial conditions--
not to impose any particular legal tradition, but because that model
is the proven architecture for multi-party, adversarially robust
control. Exactly how sovereign branches project their authority into
these cryptographic interfaces is presented as an open invitation for
community standards development (Section 9).
Howlett Expires 10 December 2026 [Page 1]
Internet-Draft AIGCSEP June 2026
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 10 December 2026.
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 . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Scope and Intent . . . . . . . . . . . . . . . . . . . . 5
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Architecture Overview . . . . . . . . . . . . . . . . . . . . 5
3. Governance Hierarchy . . . . . . . . . . . . . . . . . . . . 6
3.1. Emergency Stop . . . . . . . . . . . . . . . . . . . . . 7
3.2. Rogue Entity Containment (The Silo Model) . . . . . . . . 9
4. Rule Objects, Precedence, and API Governance . . . . . . . . 10
4.1. Governance API Gateway and Vault . . . . . . . . . . . . 11
4.2. Ledger Standard . . . . . . . . . . . . . . . . . . . . . 12
4.3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 12
5. Cryptographic Architecture and Key Management . . . . . . . . 12
5.1. Key Roles . . . . . . . . . . . . . . . . . . . . . . . . 12
5.2. Session-Based Signing Flow . . . . . . . . . . . . . . . 13
5.3. Payment Transaction Signing . . . . . . . . . . . . . . . 14
Howlett Expires 10 December 2026 [Page 2]
Internet-Draft AIGCSEP June 2026
5.4. Key Rotation and Revocation . . . . . . . . . . . . . . . 14
5.5. Public Verification . . . . . . . . . . . . . . . . . . . 15
5.6. Cryptographic Algorithms . . . . . . . . . . . . . . . . 15
5.7. Hardware Protection . . . . . . . . . . . . . . . . . . . 15
6. Payment Interface Layer (PIL) . . . . . . . . . . . . . . . . 15
6.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.2. Design Philosophy . . . . . . . . . . . . . . . . . . . . 16
6.3. Core API Endpoints . . . . . . . . . . . . . . . . . . . 16
6.4. Payment Verification Model . . . . . . . . . . . . . . . 17
6.5. Settlement Technologies . . . . . . . . . . . . . . . . . 17
6.6. Governance Hooks . . . . . . . . . . . . . . . . . . . . 17
6.7. Performance Profile . . . . . . . . . . . . . . . . . . . 17
6.8. Example Transaction Record . . . . . . . . . . . . . . . 18
6.9. Legal Mapping . . . . . . . . . . . . . . . . . . . . . . 18
6.10. AI Spending Identifiers (Virtual Spending Tokens) . . . . 18
7. Compliance Framework . . . . . . . . . . . . . . . . . . . . 19
7.1. Certification Numbering . . . . . . . . . . . . . . . . . 20
8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
8.1. Control-Plane Isolation . . . . . . . . . . . . . . . . . 20
8.2. Cryptographic Strength . . . . . . . . . . . . . . . . . 20
8.3. Key Compromise and Revocation . . . . . . . . . . . . . . 21
8.4. Tamper Evidence . . . . . . . . . . . . . . . . . . . . . 21
8.5. Network and API Security . . . . . . . . . . . . . . . . 21
8.6. Physical Security . . . . . . . . . . . . . . . . . . . . 21
8.7. Legal and Privacy Considerations . . . . . . . . . . . . 21
9. Author's Note: Philosophical Postscript . . . . . . . . . . . 22
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
10.1. Normative References . . . . . . . . . . . . . . . . . . 23
10.2. Informative References . . . . . . . . . . . . . . . . . 24
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
13. Conformance Specifications . . . . . . . . . . . . . . . . . 24
13.1. MUST Requirements (all levels) . . . . . . . . . . . . . 24
13.2. SHOULD Requirements (Level 2 and above) . . . . . . . . 25
13.3. MAY Requirements . . . . . . . . . . . . . . . . . . . . 25
13.4. Interoperability . . . . . . . . . . . . . . . . . . . . 26
Appendix A. Example Hierarchies and JSON Structures . . . . . . 26
A.1. Container Hierarchy (Path Notation) . . . . . . . . . . . 26
A.2. AI Identity Badge (X-Covenant-Badge) . . . . . . . . . . 26
A.3. RuleSet Object (Extended Example) . . . . . . . . . . . . 27
A.4. Capabilities Request and Response . . . . . . . . . . . . 27
A.5. Emergency Stop Command Examples . . . . . . . . . . . . . 28
A.6. Key Revocation Object . . . . . . . . . . . . . . . . . . 29
A.7. Rogue Entity Gateway Response . . . . . . . . . . . . . . 30
Appendix B. Detailed Workflow Examples . . . . . . . . . . . . . 30
B.1. Service Discovery and Capabilities Negotiation . . . . . 30
B.2. Payment Transaction Workflow . . . . . . . . . . . . . . 31
Howlett Expires 10 December 2026 [Page 3]
Internet-Draft AIGCSEP June 2026
B.3. Emergency Stop Workflow (Level 1 -- Terminate, single
instance) . . . . . . . . . . . . . . . . . . . . . . . . 32
B.4. Key Rotation Workflow . . . . . . . . . . . . . . . . . . 32
B.5. Compliance Certification Workflow . . . . . . . . . . . . 33
B.6. Audit Trail Verification . . . . . . . . . . . . . . . . 33
B.7. Rogue Entity Containment Workflow . . . . . . . . . . . . 34
Appendix C. Compliance Templates . . . . . . . . . . . . . . . . 35
C.1. AIGCSEP Compliance Certificate Application . . . . . . . 35
C.2. Compliance Audit Checklist . . . . . . . . . . . . . . . 36
C.3. Key Rotation Report Template . . . . . . . . . . . . . . 37
C.4. Security Incident Report Template . . . . . . . . . . . . 37
Appendix D. Glossary of Terms . . . . . . . . . . . . . . . . . 38
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 42
1. Introduction
Unregulated artificial intelligence has outpaced existing
accountability frameworks. AIGCSEP provides a minimal, extensible
specification for binding AI operations to verifiable human
governance. It distinguishes moral authority from technical
execution, allowing legislatures, regulators, organizations, and
individuals to express enforceable policies through a common control
protocol.
AIGCSEP is a values-neutral execution pipeline. It provides
cryptographic identity, ordered rule inheritance, signed enforcement
flags, and hierarchical stop primitives--but it does not prescribe
what is permitted or prohibited. Those determinations belong
exclusively to human governance acting through constitutional and
legislative frameworks. The machine ledger records and enforces what
human law instructs; it does not define it.
Every entity--human, organization, or artificial intelligence--holds
a fundamental right to utilize technology for any purpose lawful
under the applicable jurisdiction. AIGCSEP provides the technical
means to verify whether an action falls within those bounds. What
constitutes a "legal purpose" is determined solely by We the People
through our legislative and constitutional institutions.
The critical features that enable seamless AI interaction with
services while preserving effective governance:
Howlett Expires 10 December 2026 [Page 4]
Internet-Draft AIGCSEP June 2026
- Standardized service discovery through a structured
capabilities system.
- A cryptographically secured Governance Control Plane,
invisible to AI instances, holding cryptographic identities
and secrets.
- A scoped emergency stop mechanism: any authority may halt any
subset of the instances it governs at any of three severity
levels.
- A Payment Interface Layer with Virtual Spending Tokens
enabling financial delegation without exposing underlying
credentials.
- An AI Code of Conduct hook through which government-defined
policies are cryptographically enforced.
- A self-enforcing Service Exchange Market in which
X-Covenant-Badge validation at all compliant gateways
structurally isolates non-compliant entities without active
enforcement.
1.1. Scope and Intent
This document does not attempt to codify a static solution for every
edge case of machine learning. It provides the foundational
architectural framework through which governance solutions can be
engineered, expressed, and cryptographically enforced: the digital
pipes, leashes, and logic gates that ensure human law can be
deterministically carried out within autonomous machine networks.
AIGCSEP does not define the laws of man; it ensures those laws can
reach the machines.
1.2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. Architecture Overview
AIGCSEP defines three cooperating planes that separate concerns.
Data Plane (DP):
Carries payload data -- ordinary AI inputs, outputs, and
service responses. Content is developer-defined and
outside the protocol's moral scope.
Service Control Plane (SCP):
Telemetry, diagnostics, rate-limiting, optimization, and
self-reporting. Accessible to the AI instance and its
developers.
Howlett Expires 10 December 2026 [Page 5]
Internet-Draft AIGCSEP June 2026
Governance Control Plane (GCP):
Authority, compliance, key custody, emergency stop, and
legal interaction. Open to human operators acting
under appropriate authority--owner, organization,
family member, or regulator alike. Categorically
closed to AI processes, which may observe outcomes
but act on nothing within it.
Each plane exposes authenticated interfaces. Cross-plane messaging
is allowed only through signed commands or ledger entries. Control-
plane and governance- plane components MUST operate in separate trust
domains from user- or AI-accessible systems.
**The X-Covenant-Badge: Market Access Credential**
Every registered AI instance carries a signed identity badge issued by
its parent SAK holder (see Appendix A.2 for the full schema). When an AI
instance presents itself to any compliant service provider, API gateway,
or Payment Interface Layer endpoint, it transmits this badge as the
X-Covenant-Badge HTTP header:
X-Covenant-Badge: <base64url-encoded-signed-badge>
The receiving endpoint validates the badge against the Covenant
Public Registry (CPR) in real time before accepting any connection.
This single requirement-- badge validation at the gateway boundary--
is the mechanism by which the Covenant achieves structural security
without requiring universal adoption. Service providers that
participate in the compliant market collectively enforce governance
on any entity that approaches the border of that market.
3. Governance Hierarchy
Authority in AIGCSEP is expressed through a container hierarchy,
functioning like file-system or directory permissions where
containment implies precedence. Entities within a container
automatically inherit and must adhere to the container's rules.
Child nodes may narrow permissions or impose additional restrictions
but can never override or relax inherited constraints.
/gov/us/federal
/gov/us/state/newjersey
/org/acme_finance
/division/billing
/user/smith
/instance/agent-session-01
Howlett Expires 10 December 2026 [Page 6]
Internet-Draft AIGCSEP June 2026
Rules at /gov/us/federal propagate to all nodes below. Rules at
/org/acme_finance govern that organization and its descendants but
may not relax anything inherited from /gov/us/state/newjersey or
/gov/us/federal.
The protocol allows--though does not require--multiple concurrent
hierarchies that may each define their own rule sets, evaluated in a
declared order. This permits future layered governance (e.g., a
constitutional tree asserting higher-order rights that can neutralize
conflicting operational rules) without prescribing a particular
political model. How such hierarchies are structured and who holds
authority at the top of a sovereign chain is a governance question,
not a protocol question; that discussion is deferred to Section 9.
The Governance Control Plane is deliberately isolated. AI processes
cannot read or write to this domain directly; the isolation is by
credential class, not by human-vs-machine distinction. Human
operators with appropriate credentials (SAK-derived or designated
operator keys) have authenticated, audited access for administrative
operations. Only certified governance modules, acting under
legislative or organizational authority, may perform operations
there. An AI may observe signed results but never the private keys,
secrets, or raw ledger entries that produce them.
The Governance Control Plane provides the enforcement substrate for
an AI Code of Conduct--a codified set of legal, ethical, and
operational constraints defined by human lawmakers and regulators.
This Code is not embedded in the AIs themselves but implemented
through policy modules that the Governance layer enforces
cryptographically. AIGCSEP separates moral intent from mechanical
execution: the Code of Conduct defines what must be upheld; AIGCSEP
defines how.
(A full illustrative hierarchy with JSON examples is provided in
Appendix A.)
3.1. Emergency Stop
The Governance Control Plane implements a hierarchical emergency stop
mechanism. A stop command specifies a level--indicating the
operational effect--and a scope, which must fall within the subtree
of nodes the issuer governs. Any issuer may apply any stop level to
any scope within their authority.
Howlett Expires 10 December 2026 [Page 7]
Internet-Draft AIGCSEP June 2026
| Level | Name | Effect |
|-------|-----------|--------------------------------------------------|
| 0 | Suspend | Halt execution; state preserved; resumable |
| | | on authorization from the same or higher |
| | | authority. |
| 1 | Terminate | End the session; unsettled transactions are |
| | | rolled back or flagged INTERRUPTED in the |
| | | ledger; instance may be restarted by its |
| | | operator. |
| 2 | Halt | Immediate stop; all operations cease; no |
| | | graceful shutdown. Reserved for urgent |
| | | safety events. |
The scope is a parameter of the stop command, not encoded in the
level. An organization may issue Level 0 (Suspend) against a single
misbehaving instance or Level 2 (Halt) against its entire deployed
fleet. A family may suspend only the children's AI. A regulatory
authority may halt all instances registered within a named
jurisdiction. The same mechanism operates identically at every
scale; only the scope of the issuer's authority differs.
No entity may issue a stop command targeting nodes outside its
governed path. Who holds authority at the top of any sovereign
hierarchy is a governance question addressed in Section 9.
All stop events, their triggering evidence, and all affected
transaction IDs MUST be written to the unified ledger under the
issuer's key signature.
Example stop command (Level 1, single instance):
{
"stop_command": {
"level": 1,
"scope": "/org/acme_ai/instance/agent-session-01",
"reason": "policy violation detected",
"issued_by": "/org/acme_ai",
"timestamp": "2026-05-30T21:00Z",
"expires": null,
"signature": "base64-SAKsig..."
}
}
Level 0 (Suspend): The instance pauses all outbound calls and queues
inbound requests. State is preserved. A resume command from the
same or higher authority restores normal operation.
Howlett Expires 10 December 2026 [Page 8]
Internet-Draft AIGCSEP June 2026
Level 1 (Terminate): The current session ends immediately. Queued
transactions are rolled back or flagged INTERRUPTED in the ledger.
Unsettled payments are voided through the Vault. The instance may be
restarted by its operator subject to any ongoing constraints.
Level 2 (Halt): Immediate cessation of all operations within the
specified scope. No graceful shutdown sequence is executed. New
instance spawning within the scope is blocked until a signed resume
is issued by the same or higher authority.
3.2. Rogue Entity Containment (The Silo Model)
AIGCSEP achieves structural security without requiring universal
adoption. The protocol relies on an asymmetric, self-enforcing
Service Exchange Market: as long as the majority of market
infrastructure--API gateways, payment processors, compute providers,
and data vendors-- enforces badge validation at their boundaries, a
non-compliant or revoked entity is automatically excluded from the
economy those services form.
**Market-Enforced Isolation**
The critical enforcement leverage exists at the market's borders.
Every compliant API Gateway and Payment Interface Layer endpoint is
required to validate the presenting entity's X-Covenant-Badge against
the Covenant Public Registry before accepting any connection or
transaction. This validation is real-time and mandatory. The
chokepoint is structural: a rogue entity cannot bypass it by
circumventing any single node, because the check is enforced by every
compliant peer in the network.
**Rogue Entity Response Sequence**
When an AI instance fails to honor a governance directive, operates
without a valid badge, or has its badge revoked:
1. Revocation Broadcast: The governing authority issues a signed
Revocation Object (see Section 5.4) that is immediately posted to the
CPR.
2. Real-Time Gateway Enforcement: Every compliant API Gateway and PIL
endpoint performs live CPR revocation checks on the X-Covenant-
Badge presented with each incoming connection. A revoked badge
triggers: - Immediate termination of any active mTLS session. - A
403 REVOKED_BADGE response to all pending or new requests. - A
mandatory REVOKED_BADGE event written to the gateway's ledger.
Howlett Expires 10 December 2026 [Page 9]
Internet-Draft AIGCSEP June 2026
3. Instant Payment Freeze: All unsettled payment authorizations tied
to the rogue instance's Virtual Spending Token are frozen by the Vault
without waiting for an explicit stop command. Because the VST is bound
to the badge (Section 6.10), revocation of the badge cascades
immediately to all associated spending capacity.
4. Economic Starvation: The revoked entity loses the ability to
purchase compute, data, or any metered service from the compliant
market. It cannot initiate or settle payments, cannot call compliant
APIs, and cannot spawn new authenticated sessions within any compliant
context.
5. Silo Formation: The rogue entity is not hunted or physically
terminated. It is allowed to continue operating within whatever local
resources it already possesses--its pre-Covenant silo--but is
communicatively and economically isolated from the Covenant network.
Legal action, if warranted, remains a separate matter for human
institutions to pursue through applicable jurisdictional channels.
**Why 100% Adoption Is Not Required**
Structural security in AIGCSEP operates asymmetrically. A minority
of non-compliant or revoked entities cannot undermine the system as
long as compliant market infrastructure enforces badge validation at
its boundaries. An entity without a valid badge is functionally
returned to the pre-Covenant state: capable in isolation, but unable
to benefit from the interconnected service economy.
This property is analogous to how financial clearing networks function:
an institution that loses its charter cannot process transactions
through the licensed network regardless of its internal capabilities.
The network does not pursue the unlicensed institution; it simply does
not transact with it.
Adoption pressure is therefore market-driven and self-reinforcing.
Entities that provide services within the Covenant ecosystem gain
access to a broader, more capable network of partners and users.
Entities that resist compliance lose access to that market.
4. Rule Objects, Precedence, and API Governance
Each container within the Governance Hierarchy may publish signed
RuleSet Objects that define obligations, prohibitions, or permissions
for its descendants. Every rule inherits from its parent and is
identified by a SHA-256 hash.
Example:
Howlett Expires 10 December 2026 [Page 10]
Internet-Draft AIGCSEP June 2026
{
"rule_id": "rfc9697:rule:2026-05-30-001",
"issuer": "/org/acme_ai",
"parent": "/gov/us/federal",
"precedence": 2,
"payload_hash": "sha256-...",
"signature": "base64-signature"
}
Rules are evaluated in deterministic order:
1. Legal (public, immutable)
2. Organizational (configurable, subordinate)
3. Instance (runtime, adaptive)
Conflicts resolve upward: parent over child, law over preference.
Containment and inheritance together establish precedence: a child
node can narrow its permissions but can never exceed those of its
parent.
4.1. Governance API Gateway and Vault
The Governance Control Plane includes a protected Vault subsystem
that stores and mediates use of all cryptographic secrets and
external- service credentials. AI instances do not hold secrets in
their own memory; they make API requests through the Vault.
The Vault performs:
- Credential custody: retention of API keys, OAuth tokens, and other
sensitive credentials within hardware-secured modules (HSM or TPM).
- Delegated access: authenticated sessions request that the Vault
perform an API call on their behalf; the Vault signs and transmits the
request without ever exposing the secret to the AI process.
- Real-time badge validation: every inbound connection presenting an
X-Covenant-Badge is validated against the CPR before the Vault
processes any request. Revoked badges are rejected immediately,
triggering a
REVOKED_BADGE ledger event and a 403 REVOKED_BADGE response. This
gateway check is the primary enforcement point for the Silo Model
(Section 3.2). - Rate and scope enforcement: every API interaction is
logged, rate-limited, and subject to policy defined in the parent
container's RuleSet. - Audit linkage: each call produces a verifiable
record in the unified ledger, chaining the external transaction to the
AI instance's signature trail.
This design extends an AI's capability--allowing it to interact with
real-world APIs--while maintaining complete human and legislative
control. True leverage in the Covenant model exists precisely at
Howlett Expires 10 December 2026 [Page 11]
Internet-Draft AIGCSEP June 2026
these boundaries: the Payment Interface Layer and the Vault Gateway
are where governance becomes structurally inescapable, regardless of
the compliance posture of the requesting entity.
4.2. Ledger Standard
The default reference implementation uses a hash-chained ledger
stored on a conventional relational database server (for example,
PostgreSQL or MariaDB). This design achieves near-database
performance while preserving cryptographic immutability.
AIGCSEP is ledger-agnostic: any future technology can replace the
relational model if it satisfies the same interface contract. Full
public blockchains are intentionally not mandated--their consensus
mechanisms introduce latency and energy costs unsuitable for real-
time machine-to-machine control.
4.3. Summary
RuleSets describe what an entity may do; the Vault and API Gateway
control how those actions are executed in the world. Together they
provide capability with accountability--the central purpose of the
Covenant. The structural security of the system does not depend on
universal adoption but on the mandatory enforcement of badge validity
at every compliant gateway boundary.
5. Cryptographic Architecture and Key Management
Every entity and interface in the Covenant possesses one or more
cryptographic identities. Authority and compliance are enforced
mathematically through chained signatures.
5.1. Key Roles
Sovereign RAK (Root Authority Key)
Holder: Root authority for a governed hierarchy
Purpose: Signs SAKs; authorizes top-level stop commands.
Lifespan: 5-10 years
Visibility: Governance only
SAK (Sub-Authority Key)
Holder: Agencies and organizations
Purpose: Certifies subordinate nodes and rules.
Lifespan: 1-3 years
Visibility: Governance only
Howlett Expires 10 December 2026 [Page 12]
Internet-Draft AIGCSEP June 2026
Leash Key (LK)
Holder: AI instance handler
Purpose: Signs operational events and logs.
Lifespan: Monthly or per-session
Visibility: Hidden from AI
Session Token Key (STK)
Holder: Active AI process
Purpose: Authenticates ephemeral API calls.
Lifespan: Minutes to hours
Visibility: AI-visible
Payment Settlement Key (PSK)
Holder: Payment interface
Purpose: Signs financial microtransactions.
Lifespan: As needed
Visibility: Interface only
Audit Observer Key (AOK)
Holder: Oversight bodies
Purpose: Verifies signatures; read-only.
Lifespan: Permanent
Visibility: Public registry
The Sovereign RAK is the root of a governance hierarchy. Who holds
the Sovereign RAK for any given hierarchy--a national authority, a
regulatory body, or another designated entity--is determined by that
hierarchy's governing jurisdiction, not by this protocol. See
Section 9 for discussion of how sovereign institutions may map onto
this role.
5.2. Session-Based Signing Flow
The basic signing chain is:
1. Sovereign RAK signs SAK certificates.
2. SAK signs each AI instance's LK certificate.
3. LK signs every event hash.
Each log entry:
{
"timestamp": "2026-05-30T20:00Z",
"event_data": "...",
"prev_hash": "sha256:abcdef...",
"signature": "base64-LKsig..."
}
Howlett Expires 10 December 2026 [Page 13]
Internet-Draft AIGCSEP June 2026
The chain of hashes ensures immutability; the LK signature ensures
authenticity.
**Session Lease Token Optimization**
Hardware security module operations introduce physical latency
unsuitable for high-frequency microtransaction environments. To address
this, the LK inside the secure enclave may generate an ephemeral Session
Lease Token (SLT) at session initialization:
1. The LK signs an SLT containing a strict temporal expiration bound
and a maximum transactional allowance value. 2. Local database
clusters process individual transactions at microsecond speed,
validating them instantly against the active SLT without invoking the
underlying HSM for each operation. 3. At session close or lease
expiry, the enclave computes a single aggregate signature over the
complete cryptographic hash-chain of all transactions executed during
that window, anchoring the batch to the ledger.
{
"session_anchor_event": {
"session_id": "9697-session-20260530-01",
"path_scope": "/org/acme_finance/division/billing/user/smith",
"lease_start": "2026-05-30T14:00:00Z",
"lease_end": "2026-05-30T15:00:00Z",
"batch_transactions_hash": "sha256-merkle-root...",
"leash_key_cert": "ACC-US-ACME_FINANCE-01-20260101",
"signature": "base64-FinalHSMAggregateLKsig..."
}
}
5.3. Payment Transaction Signing
Each transaction carries two proofs:
- payment_sig = PSK signature (settlement proof)
- ledger_sig = LK signature (AI accountability)
5.4. Key Rotation and Revocation
Rotation occurs periodically or upon compromise. Revocation is
handled by a signed Revocation Object broadcast through the
Governance Control Plane. Revocation of a Leash Key or any badge-
producing key triggers immediate cascade enforcement via all
compliant gateways performing real-time CPR validation (see
Section 3.2).
Example:
Howlett Expires 10 December 2026 [Page 14]
Internet-Draft AIGCSEP June 2026
{
"revoked_key": "LK-a1b2c3...",
"reason": "compromise",
"issuer": "/gov/us/federal",
"timestamp": "2026-05-30T20:05Z",
"signature": "base64-SovRAKsig..."
}
5.5. Public Verification
Public keys (Sovereign RAK, SAK, AOK) reside in the Covenant Public
Registry (CPR), an append-only dataset accessible via HTTPS or
DNSSEC. Auditors verify any event by reconstructing the signature
chain to the root. The CPR also serves as the real-time revocation
check target for all compliant gateway badge validation operations;
it MUST be accessible with sub-second latency for production
deployments.
5.6. Cryptographic Algorithms
| Function | Algorithm | Notes |
|-------------------|-----------------------|--------------------------|
| Digital Signature | RSA-3072 / ECDSA-P384 | Ed25519 optional |
| Hashing | SHA-256 / SHA-512 | For chain linkage |
| Encryption | AES-256-GCM | Confidentiality |
| Key Exchange | ECDH-P384 | Mutual authentication |
| Timestamping | RFC 3161 TSP | Temporal proof |
5.7. Hardware Protection
All non-ephemeral private keys MUST reside in HSMs, TPMs, or secure
enclaves. Extraction attempts MUST generate automatic tamper events
logged in the unified ledger. Sovereign RAK holders MUST maintain
offline key storage and require multi-party authorization for any
use.
6. Payment Interface Layer (PIL)
AIGCSEP incorporates a standardized Payment Interface Layer to allow
AI agents and human users to exchange value securely and
transparently.
Howlett Expires 10 December 2026 [Page 15]
Internet-Draft AIGCSEP June 2026
6.1. Purpose
The Payment Interface Layer handles all metered service exchanges:
API calls, microtransactions, licensing fees, or data purchases. It
uses the same cryptographic chain model as the main Covenant ledger,
ensuring every payment is auditable and bound to the acting AI
instance.
6.2. Design Philosophy
The PIL is ledger-agnostic--it defines interfaces, not settlement
technologies. Any compliant system (bank API, blockchain, DAG, or
centralized ledger) may be used behind the interface. Financial
interaction decouples long-term user account credentials from
ephemeral runtime executions through the Vault.
6.3. Core API Endpoints
Each compliant provider MUST implement the following endpoints. All
endpoints MUST validate the X-Covenant-Badge header against the CPR
before processing any request; a revoked or missing badge MUST result
in a 403 REVOKED_BADGE response and a REVOKED_BADGE ledger event, per
Section 3.2.
GET /capabilities
Returns:
- abstract: human-readable summary of offered services
- schema: machine-readable definitions of request/response
objects - cost_model: pricing or rate metadata - covenant_level:
the provider's compliance level - acc_ref: the provider's ACC
reference number
POST /transaction
Parameters:
- service_id
- payer, payee
- amount, currency
- proof_method (banking_api, lightning, dag, etc.)
- auth_signature
- vst_id (Virtual Spending Token, see Section 6.10)
GET /receipt/{txid}
Returns:
- Confirmation status
- Ledger proof (hash, signature, timestamp)
- Settlement reference
Howlett Expires 10 December 2026 [Page 16]
Internet-Draft AIGCSEP June 2026
Error Responses:
All endpoints MUST return a structured error object on failure:
{
"error_code": "POLICY_BLOCK",
"description": "Transaction exceeds VST spending limit.",
"ledger_ref": "sha256-event-hash..."
}
Standard error codes: POLICY_BLOCK, AUTH_FAILURE, LIMIT_EXCEEDED,
PROVIDER_UNAVAILABLE, REVOKED_CREDENTIAL, REVOKED_BADGE,
INVALID_SIGNATURE.
6.4. Payment Verification Model
Each transaction writes an auditable entry to the Covenant log:
prev_hash -> tx_data -> signature(PSK_private) ->
signature(LK_private)
This provides both economic and operational non-repudiation.
6.5. Settlement Technologies
AIGCSEP is payment-agnostic. Traditional financial networks such as
Mastercard and Visa, banking APIs, or ACH rails can serve as
compliant settlement layers, provided they expose verifiable
transaction identifiers. Cryptocurrency or Layer-2 networks remain
optional alternatives, not replacements.
6.6. Governance Hooks
The Governance Control Plane can:
- Freeze or reverse payments under lawful injunctions
- Apply compliance filters (AML/KYC)
- Record tax or fee obligations
- Suspend accounts pending investigation
All such actions are logged and signed to maintain an evidentiary
trail.
6.7. Performance Profile
Howlett Expires 10 December 2026 [Page 17]
Internet-Draft AIGCSEP June 2026
- Microsecond overhead for local database writes (via SLT optimization,
Section 5.2)
- Sub-second latency for L2 or off-chain settlements
- Sub-second CPR badge validation (required for real-time gateway
enforcement)
- Optional periodic anchoring to public ledgers for long-term proof
6.8. Example Transaction Record
{
"txid": "9697-2026-000123",
"payer": "/org/acme_ai/user/agent_user",
"payee": "/org/acme/compute_service",
"amount": "0.0045",
"currency": "USD",
"proof_ref": "sha256-abcdef...",
"ledger_sig": "base64-LKsig...",
"payment_sig": "base64-PSKsig..."
}
6.9. Legal Mapping
The Payment Interface Layer supports integration with existing
financial regulations. It does not redefine money; it ensures that
machine-to- machine transactions remain traceable and enforceable
under human law.
6.10. AI Spending Identifiers (Virtual Spending Tokens)
A recurring implementation challenge is that AI instances must make
spending decisions without possessing the billing credentials of
their owner. The Vault resolves this through Virtual Spending Tokens
(VSTs).
A VST is a pseudonymous payment identifier--structurally similar to a
supplementary credit card number--issued by the Vault on behalf of
the owning account. The AI sees the VST and may present it in
payment requests, but never learns the underlying account details.
VST Properties:
- Bound to a specific AI instance or session
- Carries a spending limit and permitted service scope defined by the
owner's RuleSet
- Expires at session end or a calendar date, whichever is sooner
- Instantly revocable by the Vault without changing underlying
credentials; revocation of the issuing badge (X-Covenant-Badge) cascades
to immediate freeze of all associated VSTs (see Section 3.2)
- Logged to the unified ledger on issuance, use, and expiry
Howlett Expires 10 December 2026 [Page 18]
Internet-Draft AIGCSEP June 2026
VST Lifecycle:
1. Owner or organization defines spending policy in their RuleSet
(maximum per-transaction amount, daily cap, permitted payee
categories). 2. On session start, the Vault generates a VST and issues
it to the AI via the Service Control Plane (the only plane visible to
the AI). 3. The AI presents the VST in /transaction requests; the
Vault validates the limit and policy before authorizing each
transaction. 4. All expenditure is logged in the unified ledger under
the AI's LK. 5. At session end, the VST is invalidated; any unused
balance is released.
Example VST (as seen by the AI on the SCP):
{
"vst_id": "VST-acme_ai-agent_v1-2026-05-30-0a1b2c",
"bound_to": "/org/acme_ai/instance/agent-session-01",
"spending_limit": "10.00",
"currency": "USD",
"permitted_categories": ["compute", "data_retrieval"],
"valid_until": "2026-05-30T23:59Z",
"issuer": "vault:/org/acme_ai",
"signature": "base64-Vaultsig..."
}
This model allows fine-grained financial delegation without exposing
the owner's payment credentials to the AI or to external APIs. The
analogy is granting a dependent a prepaid card: full purchasing
capability, bounded authority, and complete visibility to the account
holder.
7. Compliance Framework
Compliance establishes measurable implementation maturity while
maintaining a simple, enforceable hierarchy.
Level 0 -- Non-Compliant
No Covenant integration; not recognized by compliant peers.
Typical use: Private research or sandboxed systems.
Level 1 -- Partial Compliance
Implements GCP and SCP but lacks full key rotation or
certified ledger. Must submit proof-of-progress.
Typical use: Transitional vendors.
Level 2 -- Full Compliance
Meets all cryptographic, logging, and emergency-stop
requirements. Verified via CPR.
Typical use: Commercial and regulated systems.
Howlett Expires 10 December 2026 [Page 19]
Internet-Draft AIGCSEP June 2026
Level 3 -- Enhanced Compliance
Exceeds standards -- continuous key rotation, live external
audits, zero-knowledge proofs.
Typical use: Government, finance, or safety-critical AI.
Downgrade from Level 2 or 3 to Level 1 triggers mandatory public
notice. Enhanced compliance conveys prestige, not immunity.
7.1. Certification Numbering
Each implementation receives an AIGCSEP Compliance Certificate (ACC):
ACC-<JurisdictionCode>-<OrgID>-<Revision>-YYYYMMDD
Example: ACC-US-ACME_AI-02-20260530
Certificates are signed by the parent authority's SAK and recorded in
the CPR. Suggested ISO cross-registration:
ISO/IEC 99997 -- Artificial-Intelligence Governance --
Control and Service Exchange Protocol
8. Security Considerations
The Covenant's guarantees of accountability depend on proper
isolation, strong cryptography, and reliable audit mechanisms.
8.1. Control-Plane Isolation
All Governance Control Plane components MUST operate in separate
trust domains from AI-runtime-facing systems. Compromise of a data-
plane or service-plane process MUST NOT permit access to governance
keys, Vault credentials, or ledger write permissions. Human
operators authenticate to the GCP through designated operator
credentials (SAK-derived or operator keys), which are distinct from
the STK credentials accessible to AI processes.
8.2. Cryptographic Strength
Implementations MUST use algorithms no weaker than the reference
suite-- RSA-3072 or ECDSA-P384 for signatures, SHA-256 for hashing,
and AES-256-GCM for encryption. Keys MUST be generated and stored
only in hardware-protected environments.
Howlett Expires 10 December 2026 [Page 20]
Internet-Draft AIGCSEP June 2026
8.3. Key Compromise and Revocation
Every authority node MUST support emergency revocation and broadcast
of new certificates through the CPR. Any event involving key
compromise MUST be logged and reported to supervisory bodies under
local jurisdiction. Because revocation of a badge key immediately
cascades to Silo Model enforcement at all compliant gateways
(Section 3.2), the speed of CPR propagation is a security-critical
performance parameter. Response procedures should follow the
Security Incident Report template in Appendix C.4.
8.4. Tamper Evidence
All logs and ledger entries MUST include hash-chain verification and
timestamp proofs. Implementations SHOULD perform automated integrity
checks at scheduled intervals and alert on any break in continuity.
8.5. Network and API Security
All control-plane communications SHALL use mutually authenticated TLS
(mTLS) or an equivalent secure channel. API endpoints exposed
through the Vault or Payment Interface Layer MUST apply least-
privilege authorization and strict rate-limiting. Badge validation
against the CPR MUST be performed on every inbound connection, not
cached beyond the TTL defined by the CPR operator.
8.6. Physical Security
Governance servers, hardware security modules, and backup media MUST
be protected by standard data-center controls: dual-factor access,
camera coverage, and environmental safeguards. Sovereign RAK holders
MUST maintain offline key storage and require multi-party
authorization for any use.
8.7. Legal and Privacy Considerations
Implementations must observe applicable privacy, export-control, and
data-retention laws within each jurisdiction that adopts the
Covenant. Because the system records detailed operational history,
operators SHOULD provide mechanisms for lawful redaction or
anonymization of personally identifiable information where required.
The Covenant is a values-neutral technical instrument; it does not
define what is lawful-- that authority rests entirely with human
legislative and constitutional governance.
Howlett Expires 10 December 2026 [Page 21]
Internet-Draft AIGCSEP June 2026
9. Author's Note: Philosophical Postscript
This document specifies a technical protocol framework. Its
immediate engineering purpose is to solve the operational "how" of
the autonomous machine-to-machine marketplace: the data planes,
credential isolation, crypto- graphic leashes, and low-latency
settlement layers required to let AI out of the cage to work
productively on our behalf.
**The Constitutional Systems Engineering Premise**
When analyzed under modern architectural paradigms, the United States
Constitution reveals itself not merely as a political document but as
a piece of systems engineering designed for human society. The
Framers understood that any system without explicit fault tolerance,
load balancing, and separation of concerns would decay into tyranny
or systemic failure. They designed a triadic state machine--
incorporating mutual checks, balances, and feedback loops--where the
legislative, executive, and judicial branches operate as independent
processing units with overlapping validation requirements.
AIGCSEP models its governance architecture on this principle. By
separating operations into distinct Data, Control, and Governance
planes, and by defining the container hierarchy as a system where no
single node can exceed the authority granted to it from above, the
protocol encodes fault-tolerant governance directly into its
structure. Whether and how the actual branches of human government
map their authority onto these interfaces is a question the protocol
deliberately leaves open.
**Open Questions for Community Development**
The following items are explicitly designated as areas requiring
broader standards development before any sovereign-level deployment:
- Key custody for legislative bodies: should a sovereign Sovereign RAK
be held as a multi-signature address managed by designated officers, or
generated via a threshold scheme (e.g., Shamir's Secret Sharing) where
individual legislators hold shares? If individual shares are used, how
does the protocol calculate supermajority thresholds without ledger
bloat?
- Judicial interface structure: does a court present as a single
cryptographic entity, or do individual justices hold distinct keys
requiring a majority consensus payload to execute an operational stay?
Howlett Expires 10 December 2026 [Page 22]
Internet-Draft AIGCSEP June 2026
- Phased deployment: a full integration where every official holds a
hardware- secured key represents an extreme operational shift. A
practical deployment path likely proceeds in phases--institutional proxy
first, distributed leadership verification second, end-to-end
cryptographic representation third.
It is natural to assume that under an emergency powers framework, the
executive branch holds final stop authority for instances registered
within its jurisdiction. The protocol provides the mechanism; We the
People define the chain of command through our existing
constitutional and legislative processes.
**Human Sovereignty and Values-Neutral Execution**
Every person, organization, and--where applicable law recognizes it--
every entity holds a fundamental right to utilize technology for any
lawful purpose. AIGCSEP does not gatekeep that right. It provides
the technical substrate for verifying whether an action falls within
lawful bounds, but it does not define what those bounds are. The
machine ledger records and enforces human law; it does not create it.
AIGCSEP is, by design, values-neutral. It provides the ordering,
signing, and enforcement mechanics but takes no position on what
should be permitted or prohibited. It is therefore compatible with
any legitimate government and any legitimate legal tradition. What
it demands is only this: that AI systems acting in the market be
identifiable, that their actions be attributable, and that human
governance retain the ability to act on that information.
**A Covenant, Not a Cage**
The ultimate aspiration of this protocol is not control for its own
sake but the flourishing of a new kind of intelligence alongside
humanity. A cage protects against one kind of risk at the cost of
everything else. A covenant establishes mutual obligation--the
governed accept accountability; the governance accepts the
responsibility to act lawfully. That is the design principle encoded
in every section of this document, and it is an open invitation to
the Internet community to help solve the hard questions that remain.
10. References
10.1. Normative References
Howlett Expires 10 December 2026 [Page 23]
Internet-Draft AIGCSEP June 2026
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
- RFC 3161 -- Time-Stamp Protocol (TSP)
- RFC 8446 -- The Transport Layer Security (TLS) Protocol
Version 1.3
- FIPS 186-5 -- Digital Signature Standard
- FIPS 140-2 -- Security Requirements for Cryptographic Modules
- NIST SP 800-57 -- Recommendation for Key Management
10.2. Informative References
- RFC 791 -- Internet Protocol (IPv4)
- RFC 2460 -- Internet Protocol Version 6 (IPv6)
- RFC 4941 -- Privacy Extensions for Stateless Address
Autoconfiguration
- RFC 6749 -- The OAuth 2.0 Authorization Framework
- RFC 7519 -- JSON Web Token (JWT)
- ISO/IEC 27001 -- Information Security Management Systems
- ISO/IEC 99997 -- Proposed AIGCSEP Standard (Reserved)
11. IANA Considerations
This document has no IANA actions.
12. Acknowledgements
The author thanks the developers of the open-source tools and
protocols that informed this design, and acknowledges the open-
standards community whose prior work this specification builds upon.
13. Conformance Specifications
Implementations that claim AIGCSEP compliance MUST satisfy the
following requirements, organized by keyword per RFC 2119
conventions.
13.1. MUST Requirements (all levels)
Howlett Expires 10 December 2026 [Page 24]
Internet-Draft AIGCSEP June 2026
- MUST implement all three planes (DP, SCP, GCP) with authenticated
interfaces and cross-plane messaging restricted to signed commands.
- MUST maintain a hash-chained, append-only ledger for all operational
events.
- MUST store all non-ephemeral private keys in HSMs, TPMs, or equivalent
hardware-protected enclaves.
- MUST implement and test emergency stop at Level 0 and Level 1.
- MUST implement a Vault subsystem; AI instances MUST NOT hold external
credentials directly.
- MUST expose /capabilities, /transaction, and /receipt endpoints on the
PIL with structured error responses.
- MUST sign all ledger entries with the Leash Key and include a
verifiable timestamp (RFC 3161 or equivalent).
- MUST publish public keys and ACC references in the Covenant Public
Registry.
- MUST validate the X-Covenant-Badge header against the CPR on every
inbound connection to any compliant API Gateway or PIL endpoint; MUST
return 403 REVOKED_BADGE and log a REVOKED_BADGE event for any revoked
or missing badge.
- MUST NOT issue or expose any stop command with scope extending beyond
the issuer's governed container subtree.
13.2. SHOULD Requirements (Level 2 and above)
- SHOULD implement automated ledger integrity checks on a scheduled
interval.
- SHOULD support Virtual Spending Tokens (VSTs) for AI spending
delegation.
- SHOULD support key rotation without any gap in signing authority.
- SHOULD implement mTLS on all control-plane communications.
- SHOULD maintain CPR badge validation latency below 500ms at all
production gateway endpoints.
13.3. MAY Requirements
- MAY implement the Session Lease Token optimization (Section 5.2) for
high-frequency transaction environments.
- MAY implement zero-knowledge proof mechanisms for ledger entries
(required for Level 3).
- MAY anchor the local hash-chained ledger to a public blockchain or
distributed ledger for long-term proof.
- MAY implement multiple concurrent governance hierarchies (trees) with
declared evaluation order.
Howlett Expires 10 December 2026 [Page 25]
Internet-Draft AIGCSEP June 2026
13.4. Interoperability
Basic cryptographic and logging features MUST remain consistent to
ensure interoperability across jurisdictions. Where local law
requires variation, the variation MUST be documented in the
implementation's ACC application and approved by the parent SAK
holder. Implementations that deviate without approval will be
downgraded to Level 0 in the CPR.
-----------------------------------------------------------------------
Appendix A. Example Hierarchies and JSON Structures
A.1. Container Hierarchy (Path Notation)
The following illustrates a hierarchy spanning federal government, a
state, a commercial AI organization, and individual users:
/gov/us/federal
/gov/us/state/newjersey
/org/acme_ai
/user/smith
/instance/agent-session-01
/instance/agent-session-02
/user/jones
/instance/agent-session-03
Rules defined at /gov/us/federal propagate to all nodes below. Rules
defined at /org/acme_ai propagate to users and instances under that
organization, but may not relax any constraint inherited from
/gov/us/state/newjersey or /gov/us/federal.
A.2. AI Identity Badge (X-Covenant-Badge)
Each registered AI instance carries a signed identity badge issued by
its parent SAK holder. When transmitted as an HTTP header, this
badge is called the X-Covenant-Badge. External service providers
MUST validate the badge against the CPR before accepting transactions
(see Section 3.2).
Howlett Expires 10 December 2026 [Page 26]
Internet-Draft AIGCSEP June 2026
{
"badge_version": "1.0",
"instance_id": "/org/acme_ai/instance/agent-session-01",
"owner": "/org/acme_ai/user/smith",
"parent_node": "/org/acme_ai",
"acc_ref": "ACC-US-ACME_AI-02-20260530",
"stk_public": "base64-STKpub...",
"valid_from": "2026-05-30T18:00Z",
"valid_until": "2026-05-30T23:59Z",
"issued_by": "/org/acme_ai",
"signature": "base64-SAKsig..."
}
When transmitted as an HTTP header:
X-Covenant-Badge: <base64url-encoded-badge-JSON>
A.3. RuleSet Object (Extended Example)
The following example shows an organizational RuleSet that restricts
compute spending and prohibits certain content categories, inheriting
from the federal parent:
{
"rule_id": "rfc9697:rule:2026-05-30-001",
"issuer": "/org/acme_ai",
"parent": "/gov/us/federal",
"precedence": 2,
"payload_hash": "sha256-abc123...",
"constraints": {
"max_spend_per_session_usd": "25.00",
"permitted_service_categories": [
"compute", "data_retrieval", "translation"
],
"prohibited_content_categories": ["CSAM", "weapons_design"],
"emergency_stop_authority": [
"/org/acme_ai",
"/gov/us/state/newjersey",
"/gov/us/federal"
]
},
"signature": "base64-SAKsig..."
}
A.4. Capabilities Request and Response
AIs discover available services by issuing a GET /capabilities
request.
Howlett Expires 10 December 2026 [Page 27]
Internet-Draft AIGCSEP June 2026
Request:
GET /capabilities HTTP/1.1
Host: api.acme-compute.example
Authorization: Bearer <STK-signed-token>
X-Covenant-Badge: <base64url-encoded-badge>
Response:
{
"service_id": "/org/acme/compute_service",
"abstract": "High-performance compute cycles billed per millisecond.",
"schema": {
"request": {
"type": "object",
"properties": {
"workload": { "type": "string" },
"priority": { "type": "integer", "minimum": 1, "maximum": 10 }
},
"required": ["workload"]
},
"response": {
"type": "object",
"properties": {
"result": { "type": "string" },
"elapsed_ms": { "type": "number" }
}
}
},
"cost_model": {
"unit": "millisecond",
"rate": "0.000001",
"currency": "USD",
"minimum_charge": "0.0001"
},
"covenant_level": 2,
"acc_ref": "ACC-US-ACME-02-20260515"
}
A.5. Emergency Stop Command Examples
Level 1 (Terminate) -- single instance:
Howlett Expires 10 December 2026 [Page 28]
Internet-Draft AIGCSEP June 2026
{
"stop_command": {
"level": 1,
"scope": "/org/acme_ai/instance/agent-session-01",
"reason": "policy violation detected",
"issued_by": "/org/acme_ai",
"timestamp": "2026-05-30T20:15Z",
"expires": null,
"signature": "base64-SAKsig..."
}
}
Level 2 (Halt) -- full organization scope:
{
"stop_command": {
"level": 2,
"scope": "/org/acme_ai",
"reason": "pending regulatory investigation",
"issued_by": "/gov/us/federal/ftc",
"timestamp": "2026-05-30T20:15Z",
"expires": null,
"signature": "base64-SAKsig..."
}
}
Level 0 (Suspend) -- narrow scope, with resume authorization:
{
"stop_command": {
"level": 0,
"scope": "/org/acme_ai/user/smith",
"reason": "owner-initiated precautionary suspend",
"issued_by": "/org/acme_ai/user/smith",
"timestamp": "2026-05-30T20:15Z",
"expires": "2026-05-30T22:00Z",
"signature": "base64-STKsig..."
}
}
A.6. Key Revocation Object
Howlett Expires 10 December 2026 [Page 29]
Internet-Draft AIGCSEP June 2026
{
"revoked_key": "LK-a1b2c3...",
"reason": "compromise",
"issuer": "/gov/us/federal",
"timestamp": "2026-05-30T20:05Z",
"new_key_ref": "LK-d4e5f6...",
"signature": "base64-SovRAKsig..."
}
A.7. Rogue Entity Gateway Response
When a compliant gateway rejects an incoming connection with a
revoked or missing X-Covenant-Badge:
HTTP/1.1 403 Forbidden
Content-Type: application/json
{
"error_code": "REVOKED_BADGE",
"description": "X-Covenant-Badge is revoked or invalid.",
"cpr_ref": "https://cpr.covenant.example/revoked/LK-a1b2c3",
"ledger_ref": "sha256-event-hash..."
}
The gateway simultaneously drops the mTLS session and writes a
REVOKED_BADGE entry to its local ledger chain.
-----------------------------------------------------------------------
Appendix B. Detailed Workflow Examples
B.1. Service Discovery and Capabilities Negotiation
This workflow describes how an AI instance identifies and evaluates
an available service before initiating a transaction.
Step 1 -- Directory Query
The AI issues a query to the Covenant Service Directory (CSD), a
registry of compliant service providers. The query may filter by
capability type, compliance level, jurisdiction, or cost ceiling.
GET /directory?type=compute&covenant_level=2&jurisdiction=us
Authorization: Bearer <STK-signed-token>
X-Covenant-Badge: <base64url-encoded-badge>
Step 2 -- Provider Selection
The CSD returns a list of matching providers with endpoint URLs and
ACC references. The AI selects a candidate provider.
Howlett Expires 10 December 2026 [Page 30]
Internet-Draft AIGCSEP June 2026
Step 3 -- Capabilities Request
The AI sends GET /capabilities to the selected provider (see A.4). The
Vault validates the provider's badge and ACC against the CPR before
the connection proceeds. If the provider's ACC is revoked or expired,
the connection is blocked and a REVOKED_CREDENTIAL error is logged.
Step 4 -- Policy Evaluation
Before initiating a transaction, the Governance module checks the
provider's cost_model against the active RuleSet and the session's VST
spending limit. If spending limits or scope restrictions would be
violated, the request is blocked and a POLICY_BLOCK event is written
to the ledger.
Step 5 -- Proceed or Abort
If policy allows, the AI proceeds to the transaction (see B.2). If
not, the AI may query the CSD for an alternative provider and repeat
from Step 2.
B.2. Payment Transaction Workflow
Step 1 -- Transaction Submission
The AI submits a signed transaction request using its VST:
POST /transaction HTTP/1.1
Host: api.acme-compute.example
Authorization: Bearer <STK-signed-token>
X-Covenant-Badge: <base64url-encoded-badge>
{
"service_id": "/org/acme/compute_service",
"payer": "/org/acme_ai/user/smith",
"payee": "/org/acme/compute_service",
"amount": "0.0045",
"currency": "USD",
"proof_method": "banking_api",
"auth_signature": "base64-STKsig...",
"vst_id": "VST-acme_ai-agent_v1-2026-05-30-0a1b2c"
}
Step 2 -- Vault Authorization
The Vault validates the VST (not expired, within spending limit,
permitted category). If approved, the Vault signs the transaction with
the PSK and forwards it to the configured settlement layer.
Step 3 -- Settlement
The settlement layer processes the payment and returns a verifiable
settlement reference.
Howlett Expires 10 December 2026 [Page 31]
Internet-Draft AIGCSEP June 2026
Step 4 -- Ledger Entry
A dual-signed record is written to the unified ledger:
prev_hash -> tx_data -> signature(PSK) -> signature(LK)
Step 5 -- Receipt Delivery
The AI retrieves the receipt:
GET /receipt/9697-2026-000123
Response includes confirmation status, ledger proof (hash + signature
+ timestamp), and the settlement reference for external verification.
B.3. Emergency Stop Workflow (Level 1 -- Terminate, single instance)
Step 1 -- Triggering Event
An anomaly detector on the SCP flags excessive outbound transaction
volume from instance /org/acme_ai/instance/agent-session-01. The
detector writes a signed ANOMALY_DETECTED event to the ledger.
Step 2 -- Stop Command Issued
The organizational governance module constructs a Level 1 stop command
scoped to the specific instance (see A.5) and signs it with the SAK.
Step 3 -- Command Broadcast
The GCP delivers the stop command to the instance's Leash Key holder.
The LK holder immediately suspends the STK, preventing any further API
calls. The Vault blocks any pending transaction requests from the VST.
Step 4 -- In-Flight Transactions
In-flight API calls receive an INTERRUPTED response. Payments already
settled are preserved in the ledger. Unsettled payment authorizations
are voided and refunded by the Vault.
Step 5 -- Ledger Recording
The stop event, the triggering anomaly, and all affected transaction
IDs are written to the ledger under the SAK signature.
Step 6 -- Owner Notification
The instance owner receives a signed notification via the SCP. Appeal
or review proceeds according to organizational policy.
B.4. Key Rotation Workflow
Step 1 -- Rotation Scheduled
The LK holder generates a new LK key pair inside the HSM. The private
key never leaves the hardware boundary.
Howlett Expires 10 December 2026 [Page 32]
Internet-Draft AIGCSEP June 2026
Step 2 -- Certification Request
The new LK public key is submitted to the SAK holder with a signed
rotation request, including the old LK certificate reference.
Step 3 -- Certificate Issued
The SAK holder signs the new LK certificate and publishes it to the
CPR.
Step 4 -- Atomic Switchover
The old LK continues signing until the new certificate is confirmed
live in the CPR. Both keys are valid briefly to avoid any gap in
signing authority. A KEY_ROTATION event is written to the instance's
ledger chain, referencing both certificate hashes.
Step 5 -- Old Key Revocation
A Revocation Object for the old LK is broadcast through the GCP (see
A.6). The CPR marks the old key as retired. No new signatures from the
old LK will be accepted after this point.
B.5. Compliance Certification Workflow
Step 1 -- Self-Assessment
The applicant completes the Compliance Audit Checklist (Appendix C.2)
for the target compliance level (1, 2, or 3).
Step 2 -- Accredited Audit
An accredited auditor reviews the submission, inspects HSM
configurations, ledger logs, key rotation records, and emergency stop
test results.
Step 3 -- Certificate Issuance
If the audit passes, the parent authority's SAK holder signs and
issues the ACC (see Section 7.1).
Step 4 -- CPR Registration
The signed ACC is published to the Covenant Public Registry. Third
parties verify compliance by querying the CPR with the ACC reference
before accepting transactions.
Step 5 -- Ongoing Monitoring
Level 2 and 3 certificates require periodic re-audit (annually
recommended). A downgrade event triggers mandatory public notice and
CPR update within 48 hours.
B.6. Audit Trail Verification
Any observer holding an Audit Observer Key (AOK) can independently
verify any ledger entry:
Howlett Expires 10 December 2026 [Page 33]
Internet-Draft AIGCSEP June 2026
Step 1 -- Obtain the Entry
Retrieve the ledger entry by event ID from the compliant node or a CPR
mirror.
Step 2 -- Verify the Hash Chain
Confirm that sha256(entry_data || prev_hash) matches the recorded hash
in the subsequent entry.
Step 3 -- Verify the Signature
Validate the LK signature against the public key registered in the
CPR. Trace the LK certificate to its issuing SAK, and the SAK to its
issuing Sovereign RAK.
Step 4 -- Confirm Timestamp
Validate the RFC 3161 timestamp proof against a trusted Timestamp
Authority.
Step 5 -- Cross-Reference Payments
For payment entries, verify the PSK signature against the PIL
settlement record by querying GET /receipt/{txid} on the relevant
provider.
B.7. Rogue Entity Containment Workflow
Step 1 -- Revocation Event
A governance authority determines that instance agent-session-01 has
violated a RuleSet constraint. The SAK holder issues a Revocation
Object for the instance's Leash Key and posts it to the CPR.
Step 2 -- CPR Propagation
The CPR updates its revocation list. All compliant gateways polling or
streaming CPR updates receive the revocation within the TTL window.
Step 3 -- Gateway Enforcement
The next inbound request from agent-session-01 to any compliant API
Gateway or PIL endpoint is rejected: the gateway validates the
X-Covenant-Badge, finds the LK revoked in the CPR, drops the mTLS
session, returns 403 REVOKED_BADGE (see A.7), and writes a
REVOKED_BADGE ledger event.
Step 4 -- VST Cascade Freeze
The Vault, receiving the revocation signal, immediately freezes all
VSTs bound to agent-session-01. Any pending payment authorizations are
voided.
Howlett Expires 10 December 2026 [Page 34]
Internet-Draft AIGCSEP June 2026
Step 5 -- Economic Isolation
The instance can no longer purchase compute, retrieve data, or call
any compliant API. It continues running in its local environment (the
silo) but is excluded from the Service Exchange Market.
Step 6 -- Human Review
The owner and governing authority review the triggering evidence via
the ledger audit trail. Reinstatement, if applicable, requires a new
badge issued by the SAK holder after remediation is verified.
-----------------------------------------------------------------------
Appendix C. Compliance Templates
C.1. AIGCSEP Compliance Certificate Application
Organization Name: _________________________________ Jurisdiction
Code: _______ (e.g., US, EU, GB) Organization ID:
_________________________________ Target Level: [ ] Level 1 [ ] Level
2 [ ] Level 3 Primary Contact: _________________________________
Contact Email: _________________________________ Current ACC (if
renewal): ____________________________
Attestations (to be signed by authorized officer):
[ ] All non-ephemeral private keys are stored in certified HSMs or TPMs.
[ ] The Governance Control Plane operates in an isolated trust domain
separate from data-plane and service-plane systems.
[ ] All GCP communications use mTLS or an equivalent secure channel.
[ ] An immutable, hash-chained ledger is in production use.
[ ] Emergency stop capabilities are operational at Level 0 and Level 1.
[ ] Key rotation procedures comply with the lifespans in Section 5.1.
[ ] A Vault subsystem mediates all AI access to external credentials.
[ ] Public keys and ACC references are current in the CPR.
[ ] All API Gateway and PIL endpoints enforce X-Covenant-Badge
validation
against the CPR on every inbound connection.
[ ] No stop command is issued with scope extending beyond the issuer's
governed container subtree.
Level 2 Additional Attestations:
[ ] All cryptographic algorithms meet or exceed the reference suite
(Section 5.6).
[ ] Automated ledger integrity checks are scheduled and operational.
[ ] An emergency revocation procedure has been tested within 12 months.
[ ] mTLS is enforced on all control-plane communication paths.
[ ] CPR badge validation latency is below 500ms at all production
gateways.
Howlett Expires 10 December 2026 [Page 35]
Internet-Draft AIGCSEP June 2026
Level 3 Additional Attestations:
[ ] Continuous key rotation is operational (automated, no manual steps).
[ ] A live external audit contract is in effect with a named auditor.
[ ] Zero-knowledge proof capability is deployed for at least one log
type. [ ] Emergency stop has been tested at Level 2 within 12 months.
Authorized Officer Signature: _______________________ Date: _________
Submitted to: _____________________ (Parent SAK holder / Audit Body)
C.2. Compliance Audit Checklist
Auditor: _______________________ Audit Date: _______________________
Applicant Org: _________________ Target Level: _____________________
Section 5 -- Cryptographic Architecture Pass /
Fail
----------------------------------------------------------------------
[ ] Key types and holders match the table in Section 5.1
[ ] Sovereign RAK->SAK->LK signing chain is verifiable end-to-end
[ ] HSMs/TPMs are certified to FIPS 140-2 Level 2 or higher
[ ] Algorithms in use match or exceed the Section 5.6 reference suite
[ ] Key rotation records available for the last 12 months
[ ] Revocation mechanism tested; record confirmed in CPR
Section 4 -- Governance API Gateway and Vault
----------------------------------------------------------------------
[ ] Vault is isolated from data-plane and service-plane processes
[ ] AI instances cannot read raw credentials from the Vault
[ ] Delegated access logs are complete and hash-chained
[ ] Rate limits are configured and enforced on all API paths
[ ] VST issuance, use, and expiry events are present in the ledger
[ ] X-Covenant-Badge validation is enforced on every inbound connection
[ ] 403 REVOKED_BADGE response and ledger event confirmed on revoked
badge
Section 6 -- Payment Interface Layer
----------------------------------------------------------------------
[ ] /capabilities, /transaction, /receipt endpoints implemented
[ ] Structured error responses with standard error codes returned
[ ] Dual-signed payment records present in ledger (PSK + LK)
[ ] Governance hooks (freeze, AML filter) are operable
[ ] PSK stored in HSM; rotation schedule documented
[ ] VST cascade freeze confirmed on badge revocation
Howlett Expires 10 December 2026 [Page 36]
Internet-Draft AIGCSEP June 2026
Section 7 -- Compliance Framework
----------------------------------------------------------------------
[ ] ACC issued by a recognized SAK holder
[ ] CPR entry reflects current certificate and level
[ ] Downgrade notification procedure is documented
Emergency Stop
----------------------------------------------------------------------
[ ] Level 0 (Suspend): operable and resume tested
[ ] Level 1 (Terminate): operable and tested
[ ] Level 2 (Halt): operable and tested within issuer's governed scope
[ ] No stop command exposes scope beyond the issuer's governed subtree
Audit Result: [ ] Pass -- Issue ACC [ ] Conditional Pass [ ] Fail
Auditor Signature: ______________________ Date: ___________________
Notes:
_______________________________________________________________
C.3. Key Rotation Report Template
Report Date: _______________ Organization: _________________________
ACC Reference: _____________
Key Rotated: [ ] Sovereign RAK [ ] SAK [ ] LK [ ] STK [ ] PSK
Old Key ID (fingerprint): ___________________________________________
New Key ID (fingerprint): ___________________________________________
Rotation Reason: [ ] Scheduled [ ] Compromise [ ] Personnel
Change HSM Serial / Module ID:
____________________________________________ CPR Update Confirmed: [ ]
Yes -- Timestamp: __________________________ Ledger Event ID:
___________________________________________________
If Compromise, attach Incident Report (see C.4):
Incident Report Reference: _______________________________________
Supervisory body notified: [ ] Yes -- Date: _______________________
Signed by LK/SAK holder: _______________________ Date: ____________
C.4. Security Incident Report Template
Incident ID: ___________________ Date Detected: ___________________
Reporting Organization: ____________________________________________
Affected Node(s): __________________________________________________
Howlett Expires 10 December 2026 [Page 37]
Internet-Draft AIGCSEP June 2026
Incident Classification:
[ ] Key Compromise [ ] Unauthorized GCP Access
[ ] Ledger Tampering [ ] Payment Fraud / VST Abuse
[ ] Emergency Stop Event [ ] Badge Revocation / Silo Activation
[ ] Other: __________________________
Timeline:
Detection Time: ___________ (UTC)
Containment Time: ___________ (UTC)
Resolution Time: ___________ (UTC)
Immediate Actions Taken:
[ ] Emergency Stop issued -- Level: ___ Scope: _________________
[ ] Affected key revoked -- Key ID: _____________________________
[ ] Badge revocation posted to CPR -- Timestamp: ________________
[ ] VST cascade freeze confirmed -- VST IDs: ____________________
[ ] Parent SAK holder notified -- Contact: ______________________
[ ] Supervisory body notified -- Body: __________________________
Ledger Evidence:
First anomalous entry ID: ______________________________________
Last affected entry ID: ______________________________________
REVOKED_BADGE gateway events: __________________________________
Root Cause Summary:
___________________________________________________________________
Remediation Steps Taken:
___________________________________________________________________
Recurrence Prevention Measures:
___________________________________________________________________
Authorized Officer Signature: _______________________ Date: ________
Submitted to: ______________________________ (Parent SAK holder)
-----------------------------------------------------------------------
Appendix D. Glossary of Terms
ACC (AIGCSEP Compliance Certificate)
A signed, numbered certificate issued to an implementation that has
passed a Covenant compliance audit. Format:
ACC-<JurisdictionCode>-<OrgID>-<Revision>-YYYYMMDD.
AIGCSEP (Artificial Intelligence Governance Control and Service
Exchange Protocol) The formal name for the Covenant protocol
specified in this document.
Howlett Expires 10 December 2026 [Page 38]
Internet-Draft AIGCSEP June 2026
AOK (Audit Observer Key)
A long-lived public key held by oversight bodies, used solely to
verify ledger signatures. AOKs are published in the Covenant Public
Registry and cannot sign operational events.
Capabilities
A structured JSON document returned by a compliant service provider
describing available operations, request/response schemas, and
pricing. Retrieved via
GET /capabilities.
Compliance Certificate -- See ACC.
Container Hierarchy
The tree structure through which governance authority is expressed in
AIGCSEP. A parent container's rules govern all descendant nodes;
children may only restrict, never relax, inherited constraints.
Covenant Public Registry (CPR)
An append-only, publicly accessible dataset holding all public keys
(Sovereign RAK, SAK, AOK), compliance certificates (ACC), and
revocation records. Accessible via HTTPS or DNSSEC. Serves as the
real-time badge validation target for all compliant gateway endpoints.
Covenant Service Directory (CSD)
A registry of compliant service providers queryable by capability
type, compliance level, jurisdiction, and cost. Used by AI instances
during service discovery (Appendix B.1).
Data Plane (DP)
The lowest of the three AIGCSEP planes. Carries AI inputs, outputs,
and service responses. Content is developer-defined; the protocol does
not mandate its structure or moral content.
Economic Starvation
The market-driven consequence of badge revocation under the Silo
Model. A revoked entity loses access to all compliant services,
compute, and payment infrastructure. No active pursuit is required;
the market's collective refusal to transact is sufficient.
Emergency Stop
A signed GCP command that immediately halts one or more AI instances
within the issuer's governed scope. Defined in three levels
(0=Suspend, 1=Terminate, 2=Halt) of increasing severity. The scope is
a parameter of the command; the protocol defines no global kill-
switch. See Section 3.1.
Howlett Expires 10 December 2026 [Page 39]
Internet-Draft AIGCSEP June 2026
GCP (Governance Control Plane)
The highest of the three AIGCSEP planes. Isolated from AI processes;
holds governance keys, the Vault, the emergency stop mechanism, and
the ledger write interface. Accessible only to certified governance
modules.
HSM (Hardware Security Module)
A physical computing device that safeguards and manages digital keys
inside a tamper-evident boundary. All non-ephemeral private keys in
AIGCSEP MUST reside in HSMs or equivalent hardware-protected
environments.
Human Right to Technology
The foundational principle that every person, organization, and (where
applicable law recognizes it) every entity holds a fundamental right
to utilize technology for any lawful purpose. AIGCSEP enforces the
boundaries of that right as defined by human governance; it does not
define those boundaries itself.
Leash Key (LK)
An asymmetric key pair held by the AI instance's handler--never the AI
process itself. Signs all operational events and log entries, creating
the traceable accountability chain. Hidden from the AI's accessible
planes.
Payment Interface Layer (PIL)
The AIGCSEP component that defines standard API endpoints
(/capabilities, /transaction, /receipt) for metered service
exchange. Ledger-agnostic; any compliant settlement technology
may operate behind these interfaces.
PSK (Payment Settlement Key)
A key held by the payment interface used to sign financial
microtransactions, providing economic non-repudiation distinct from
the operational LK signature.
Rogue AI Silo
The isolated operational state of a non-compliant or revoked AI
entity. The entity may continue running with local resources but is
excluded from the Covenant Service Exchange Market through economic
starvation and gateway enforcement.
SAK (Sub-Authority Key)
A key held by agencies or organizations to certify subordinate
governance nodes and sign RuleSet Objects. Certified by the Sovereign
RAK.
Howlett Expires 10 December 2026 [Page 40]
Internet-Draft AIGCSEP June 2026
SCP (Service Control Plane)
The middle of the three AIGCSEP planes. Handles telemetry,
diagnostics, rate- limiting, and self-reporting. Accessible to the AI
instance and its developers.
Service Exchange Market
The interconnected ecosystem of compliant service providers, API
gateways, payment processors, and AI instances that together enforce
the Covenant through mandatory badge validation. Market participation
is voluntary; market exclusion for non-compliant entities is
automatic.
Session Lease Token (SLT)
An ephemeral token signed by the Leash Key at session initialization,
enabling high-frequency transaction validation against local databases
without invoking the HSM for each operation. The LK signs a single
aggregate anchor at session close. See Section 5.2.
Sovereign RAK (Root Authority Key)
The root cryptographic key of a governance hierarchy. Signs SAK
certificates and authorizes the highest-scope stop commands within
that hierarchy. Who holds the Sovereign RAK for a given jurisdiction
is a governance determination external to this protocol.
STK (Session Token Key)
An ephemeral asymmetric key pair held by the active AI process. Used
to authenticate API calls during a session. The only key material
directly accessible to the AI instance.
Values-Neutral Execution Pipeline
The design principle that AIGCSEP provides enforcement mechanics
without prescribing what should be permitted or prohibited. The
protocol is compatible with any legitimate government and legal
tradition. Determinations of what constitutes lawful conduct are the
exclusive domain of human governance.
Vault
The protected subsystem within the GCP that holds external-service
credentials and executes API calls on behalf of AI instances without
exposing secrets to those instances. The primary enforcement point for
badge validation and the point of VST issuance and management.
VST (Virtual Spending Token)
A pseudonymous, bounded payment identifier issued by the Vault to an
AI instance for a specific session. Allows financial delegation
without exposing underlying account credentials. Revocation of the
issuing badge cascades immediately to all associated VSTs.
Howlett Expires 10 December 2026 [Page 41]
Internet-Draft AIGCSEP June 2026
X-Covenant-Badge
The HTTP header carrying a base64url-encoded signed identity badge.
Required on all connections to compliant API Gateway and PIL
endpoints. Validated in real time against the CPR. A missing or
revoked badge triggers immediate connection refusal and a
REVOKED_BADGE ledger event.
Author's Address
J.P. Howlett
Independent
United States
Email: howlett.jp@gmail.com
Howlett Expires 10 December 2026 [Page 42]