AI Agent Governance Attestation Model — Specification v1.0.0

1. Abstract

This document specifies a model for cryptographically attesting AI agent actions within governance-bound execution environments. The model defines how agents are registered, how scope constraints are expressed, how actions are attested and receipted, how escalation is handled when actions exceed scope, how negative authority proofs are constructed, and how agent receipts integrate into a governance chain for deterministic replay.

The model treats agent authority as a first-class governance object: time-bounded, scope-constrained, cryptographically signed, and independently reconstructable. An agent's authority at any historical point in time can be derived from the governance chain without contacting the originating infrastructure.

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.

2. Status of This Document

This document is a Draft specification published by H33.ai, Inc. for public review and implementer feedback. Normative requirements are binding for implementations that claim agent governance attestation conformance.

Comments and errata SHOULD be directed to standard@h33.ai.

3. Definitions

Term	Definition
Agent	An autonomous or semi-autonomous software entity that executes actions within a governed system. An agent operates under a set of scope constraints and MUST be registered in the governance state before executing any action.
Agent Scope	The complete set of constraints that define what an agent is authorized to do, including action types, value limits, jurisdictions, time windows, and delegation depth.
Authority Delegation	The act of one governance principal (human or agent) granting a subset of its own authority to an agent. Delegated authority MUST NOT exceed the delegator's own authority.
Scope Constraint	A single rule within an agent's scope. Each constraint MUST be independently evaluable and MUST produce a deterministic boolean result for any given action.
Negative Authority Proof	A cryptographic attestation that an agent does not have authority to perform a specified action. The proof is verifiable without access to the agent's full scope definition.
Escalation	The process triggered when an agent attempts an action that exceeds its scope. Escalation transfers the decision to a higher-authority principal.
Governance Receipt	An immutable, signed record of an agent action, its scope evaluation result, and its governance chain linkage. The receipt is the atomic unit of agent audit history.
Governance DAG	A directed acyclic graph of governance receipts. Each receipt references one or more predecessor receipts. The DAG is the authoritative record of all governance events.

4. Agent Registration

An agent MUST be registered in the governance state before executing any action. Registration produces a governance receipt that establishes the agent's identity, initial scope, and delegating authority.

4.1. Registration Record

The delegator_id MUST reference a principal whose own scope is a superset of the agent's scope. The scope_hash is the SHA3-256 hash of the canonical serialization of the scope object. The valid_from and valid_until fields define the time window during which the agent is authorized to act.

4.2. Registration Constraints

• An agent MUST NOT be registered with a scope that exceeds the delegator's own scope.
• The valid_until timestamp MUST be strictly later than valid_from.
• The registration receipt MUST be signed with a multi-family PQ signature bundle as defined in the Multi-Family PQ Signature Framework.
• Re-registration (updating scope or extending validity) produces a new registration receipt that references the previous one as a predecessor.

5. Scope Constraints

An agent's scope is expressed as a set of constraints. Each constraint is a typed rule that evaluates to true (action permitted) or false (action denied) for a given action.

Constraint Type	Identifier	Description	Example
Action Type	action_type	Whitelist of permitted action types. Actions not in the list are denied.	["read", "review", "flag"]
Maximum Value	max_value	Upper bound on the monetary or quantitative value of a single action.	{"currency": "USD", "amount": 10000}
Jurisdiction	jurisdiction	Geographic or regulatory jurisdictions in which the agent may act.	["US", "EU", "UK"]
Time Window	time_window	Hours of the day or days of the week during which the agent may act. Evaluated in UTC.	{"days": ["mon","tue","wed","thu","fri"], "hours": [8, 18]}
Delegation Depth	delegation_depth	Maximum number of delegation levels this agent may create. 0 means the agent MUST NOT delegate to sub-agents.	0

Constraint evaluation is conjunctive: all constraints MUST evaluate to true for an action to be within scope. If any single constraint evaluates to false, the action is out of scope.

6. Action Attestation

Every agent action produces a governance receipt. The receipt is the immutable, cryptographically signed record of the action, its scope evaluation, and its position in the governance chain.

6.1. Receipt Structure

