| Internet-Draft | AIGCSEP | June 2026 |
| Howlett | Expires 10 December 2026 | [Page] |
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).¶
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 (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.¶
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:¶
- 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.¶
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.¶
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].¶
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.¶
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.¶
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
¶
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.)¶
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.¶
| 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.¶
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.¶
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.¶
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.¶
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:¶
{
"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.¶
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 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.¶
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.¶
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.¶
Every entity and interface in the Covenant possesses one or more cryptographic identities. Authority and compliance are enforced mathematically through chained signatures.¶
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¶
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.¶
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..."
}
¶
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..."
}
}
¶
Each transaction carries two proofs: - payment_sig = PSK signature (settlement proof) - ledger_sig = LK signature (AI accountability)¶
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:¶
{
"revoked_key": "LK-a1b2c3...",
"reason": "compromise",
"issuer": "/gov/us/federal",
"timestamp": "2026-05-30T20:05Z",
"signature": "base64-SovRAKsig..."
}
¶
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.¶
| 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 |¶
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.¶
AIGCSEP incorporates a standardized Payment Interface Layer to allow AI agents and human users to exchange value securely and transparently.¶
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.¶
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.¶
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
¶
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.¶
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.¶
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.¶
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.¶
- 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¶
{
"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..."
}
¶
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.¶
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¶
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.¶
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.¶
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.¶
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
¶
The Covenant's guarantees of accountability depend on proper isolation, strong cryptography, and reliable audit mechanisms.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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?¶
- 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.¶
[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
¶
- 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)
¶
This document has no IANA actions.¶
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.¶
Implementations that claim AIGCSEP compliance MUST satisfy the following requirements, organized by keyword per RFC 2119 conventions.¶
- 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.¶
- 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.¶
- 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.¶
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.¶
-----------------------------------------------------------------------¶
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.¶
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).¶
{
"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>¶
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..."
}
¶
AIs discover available services by issuing a GET /capabilities request.¶
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"
}
¶
Level 1 (Terminate) -- 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-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..."
}
}
¶
{
"revoked_key": "LK-a1b2c3...",
"reason": "compromise",
"issuer": "/gov/us/federal",
"timestamp": "2026-05-30T20:05Z",
"new_key_ref": "LK-d4e5f6...",
"signature": "base64-SovRAKsig..."
}
¶
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.¶
-----------------------------------------------------------------------¶
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.¶
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.¶
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.¶
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.¶
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.¶
Step 1 -- Rotation Scheduled The LK holder generates a new LK key pair inside the HSM. The private key never leaves the hardware boundary.¶
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.¶
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.¶
Any observer holding an Audit Observer Key (AOK) can independently verify any ledger entry:¶
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.
¶
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.¶
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.¶
-----------------------------------------------------------------------¶
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.
¶
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)¶
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¶
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: _______________________________________________________________¶
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: ____________¶
Incident ID: ___________________ Date Detected: ___________________ Reporting Organization: ____________________________________________ Affected Node(s): __________________________________________________¶
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)¶
-----------------------------------------------------------------------¶
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.¶
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.¶
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.¶
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.¶
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.¶