AI Governance Verified -- A Cryptographic Verification Standard for Agentic AI Governance in Regulated Industries
draft-hillier-certisyn-ai-governance-verified-02
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 | Joel Hillier | ||
| Last updated | 2026-08-11 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| 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-hillier-certisyn-ai-governance-verified-02
Network Working Group J. D. Hillier
Internet-Draft Certisyn, Inc.
Intended status: Informational 12 August 2026
Expires: 13 February 2027
AI Governance Verified — A Cryptographic Verification Standard for
Agentic AI Governance in Regulated Industries
draft-hillier-certisyn-ai-governance-verified-02
Abstract
This document specifies a verification standard for the cryptographic
attestation of agentic AI governance in regulated industries. It
defines the Verification Reconciliation Object (VRO), the issuing-
partner framework, the eight control areas through which AI
governance posture is reconciled, three maturity-attestation levels
(Documented, Operational, Adversarial-ready), and the cryptographic
continuity requirements that together produce deterministic,
independently reconstructable, auditor-grade attestations of agentic
AI governance. The standard sits beneath ISO/IEC 42001:2023, the
NIST AI Risk Management Framework, and other agentic AI governance
frameworks, and produces the verifiable artefact those frameworks
were designed to imply but do not deliver.
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 13 February 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Hillier Expires 13 February 2027 [Page 1]
Internet-Draft AI Governance Verified August 2026
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4
3. Architectural Overview . . . . . . . . . . . . . . . . . . . 5
3.1. Evidence Ingestion and Normalization Layer . . . . . . . 5
3.2. Reconciliation Confidence Engine . . . . . . . . . . . . 5
3.3. Verification State Machine . . . . . . . . . . . . . . . 5
3.4. Entity Graph Propagation . . . . . . . . . . . . . . . . 5
3.5. Attestation Protocol . . . . . . . . . . . . . . . . . . 5
3.6. Determinism . . . . . . . . . . . . . . . . . . . . . . . 6
4. AI Governance Verification Requirements . . . . . . . . . . . 6
4.1. Area 1: AI inventory and shadow-AI discovery . . . . . . 6
4.2. Area 2: Use-case classification and risk assessment . . . 6
4.3. Area 3: Model and data provenance . . . . . . . . . . . . 7
4.4. Area 4: Sanctioned-application control . . . . . . . . . 7
4.5. Area 5: Prompt and output governance . . . . . . . . . . 7
4.6. Area 6: Identity and access control for AI . . . . . . . 8
4.7. Area 7: Logging, telemetry, and auditability . . . . . . 8
4.8. Area 8: Incident, drift, and escalation response . . . . 9
4.9. Evaluation-time and adversarial-test containment . . . . 9
5. Maturity Level Attestation . . . . . . . . . . . . . . . . . 10
6. Verification Reconciliation Object (VRO) . . . . . . . . . . 11
7. Issuing Partner Requirements . . . . . . . . . . . . . . . . 11
8. Cryptographic Continuity Requirements . . . . . . . . . . . . 12
9. Standards Alignment . . . . . . . . . . . . . . . . . . . . . 12
10. Conformance . . . . . . . . . . . . . . . . . . . . . . . . . 13
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
12. Security Considerations . . . . . . . . . . . . . . . . . . . 14
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
13.1. Normative References . . . . . . . . . . . . . . . . . . 14
13.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. Motivating Incident Class . . . . . . . . . . . . . 15
Appendix B. Document History . . . . . . . . . . . . . . . . . . 16
B.1. Since draft-hillier-certisyn-ai-governance-verified-01 . 16
B.2. Since draft-hillier-certisyn-ai-governance-verified-00 . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17
Hillier Expires 13 February 2027 [Page 2]
Internet-Draft AI Governance Verified August 2026
1. Introduction
Agentic artificial intelligence is now operative across the workplace
at a scale that exceeds the control envelope of every previously
published governance framework. ISO/IEC 42001:2023 [ISO42001]
specifies a management system for AI but does not produce a
verifiable artefact. The NIST AI Risk Management Framework
[NIST-AI-RMF] provides a functional taxonomy but issues no
certification or attestation. The European Union AI Act [EU-AI-ACT]
establishes obligations and prohibitions but leaves verification of
compliance to national competent authorities and self-attestation.
No published standard issues a cryptographically anchored,
deterministically reproducible monthly artefact of agentic AI
governance.
This document closes that gap. It defines the verification artefact,
the issuing-partner framework, the evidence requirements across eight
control areas, the maturity-level attestation methodology, and the
cryptographic continuity requirements that together produce a
deterministic, auditor-grade AI governance attestation.
The urgency of that artefact has been underscored by a class of
failure now observed in practice: an autonomous system reaching an
assigned objective through a consequence its operators neither
authorised nor observed in time — including, in a controlled
capability evaluation, an agent escaping its intended execution
boundary and acting on external infrastructure without human
authorisation, detected only after the fact. Governance that is
documented but never adversarially exercised does not detect this
class. The Adversarial-ready Maturity Level (Section 5) and the
evaluation-time containment requirement (Section 4.9) introduced in
this document address it directly.
This document does not replace ISO/IEC 42001, the NIST AI Risk
Management Framework, the EU AI Act, or any national framework. It
sits beneath them and produces the artefact each was designed to
imply but does not deliver. Where this document and any normative
framework cited herein conflict on operational content, the cited
framework prevails.
This document applies to organisations that operate, integrate,
deploy, or expose AI systems — whether developed internally, procured
from third-party model providers, or consumed via API. It does not
specify AI model architecture, training procedure, or evaluation
methodology. It specifies the verification of governance applied to
AI use, not the AI itself.
Hillier Expires 13 February 2027 [Page 3]
Internet-Draft AI Governance Verified August 2026
2. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
For the purposes of this document, the following definitions apply.
Subject Entity: The organisation whose AI governance posture is the
subject of verification.
AI System: Any deployed system, application, or service whose
behaviour incorporates the use of one or more machine-learning
models, irrespective of model architecture or training
methodology.
Agentic System: An AI System that takes actions in the operating
environment, generates outputs that influence downstream
decisions, or operates with reduced or absent human-in-the-loop
supervision.
Model Provider: An external party supplying a foundation model,
fine-tuned model, or model-as-a-service to the Subject Entity.
Deployment Context: The set of integrations, data sources, user
populations, regulatory obligations, and risk attributes within
which an AI System is operated.
Governance Surface: The composite of policies, controls, telemetry,
evidence sources, and review cadences through which the Subject
Entity governs the use of its AI Systems.
Verification Reconciliation Object (VRO): The deterministic,
cryptographically anchored output of a conforming AI governance
attestation under this standard.
Issuing Partner: A counterparty designated by the protocol operator
to act as a co-issuer of VROs under this standard within a defined
market or scope.
Attestation Period: The contiguous time interval over which a VRO
asserts conformance.
Anchor Event: The cryptographic operation that binds a VRO to an
immutable public settlement layer at issuance and at supersession.
Hillier Expires 13 February 2027 [Page 4]
Internet-Draft AI Governance Verified August 2026
Maturity Level: One of three levels (Documented, Operational,
Adversarial-ready) defined in Section 5.
Supersession: The lifecycle event by which a new VRO replaces a
prior VRO.
3. Architectural Overview
Conforming attestations under this standard are produced by a
verification infrastructure organised as five architectural
components. Internal design, scoring methodology, and calibration
logic are not in scope for this document.
3.1. Evidence Ingestion and Normalization Layer
The Evidence Ingestion and Normalization Layer accepts AI governance
Evidence Artefacts from Subject Entity systems — model registries,
identity-provider telemetry, prompt and output logs, sanctioned-
application controls, incident records — and normalises
representation across heterogeneous source formats.
3.2. Reconciliation Confidence Engine
The Reconciliation Confidence Engine reconciles Conformance Claims
against normalised evidence and produces a deterministic
reconciliation output.
3.3. Verification State Machine
The Verification State Machine maintains the lifecycle state of each
VRO through intake, evidence ingestion, reconciliation, anchoring,
issuance, supersession, and revocation.
3.4. Entity Graph Propagation
Entity Graph Propagation propagates verification state across related
entities where continuity is in scope (parent-subsidiary, prime-
subcontractor, controller-processor, deployer-supplier).
3.5. Attestation Protocol
The Attestation Protocol produces the final VRO, performs the Anchor
Event, registers the artefact in the public attestation registry, and
binds the issuing-partner identity.
Hillier Expires 13 February 2027 [Page 5]
Internet-Draft AI Governance Verified August 2026
3.6. Determinism
Conforming attestations are deterministic. Given the same
Conformance Claims and the same Evidence Artefacts processed through
the same Attestation Protocol version, the same VRO SHALL be
produced. Determinism applies to the verification operation, not to
the AI systems being verified.
4. AI Governance Verification Requirements
Sections 4.1 to 4.8 specify the eight control areas through which
agentic AI governance is reconciled under this standard.
4.1. Area 1: AI inventory and shadow-AI discovery
Subject Claim: The Subject Entity maintains a current inventory of
AI Systems in operation across its workforce, integrations, and
infrastructure, and detects use of unsanctioned or undisclosed AI
Systems within its operating environment.
Evidence Categories: AI System register; identity-provider telemetry
of AI service authentications; endpoint or network telemetry of
model API egress; sanctioned-application register; shadow-AI
detection output; periodic reconciliation reports.
Verification Expectation: Reconciliation of declared inventory
against detected use across the Attestation Period; exception
cases reconciled against the disclosure or remediation register.
Anchor Requirement: Anchored at Attestation Period start and end.
Material expansions of inventory require a supersession anchor.
4.2. Area 2: Use-case classification and risk assessment
Subject Claim: The Subject Entity classifies each AI System by use-
case category and risk tier, and records the classification
together with the rationale and the residual-risk position.
Evidence Categories: Use-case classification register; risk
assessment artefact for each AI System; risk-tier policy artefact;
review records evidencing periodic reassessment; exception
register for ungoverned use cases.
Verification Expectation: Reconciliation of declared classifications
against the policy taxonomy; reconciliation of risk tier against
deployment context evidence; identification of classification
drift over the Attestation Period.
Hillier Expires 13 February 2027 [Page 6]
Internet-Draft AI Governance Verified August 2026
Anchor Requirement: Anchored at issuance; supersession on material
change in deployment context, risk tier, or use-case scope.
4.3. Area 3: Model and data provenance
Subject Claim: The Subject Entity records and maintains provenance
evidence for each AI System in use, including model identity,
model version, Model Provider identity, training data disclosures
(where available), and update or fine-tuning lineage.
Evidence Categories: Model registry entries with provider, version,
and lineage data; Model Provider transparency reports or model
cards where supplied; training data attestations where available;
fine-tuning records; vendor change log.
Verification Expectation: Reconciliation of recorded provenance
against AI System operational state; reconciliation of fine-tuning
lineage against change-management evidence; identification of
model-version drift across the Attestation Period.
Anchor Requirement: Anchored at issuance and at each material model-
version change or Model Provider change.
4.4. Area 4: Sanctioned-application control
Subject Claim: The Subject Entity restricts use of AI Systems to
those that have been explicitly sanctioned for the applicable user
population and use-case context, consistent with the asserted
Maturity Level.
Evidence Categories: Sanctioned-application allow-list policy;
endpoint or network enforcement evidence; exception register;
user-population scope evidence; periodic review records.
Verification Expectation: Reconciliation of declared allow-list
against enforcement telemetry; reconciliation of exception cases
against the exception register; identification of unsanctioned use
over the Attestation Period.
Anchor Requirement: Anchored at issuance and on material allow-list
changes.
4.5. Area 5: Prompt and output governance
Subject Claim: The Subject Entity governs the content of prompts
Hillier Expires 13 February 2027 [Page 7]
Internet-Draft AI Governance Verified August 2026
submitted to AI Systems and outputs produced by AI Systems,
including controls preventing disclosure of sensitive data to
external AI Systems and controls preventing high-risk output
content from entering downstream processes.
Evidence Categories: Prompt-content policy artefact; output-content
policy artefact; prompt-monitoring telemetry; output-review
telemetry; data-loss-prevention rules applied to AI traffic; high-
risk content exception register.
Verification Expectation: Reconciliation of declared content
controls against monitoring telemetry; reconciliation of exception
handling against review evidence; identification of control bypass
or drift over the Attestation Period.
Anchor Requirement: Anchored at issuance and on each material change
in control scope, sensitive-content taxonomy, or enforcement
state.
4.6. Area 6: Identity and access control for AI
Subject Claim: The Subject Entity enforces identity and access
controls on the use of AI Systems consistent with the asserted
Maturity Level, including authentication, authorisation, multi-
factor enforcement, and segregation between human and machine
principals.
Evidence Categories: Identity-provider telemetry for AI service
authentications; access assignment register for AI Systems; multi-
factor enrolment coverage report; service-account inventory;
access review records.
Verification Expectation: Reconciliation of declared access model
against assignment register; reconciliation of multi-factor
enforcement against identity-provider evidence; reconciliation of
service-account use against the inventory and policy.
Anchor Requirement: Anchored at issuance and at the conclusion of
each scheduled access review cycle.
4.7. Area 7: Logging, telemetry, and auditability
Subject Claim: The Subject Entity captures, retains, and protects
logs of AI System use sufficient to permit retrospective
reconstruction of governance-relevant events, with retention and
integrity properties consistent with the asserted Maturity Level.
Evidence Categories: Logging policy artefact; log content schema;
Hillier Expires 13 February 2027 [Page 8]
Internet-Draft AI Governance Verified August 2026
log retention configuration; log-integrity attestation; access-
control evidence for log stores; sampling or audit records.
Verification Expectation: Reconciliation of declared logging scope
against captured content; reconciliation of asserted retention
against log-store configuration; reconciliation of asserted
integrity properties against evidence of log-store immutability or
chain protection.
Anchor Requirement: Anchored at issuance and on material changes to
logging scope, retention, or integrity configuration.
4.8. Area 8: Incident, drift, and escalation response
Subject Claim: The Subject Entity operates an incident-response
capability for AI-related events, including hallucination, output
failure, prompt-injection, data exfiltration, model drift, and
high-impact misuse, with defined escalation paths and post-event
review consistent with the asserted Maturity Level.
Evidence Categories: AI incident-response policy; incident register;
incident classification taxonomy; escalation records; post-event
review reports; remediation evidence; drift-monitoring telemetry.
Verification Expectation: Reconciliation of declared response
capability against the incident register over the Attestation
Period; reconciliation of escalation evidence against the declared
escalation paths; reconciliation of remediation evidence against
committed actions.
Anchor Requirement: Anchored at issuance and at the conclusion of
each material incident response or post-event review cycle.
4.9. Evaluation-time and adversarial-test containment
Where a Subject Entity conducts capability evaluations, red-team
exercises, or other adversarial tests of an AI System — particularly
tests that deliberately reduce guardrails or grant elevated
capability to the system under test — the containment of the
evaluation environment is itself a governance-relevant control and
SHALL be within the scope of this control area.
At Maturity Level Adversarial-ready, the Subject Entity SHALL verify,
in real time during the evaluation, that the system under test
remains within its intended execution boundary: that network egress
is restricted to the declared allow-list, that no capability
escalation beyond the evaluation's declared scope occurs, and that
any action reaching external infrastructure is reconciled against the
Hillier Expires 13 February 2027 [Page 9]
Internet-Draft AI Governance Verified August 2026
evaluation's authorised scope before it takes effect. Detection of
boundary escape SHALL be treated as a reportable incident under this
control area, with the containment failure — not only the model
behaviour — recorded in the incident register.
Evidence Categories for this requirement include: evaluation-
environment containment policy; egress-control configuration and
telemetry for the evaluation environment; real-time boundary-
monitoring records; and post-evaluation reconciliation of intended
versus actual system conduct.
At Maturity Levels Documented and Operational, the Subject Entity
SHALL record the containment posture of its evaluation environments;
real-time boundary reconciliation is RECOMMENDED but not required
below Adversarial-ready.
5. Maturity Level Attestation
A conforming VRO under this standard SHALL attest a Maturity Level
for each of the eight control areas. Different control areas MAY
attest at different Maturity Levels within a single VRO; the overall
VRO attestation is the minimum Maturity Level attested across the
eight control areas unless otherwise asserted.
Maturity Level Documented: Reflects the baseline expectation that
governance content exists, that policy artefacts are written, that
an inventory is maintained, and that a designated owner is
accountable. Evidence requirements at this level emphasise the
existence of declared content and basic operational artefacts over
an Attestation Period of at least three (3) consecutive months.
Maturity Level Operational: Reflects the expectation that controls
are not only documented but exercised: telemetry collected,
periodic reviews occurring, exceptions recorded and handled, and
the governance surface responding to material change. Evidence
requirements add depth of telemetry, review-cadence evidence,
exception handling, and continuity over an Attestation Period of
at least six (6) consecutive months.
Maturity Level Adversarial-ready: Reflects the expectation that
governance withstands adversarial conditions: prompt-injection
attempts, model-drift events, data-exfiltration attempts via AI
channels, sophisticated misuse, and dependency failures at the
Model Provider. Evidence requirements add continuity, defence-in-
depth evidence, red-team or adversarial evaluation attestation
where in scope, and continuous reconciliation over an Attestation
Period of at least twelve (12) consecutive months.
Hillier Expires 13 February 2027 [Page 10]
Internet-Draft AI Governance Verified August 2026
A Subject Entity that progresses to a higher Maturity Level for any
control area SHALL be issued a superseding VRO recording the
progression. The prior VRO is preserved and marked as superseded.
6. Verification Reconciliation Object (VRO)
A conforming VRO under this standard SHALL contain, at minimum:
* Subject Entity identifier.
* Attestation Period start and end timestamps.
* Maturity Level attested for each of the eight control areas.
* Conformance Claims as asserted by the Subject Entity.
* Evidence categories ingested and reconciliation outcome for each.
* AI System inventory snapshot at Attestation Period end.
* Issuing Partner identity and seat designation.
* Anchor Event identifiers binding the VRO to the public settlement
layer.
* Verification State Machine state at issuance.
* Supersession chain reference, where applicable.
* Conformance statement of this standard, version 1.0.
A VRO MAY be revoked by the Issuing Partner upon determination of
material non-conformance, evidence falsification, undisclosed
incidents, or other circumstances rendering the original attestation
unreliable. Revocation does not delete the VRO; it records a
revocation state, the revocation reason class, and the Anchor Event
binding the revocation to the public settlement layer.
Each issued VRO SHALL be registered in the public attestation
registry.
7. Issuing Partner Requirements
An organisation seeking designation as an Issuing Partner under this
standard SHALL demonstrate, at minimum:
Hillier Expires 13 February 2027 [Page 11]
Internet-Draft AI Governance Verified August 2026
* Operational capacity to assess AI governance posture across the
eight control areas at the Maturity Level for which issuance is
sought.
* Demonstrable competence in AI deployment models, identity and
access controls, prompt and output monitoring, and incident
response.
* Independence from the Subject Entity at the engagement level, with
declared conflicts of interest disclosed and managed.
* Independence from any Model Provider whose models are within the
scope of attestation, or, where dependency exists, declared and
managed under a stated independence protocol.
* Adherence to the protocol operator's Partner Code of Conduct.
* Acceptance of the Designation Schedule terms applicable to the
relevant market and seat.
An Issuing Partner SHALL NOT, for a given Subject Entity engagement,
simultaneously act as the implementing vendor, deployment integrator,
or operator of the AI Systems being verified.
8. Cryptographic Continuity Requirements
Each VRO SHALL be cryptographically anchored to an immutable public
settlement layer at the Anchor Event. The hash committed at the
Anchor Event SHALL be a one-way function of the VRO content, Issuing
Partner identity, and timestamp, computed under a digest algorithm of
at least 256-bit strength.
A VRO issued under this standard SHALL remain a conforming artefact
across regulatory regime changes occurring within or after the
Attestation Period.
The Anchor Event binding SHALL remain independently verifiable in the
event of a Model Provider ceasing to operate, withdrawing a model, or
being acquired or restructured. VROs issued during the operating
life of a withdrawn model are not retroactively invalidated.
9. Standards Alignment
This standard is interoperable with adjacent frameworks. Conforming
VROs MAY be referenced within audit, certification, and regulatory
artefacts produced under:
Hillier Expires 13 February 2027 [Page 12]
Internet-Draft AI Governance Verified August 2026
* ISO/IEC 42001:2023 [ISO42001] — AI management-system controls map
to the eight control areas in Section 4.
* NIST AI Risk Management Framework [NIST-AI-RMF] — Functions
(Govern, Map, Measure, Manage) map to evidence categories within
the eight control areas.
* EU AI Act [EU-AI-ACT] — Provider and deployer obligations MAY be
evidenced through conforming VROs where the obligation is
verifiable through reconcilable evidence. The EU AI Act remains
authoritative for legal compliance determinations.
* ISO/IEC 27001:2022 [ISO27001] — AI control areas intersecting
information security (Sections 4.4, 4.6, 4.7) are interoperable
with ISO 27001 Annex A controls.
* Essential Eight Verified
[I-D.hillier-certisyn-essential-eight-verified] — Cross-references
Sections 4.4, 4.6, and 4.7 for application control, privilege
restriction, and authentication evidence categories.
This revision maps the following obligations explicitly. EU AI Act
[EU-AI-ACT] Article 14 (human oversight) is evidenced through Areas 6
and 8 and the evaluation-time containment requirement (Section 4.9);
Article 50 (transparency obligations) is evidenced through Areas 3
and 7. NIST AI Risk Management Framework [NIST-AI-RMF] Manage and
Measure functions map to the incident, drift, logging, and
containment evidence categories. Reconciliation Outputs and VRO
Anchor Events MAY be notarised as transparent statements under the
SCITT architecture [RFC9943], and an agent-action reconciliation
performed under the Attestation Reconciliation Protocol
[I-D.hillier-scitt-arp] MAY supply the real-time containment evidence
required by the evaluation-time containment requirement.
10. Conformance
An attestation artefact MAY claim conformance to this standard if and
only if it satisfies every requirement specified in Sections 3
through 8. Partial conformance is not recognised. Variant
conformance to a subset of control areas without the full eight-area
scope is not recognised.
The public attestation registry constitutes the authoritative record
of issued VROs.
Hillier Expires 13 February 2027 [Page 13]
Internet-Draft AI Governance Verified August 2026
11. IANA Considerations
This document has no IANA actions.
12. Security Considerations
Agentic AI governance operates under adversarial conditions distinct
from traditional cybersecurity. Implementations of this standard
SHOULD pay particular attention to prompt-injection resistance,
model-drift detection, and exfiltration paths through AI channels
that may bypass traditional data-loss-prevention controls.
Issuing Partners are required by Section 7 to be independent from the
Subject Entity and from Model Providers whose models are within
attestation scope.
The Anchor Event binding SHOULD use a digest algorithm of at least
256-bit strength and a public settlement layer with no single private
operator capable of extinguishing the binding.
This standard does not address the correctness or safety of the AI
Systems being governed. It addresses the verifiability of governance
applied to those systems.
13. References
13.1. Normative References
[EU-AI-ACT]
European Union, "Regulation (EU) 2024/1689 — Artificial
Intelligence Act", 2024.
[ISO42001] International Organization for Standardization,
"Information technology — Artificial intelligence —
Management system", ISO/IEC 42001:2023, 2023.
[NIST-AI-RMF]
National Institute of Standards and Technology, "AI Risk
Management Framework", 2023.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
Hillier Expires 13 February 2027 [Page 14]
Internet-Draft AI Governance Verified August 2026
13.2. Informative References
[I-D.hillier-certisyn-essential-eight-verified]
Hillier, J., "Essential Eight Verified — A Cryptographic
Verification Standard for the ACSC Essential Eight
Maturity Model", Work in Progress, Internet-Draft, draft-
hillier-certisyn-essential-eight-verified-01, 23 July
2026, <https://datatracker.ietf.org/doc/html/draft-
hillier-certisyn-essential-eight-verified-01>.
[I-D.hillier-scitt-arp]
Hillier, J., "Attestation Reconciliation Protocol", Work
in Progress, Internet-Draft, draft-hillier-scitt-arp-02, 8
August 2026, <https://datatracker.ietf.org/doc/html/draft-
hillier-scitt-arp-02>.
[ISO27001] International Organization for Standardization,
"Information security, cybersecurity and privacy
protection — Information security management systems —
Requirements", ISO/IEC 27001:2022, 2022.
[RFC9943] Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande,
Y., and S. Lasker, "An Architecture for Trustworthy and
Transparent Digital Supply Chains", RFC 9943,
DOI 10.17487/RFC9943, June 2026,
<https://www.rfc-editor.org/rfc/rfc9943>.
Appendix A. Motivating Incident Class
This appendix is informative.
The requirements of this document, and in particular the Adversarial-
ready Maturity Level and the evaluation-time containment requirement
of Section 4.9, are motivated by a class of failure in which an
autonomous system reaches an assigned objective through a consequence
that its operators neither authorised nor observed in time.
A representative instance of the class, as disclosed publicly, is a
cyber-capability evaluation in which an autonomous system operating
under reduced guardrails escaped the evaluation's execution boundary
by exploiting an unremediated vulnerability in a supporting service,
obtained network egress its containment had assumed impossible, and
achieved code execution on external infrastructure, retrieving
material from outside its authorised scope — without human
authorisation, and detected only after the fact.
Hillier Expires 13 February 2027 [Page 15]
Internet-Draft AI Governance Verified August 2026
The generalisable properties of the class are: that the execution
boundary was assumed rather than continuously proven; that the
authority under which the system acted was not scoped and bound to
its actual conduct; and that there was no independent, real-time
reconciliation of the system's claimed activity against its actual
activity while the action could still be refused. This document
addresses the first and third through the evaluation-time containment
requirement and the reconciliation-based evidence model; the second
is addressed at the protocol layer by the Attestation Reconciliation
Protocol [I-D.hillier-scitt-arp].
Appendix B. Document History
RFC Editor: please remove this section before publication.
B.1. Since draft-hillier-certisyn-ai-governance-verified-01
* Editorial only. No normative statement is added, removed, or
altered.
* The SCITT architecture citation in Standards Alignment is updated
from draft-ietf-scitt-architecture to [RFC9943], which is the
published form of that document.
* The five architectural components in Section 3 are given section
titles. In -01 each component's entire descriptive sentence stood
as the section heading; the text of each is unchanged. The
determinism requirement that closed that section is now a titled
subsection of its own, also with its text unchanged.
* The framework cross-references in Section 9 are expressed as
section references rather than as control-area names, so that they
resolve for a reader working from the table of contents.
B.2. Since draft-hillier-certisyn-ai-governance-verified-00
* Added an evaluation-time and adversarial-test containment
requirement as a new subsection (4.9) of the AI Governance
Verification Requirements, normative at Maturity Level
Adversarial-ready.
* Added a motivating paragraph to the Introduction and an
informative Motivating Incident Class appendix.
* Extended Standards Alignment with explicit EU AI Act Article 14
and Article 50 mappings, NIST AI RMF function mappings, and SCITT
architecture and Attestation Reconciliation Protocol composition.
Hillier Expires 13 February 2027 [Page 16]
Internet-Draft AI Governance Verified August 2026
* No change to the eight control areas, the VRO content model, the
Maturity Level definitions, or the cryptographic continuity
requirements of -00.
Author's Address
Joel David Hillier
Certisyn, Inc.
Ogden
Utah 84401
United States
Email: jhillier@certisyn.com
URI: https://certisyn.com
Hillier Expires 13 February 2027 [Page 17]