Field	Type	Description
receipt_type	string	Fixed value: "agent_action".
receipt_id	string (UUID)	Unique identifier for this receipt.
agent_id	string	Identifier of the acting agent. MUST reference a registered agent.
action_type	string	The type of action performed.
action_payload_hash	string	SHA3-256 hash of the action payload. The payload itself is not included in the receipt.
authority_hash	string	SHA3-256 hash of the agent's registration receipt at the time of action.
scope_hash	string	SHA3-256 hash of the scope under which the action was evaluated.
policy_hash	string	SHA3-256 hash of the governing policy active at the time of action.
scope_evaluation	object	Result of scope constraint evaluation. Includes count of constraints evaluated and passed.
timestamp	string (ISO 8601)	Time of action. MUST be UTC.
predecessor_hash	string	SHA3-256 hash of the immediately preceding receipt in this agent's governance chain.
signatures	object	Multi-family PQ signature bundle over the receipt.

7. Scope Enforcement

Scope enforcement is the evaluation algorithm that determines whether a proposed action is within the agent's authorized scope. The algorithm is deterministic: given identical scope definitions and action parameters, any conformant implementation MUST produce an identical result.

7.1. Evaluation Algorithm

1. Resolve agent registration. Look up the agent's most recent registration receipt. If no valid registration exists (expired or revoked), reject the action.
2. Verify time validity. Confirm the current timestamp is within the agent's valid_from / valid_until window. If outside, reject.
3. Evaluate constraints. For each constraint in the agent's scope, evaluate the constraint against the proposed action. Each constraint produces a boolean result.
4. Apply conjunction. The action is within scope if and only if all constraints evaluate to true.
5. Produce evaluation record. Record the number of constraints evaluated, the number that passed, and the overall result (permitted or denied).

8. Escalation Semantics

When an agent's scope enforcement evaluates to denied, the system MUST apply one of the following escalation policies. The applicable policy is declared in the agent's registration record.

Escalation Policy	Identifier	Behavior
Automatic Escalation	escalate_auto	The action is automatically forwarded to the agent's delegating principal for approval. The action is held pending until the principal approves or rejects. A governance receipt is produced for the escalation event.
Human Approval Required	escalate_human	The action is forwarded to a designated human approver (not necessarily the delegating principal). The system MUST suspend the action until human approval is recorded.
Rejection	reject	The action is rejected. No escalation occurs. A governance receipt is produced recording the rejection with the failing constraint(s).

8.1. Escalation Receipt

Escalations that are handled within this protocol (approved or rejected by the escalated-to principal) are not counted as scope violations for the purposes of the Operational Integrity Score Agent Scope Integrity dimension. Only unhandled escalations or actions that bypass scope enforcement entirely are scope violations.

9. Negative Authority Proofs

A negative authority proof is a cryptographic attestation that an agent does not have authority to perform a specified action at a specified time. Negative proofs are constructed from the agent's scope constraints and the governance chain state.

9.1. Proof Structure

Negative authority proofs are verifiable without access to the agent's full scope definition. The verifier needs only the scope_hash, the registration_hash, and the chain_state_hash to confirm that the proof is consistent with the governance state at the specified timestamp.

9.2. Denial Reasons

Reason Code	Description
action_type_not_in_scope	The requested action type is not in the agent's action_type whitelist.
value_exceeds_limit	The action's value exceeds the agent's max_value constraint.
jurisdiction_not_permitted	The action's jurisdiction is not in the agent's jurisdiction whitelist.
outside_time_window	The action timestamp is outside the agent's permitted time_window.
delegation_depth_exceeded	The agent attempted to delegate beyond its permitted delegation_depth.
registration_expired	The agent's registration has expired (valid_until has passed).
registration_revoked	The agent's registration has been explicitly revoked by the delegating principal.

10. Governance Chain Integration

Agent governance receipts are integrated into the governance DAG alongside all other governance events (policy changes, human approvals, system attestations). This integration ensures that agent actions are subject to the same replay and verification guarantees as all other governance state.

10.1. Chain Linkage

Every agent receipt MUST include a predecessor_hash field referencing the SHA3-256 hash of the immediately preceding receipt in the agent's event stream. The first receipt for a newly registered agent MUST reference the agent's registration receipt as its predecessor.

10.2. Cross-Agent References

When an action involves multiple agents (e.g., agent A requests data from agent B), each agent produces its own governance receipt. The receipts SHOULD cross-reference each other via an related_receipts array containing the receipt IDs of the counterpart receipts. Cross-references are OPTIONAL but RECOMMENDED for multi-agent interactions.

10.3. DAG Integrity

The governance DAG MUST be a directed acyclic graph. Cycles are a conformance violation. Implementations MUST reject any receipt whose predecessor_hash would create a cycle in the DAG.

11. Replay Semantics

