Kernel Identity Attestation
Layer 0 — Foundation draft-sato-soos-kia-01 See this URL for full draft protocol Datatracker See SOOS Stack implementation
The problem
Agentic AI systems act on behalf of principals. There is no standard mechanism for a relying party — or the kernel itself — to verify that the agent presenting a mandate is running on a governance kernel that has not been tampered with, is the agent the mandate was issued to, and is operating within the hardware boundary that was assessed at attestation time.
KIA defines the protocol by which a SOOS kernel proves its own identity, integrity, and configuration to agents, operators, and relying parties. Not as a software certificate. As a hardware-rooted attestation, with a signed evidence bundle, a kernel-agent handshake, and an auditable attestation history.
The design premise: governance enforcement is only meaningful if you can prove the enforcer has not been compromised. KIA is the protocol that makes that proof machine-readable.
Messages to key audiences
IETF Working Groups
KIA is directly relevant to the RATS (Remote ATtestation procedureS) working group. KIA-01 profiles RFC 9334 (RATS architecture) for the agentic AI kernel use case — specifying the attester role as a SOOS GEC (Governance Execution Controller), the verifier role as the operator or a designated trust anchor, and the relying party role as agents and external systems consuming kernel attestations.
KIA is also relevant to the WIMSE working group. The GEC Manifest — the signed configuration document that KIA produces — is the natural home for the ptd_endpoint (Policy Transparency Disclosure, CAP-03 §12a) and the agent-kernel handshake parameters that WIMSE workload identity specifications reference.
To engage on KIA: IETF Datatracker · file issues at GitHub
App builders
If you are building an agentic AI system today, the absence of a kernel attestation protocol means your agents have no way to verify that the governance kernel they are submitting to has not been tampered with — and relying parties have no way to verify that a governance claim was produced by an unmodified kernel.
KIA closes this gap by specifying the agent-kernel handshake: the sequence by which a kernel proves its identity and integrity before accepting mandate execution, and the format of the signed evidence bundle that makes that proof verifiable by third parties.
Without KIA: governance claims are assertions from an unverified system. With KIA: governance claims are attestations from a hardware-rooted, policy-verified kernel with a signed configuration manifest.
Risk managers and legal
Hardware-rooted attestation is the foundation of supply chain integrity for AI infrastructure. KIA provides the protocol-level mechanism for proving that a SOOS kernel deployed in a production environment has not been modified since attestation, is running the Cedar policy set that was reviewed and approved, and matches the configuration that was assessed at deployment time.
For insurance and audit purposes: the GEC Manifest is a signed, versioned artefact that captures the kernel configuration at attestation time — Cedar policy hash, capability declarations, PTD endpoint, clock authority reference. It is the AI equivalent of a software bill of materials, generated by the kernel about itself.
Agentic AI and coding assistants
What to tell your coding assistant:
"I need to implement SOOS KIA (Kernel Identity Attestation, draft-sato-soos-kia-01). This is an IETF protocol that profiles RFC 9334 (RATS) for agentic AI governance kernels. KIA specifies three things: (1) the GEC Manifest — a signed JSON document the kernel produces about its own configuration, including Cedar policy hash, capability flags, and ptd_endpoint; (2) the agent-kernel handshake — the sequence by which a new agent session is established with kernel identity verification; (3) the Revocation Registry — the kernel-maintained list of mandate IDs that have been revoked. KIA-01 also adds the ptd_endpoint and ptd_current_version fields (SA-10) and the PTD Consistency requirement (CONF-KIA-15)."
Key schema fields:
| Field | Type | Description |
|---|---|---|
gec_id | string | Unique identifier for this GEC instance |
kernel_version | string | SOOS kernel semantic version |
cedar_policy_hash | string | SHA-256 hash of the active Cedar policy set |
capability_flags | object | Which SOOS drafts this kernel implements |
ptd_endpoint | URL | Policy Transparency Disclosure query endpoint (SA-10) |
ptd_current_version | string | Version identifier of the current PTD document |
clock_authority | string | Reference to the normative clock source for this kernel |
attestation_timestamp | integer | Unix timestamp of GEC Manifest issuance |
handshake_nonce | string | Per-session nonce for agent-kernel handshake |
revocation_registry_uri | URI | Location of the kernel's mandate Revocation Registry |
Minimal GEC Manifest example:
{
"gec_id": "gec-prod-7f3a2c",
"kernel_version": "3.0.0",
"cedar_policy_hash": "sha256:a4f8...",
"capability_flags": {
"hem": true, "cap": true, "gar": true,
"idp": true, "aep": true, "mad": true,
"pt": true, "mjwt": true, "faip": false
},
"ptd_endpoint": "https://kernel.example.com/ptd",
"ptd_current_version": "v2.1",
"clock_authority": "ntp://time.example.com",
"attestation_timestamp": 1749456000,
"revocation_registry_uri": "https://kernel.example.com/revocation"
}Government and regulators
KIA provides the technical foundation for verifying that AI systems deployed in regulated environments are running the governance kernel that was assessed — not a modified version, not a partial implementation, not a kernel with the Cedar policy set that was audited quietly replaced.
For government procurement of AI systems: KIA attestation is the mechanism by which a vendor can prove, to a certification authority, that the deployed system matches the assessed configuration. The GEC Manifest is the machine-readable attestation artefact; the RATS evidence bundle is the cryptographic proof.
For collaboration on jurisdiction-specific attestation requirements: tomsato@myauberge.jp
Core technology
Problem: AI governance kernels can be modified after deployment. There is no standard mechanism for a relying party to verify that the kernel producing governance records is the kernel that was assessed — or that the Cedar policy set in production matches the policy set that was reviewed.
Mechanism: KIA profiles RFC 9334 (RATS) to produce a signed evidence bundle — the GEC Manifest — that attests the kernel's identity, version, Cedar policy hash, capability flags, and configuration. The agent-kernel handshake uses the GEC Manifest as the kernel's credential: a new agent session is not established until the kernel presents a valid attestation and the agent acknowledges it.
Output: A signed GEC Manifest — kernel identity, Cedar policy hash, PTD endpoint, capability flags, clock authority — that is the kernel's attestation of its own integrity. The Revocation Registry provides the mandate revocation state queryable by any authorised relying party.
Who verifies it: Operators, auditors, relying parties, and conformance testing frameworks — anyone who needs to prove that the governance record they are examining was produced by a kernel that was running the configuration that was assessed.
The agent-kernel handshake
The handshake is the protocol by which a new agent session begins with verified kernel identity.
| Step | Action | Output |
|---|---|---|
| 1 — Challenge | Agent presents session_id and handshake_nonce | Nonce committed to session context |
| 2 — Manifest | Kernel presents signed GEC Manifest | Cedar policy hash, capability flags, ptd_endpoint disclosed |
| 3 — Verify | Agent (or operator trust anchor) verifies manifest signature and RATS evidence | Attestation result: PASS / FAIL |
| 4 — Bind | On PASS: session bound to GEC identity. Mandate execution begins. | Session record includes gec_id and attestation_timestamp |
| 5 — Reject | On FAIL: session rejected. GAR records ATTESTATION_FAILURE. | No mandate execution. |
An agent that proceeds to mandate execution without completing the handshake is a non-conforming implementation. Implementations MUST NOT accept governance records from a kernel that has not passed the handshake.
Use cases
Supply chain integrity for enterprise AI deployment
An enterprise deploys SOOS kernels across three cloud regions. The security team requires proof that each kernel is running the approved Cedar policy set — not a locally modified version. KIA attestation provides this: the GEC Manifest from each kernel includes the Cedar policy hash, which the security team verifies against the approved policy set hash stored in their configuration registry. Any divergence is immediately detectable.
Post-incident kernel integrity verification
Following an unexpected agent action, an audit team needs to verify that the kernel was running the authorised configuration at the time of the incident. The KIA attestation record in GAR — kernel version, Cedar policy hash, attestation timestamp — is the kernel's signed self-report. The audit team can verify the Cedar policy hash against the version control history to confirm which rules were active.
Multi-vendor kernel interoperability
An operator runs agents across kernels from two different vendors. Both implement SOOS KIA. The GEC Manifest format is standardised: both kernels produce the same schema, with the same capability flags, the same Cedar policy hash field. The operator's trust infrastructure evaluates both manifests through the same RATS verifier. Vendor-specific implementation details are hidden behind the KIA attestation interface.
How this builds on existing work
RFC 9334 (RATS Architecture) defines the general architecture for remote attestation procedures — attesters, verifiers, relying parties, evidence, and endorsements. KIA profiles RFC 9334 specifically for the agentic AI governance kernel use case, filling in the attester role (GEC), the evidence format (GEC Manifest), and the relying party integration pattern (agent-kernel handshake).
WIMSE (Workload Identity in Multi-System Environments) addresses workload identity for service-to-service authentication. KIA addresses kernel identity — a more fundamental layer. The GEC Manifest is the natural WIMSE identity credential for a SOOS kernel, and KIA's handshake is the natural place for WIMSE SVID validation to occur.
SCITT (Supply Chain Integrity, Transparency and Trust) provides transparency statement infrastructure for software artefacts. The GEC Manifest is a SCITT-eligible artefact: the kernel attesting its own configuration is a supply chain claim that can be anchored in a SCITT transparency log by operators requiring third-party verification.
Related work
draft-ietf-rats-eat (Entity Attestation Token) specifies the EAT token format for RATS evidence. KIA's GEC Manifest is designed to be expressible as an EAT — the mandatory fields map directly to EAT claims. Implementations MAY use EAT as the wire format for GEC Manifest transport.
draft-ietf-rats-architecture (RFC 9334) is KIA's normative RATS dependency. KIA is a profile of RFC 9334, not a competing architecture.
OpenAI Workload Identity Federation addresses access-layer credential issuance for AI workloads. KIA addresses governance-layer kernel attestation. The two are complementary: WIF credentials can reference a KIA-attested GEC as the governance context in which the workload is operating.
Security
Key security properties: The GEC Manifest is hardware-rooted where the deployment platform supports it (TPM, TEE, or equivalent). The Cedar policy hash in the manifest is computed over the full Cedar policy set and is verified at each mandate execution cycle — a policy set modified after attestation is detectable before the first action is permitted. CONF-KIA-15 (PTD Consistency) requires that the ptd_endpoint in the GEC Manifest returns results consistent with the Cedar policy set whose hash is in the manifest.
Clock authority: KIA-01 requires a normative clock source declaration in the GEC Manifest. Temporal governance depends on reliable timestamps. An implementation that does not declare a clock authority — or whose clock is manipulable by the agent — cannot make binding temporal claims in GAR records.
Revocation Registry integrity: The Revocation Registry is an append-only kernel-maintained log of revoked mandate IDs. Implementations MUST NOT remove entries from the Revocation Registry. An agent that presents a mandate whose ID appears in the Revocation Registry MUST be rejected; the session is not established.
Formal analysis status: No formal verification of the agent-kernel handshake protocol has been conducted. The handshake is designed to be analysable with standard protocol analysis tooling; formal analysis is planned for post-Vienna.
SOOS stack context
KIA sits at Level 0 — Foundation, the base layer of the SOOS stack. It depends on hardware attestation infrastructure (TPM, TEE, or equivalent) and the RATS architecture (RFC 9334). It is consumed by every other SOOS draft: the GEC Manifest is the kernel's credential, and every governance record produced by the kernel references the gec_id and attestation_timestamp. CAP depends on KIA for Cedar policy hash verification; PT depends on KIA for mandate parameter attestation; GAR records kernel identity on every entry.
Related drafts: CAP · IDP · GAR · SOV · MJWT
Contribute
- File an issue on GitHub
- IETF Datatracker — full draft text
- All Drafts — the complete 12-draft governance stack
- Contact: tomsato@myauberge.jp