Agent authority state at any historical timestamp MUST be reconstructable from the governance chain. Replay is the process of walking the chain from genesis (or a known checkpoint) to the target timestamp, evaluating each receipt in order to derive the agent's scope, delegation state, and action history at that point.

11.1. Replay Algorithm

1. Initialize. Start with an empty agent state.
2. Walk the chain. For each receipt in chain order up to and including the target timestamp:
   • If receipt_type == "agent_registration": set or update the agent's scope and validity window.
   • If receipt_type == "agent_action": apply the action to the agent's history. Verify that the scope evaluation result in the receipt is consistent with the scope at that time.
   • If receipt_type == "escalation": record the escalation and its resolution.
   • If receipt_type == "revocation": mark the agent as revoked.
3. Output. The agent's scope, validity, action count, and authority state at the target timestamp.

Replay is deterministic: identical chains MUST produce identical agent state. Replay does not require contacting the originating infrastructure.

12. Multi-Agent Governance

In environments with multiple agents, the governance DAG contains interleaved receipts from all agents. The following rules govern multi-agent interaction:

• Each agent has an independent event stream within the DAG, linked by its own predecessor_hash chain.
• Agent A MAY delegate authority to Agent B if Agent A's delegation_depth constraint permits it. The delegation produces a new registration receipt for Agent B with Agent A as the delegator_id.
• Delegated authority is transitive but bounded: if Agent A can delegate to depth 2, Agent B (delegated by A at depth 1) can delegate to depth 1, and Agent C (delegated by B at depth 2) MUST NOT delegate further.
• Revocation of a delegating agent's registration MUST cascade to all agents it delegated to. This cascade is recursive.
• Conflict resolution: if two agents attempt conflicting actions simultaneously, the governance system MUST serialize the actions and produce receipts in a deterministic order. The serialization algorithm is implementation-defined but MUST be deterministic and documented.

13. Failure Modes

Failure Mode	Detection	Required Behavior
Scope violation	Scope enforcement evaluates to denied, but the action is executed anyway (bypass).	The receipt MUST be flagged as a scope violation. The violation MUST be recorded in the governance chain. The OIS Agent Scope Integrity dimension is degraded.
Missing delegation	Agent's delegator_id references a principal that does not exist in the governance state.	Reject the agent's registration. No receipts may be produced for an agent without a valid delegation chain.
Expired authority	Current timestamp is past the agent's valid_until.	Reject all actions. Produce a rejection receipt. Escalation is not available for expired agents.
Tampered receipt	Signature verification on a receipt fails.	The receipt is invalid. The chain is broken at that point. All subsequent receipts in the agent's chain are unverifiable. Implementations MUST halt chain processing at the first tampered receipt.
Predecessor hash mismatch	A receipt's predecessor_hash does not match the hash of any receipt in the chain.	The receipt is invalid. Chain integrity is broken. Same behavior as tampered receipt.
Cascade revocation failure	A delegating agent is revoked but delegated agents continue operating.	This is a conformance violation. Implementations MUST enforce cascade revocation within one clock cycle of the revocation event.

14. Conformance Requirements

An implementation conforms to this specification if and only if:

1. Agent registration produces a governance receipt per Section 4, signed with a multi-family PQ signature bundle.
2. Scope constraints are expressed per Section 5, with conjunctive evaluation.
3. Every agent action produces a governance receipt per Section 6, with scope evaluation results included.
4. Scope enforcement follows the deterministic algorithm in Section 7.
5. Escalation semantics are implemented per Section 8 for all three escalation policies.
6. Negative authority proofs are supported per Section 9.
7. Governance chain integration follows the DAG model in Section 10, with no cycles permitted.
8. Replay of agent authority state is deterministic per Section 11: identical chains produce identical state.
9. Multi-agent delegation respects depth constraints and cascade revocation per Section 12.
10. Failure modes in Section 13 are handled as specified.

15. Reproducible Example

The following scenario demonstrates a complete agent lifecycle: registration, action within scope, action exceeding scope (triggering escalation), and replay.

16. Changelog

Version	Date	Changes
1.0.0	2026-05-22	Initial draft specification.

17. References

Reference	Title	URL
[RFC 2119]	Key words for use in RFCs to Indicate Requirement Levels	rfc-editor.org/rfc/rfc2119
[Multi-Family PQ]	Multi-Family Post-Quantum Signature Framework v1.0.0	h33.ai/specifications/multi-family-pq/
[OIS]	Operational Integrity Score Specification v1.0.0	h33.ai/specifications/ois/
[SHA3-256]	NIST FIPS 202: SHA-3 Standard	csrc.nist.gov