Workload identity nuances for agentic AI

[TheBankster]

Agentic AI workloads may be, out of necessity, very short-lived and issued very frequently. Source: https://unmitigatedrisk.com/?p=1075
The purpose of launching a workload instance may dramatically influence what the resulting identity is authorized to do.

[wenhuizhang]

Workload TrustedID

In TWI, a Workload Trusted Identity (TrustedID) typically comes from Platform Attestation + Workload Measurements, making it a platform-level identity.

Components

1. Platform Identity

   • CPU/TEE hardware root identity
     (e.g., Intel TDX MRSIGNER / MRENCLAVE, ARM Realm Hash, etc.)
   • Host/VM ID (UUID or host key derivation)

2. Workload Measurements

   • Image hash (OCI image manifest digest, not individual layer hashes)
   • SBOM hash (optional, binds to software supply chain integrity)
   • Configuration measurement (config hash / policy hash)

3. Temporal Component

   • Optional timestamp or session ID for anti-replay protection

Representation Formats

• X.509 extension fields

  • Place Platform Claims in the Subject Alternative Name (SAN) field.
  • Example: SAN:URI for sub, with custom OID extensions carrying
    image_digest, config_hash, etc. (or reference a transparency log entry).

• JWT + EAT Claims

  • Includes ueid, hwmodel, swname, swversion, etc.

• TWI Workload Identity Token (WIT)

  • Recommended form for workload identity in TWI.

How These Fields Are Generated

• Hash algorithm: SHA-256, formatted as sha256:<hex>.

• Image hash: Use the OCI image manifest digest (not a single layer).

• Configuration hash: Normalize first, then hash:

  • JSON → normalize with JCS (JSON Canonicalization Scheme)
  • YAML → convert to JSON (sort fields, strip comments, unify units), then apply JCS
  • Text → UTF-8 + normalization

• TEE attestation:

  • Source: TDX / SGX / SEV-SNP / ARM Realm / NVIDIA CAA → produces a Quote
  • Process: Verifier validates → generates Attestation Results → compute tee_report_hash

• Keys:

  • cnf.jwk private keys should ideally be generated and stored in HSM/TEE.
  • If software-based keys are used, enforce non-exportability and key rotation policies.

Why These Fields Are Necessary

• Make runtime trust explicit (platform, image, configuration, and supply chain).
  • A single sub or DNS name is insufficient to defend against supply chain attacks or config drift.
• Proof of Possession (PoP) binding (cnf.jwk) prevents token theft/replay.
  • Even if intercepted, tokens cannot be reused.
• Short validity (exp)
  • Ensures quick expiration after key rotation or policy updates.

[TheBankster]

The Relying Party in the real world is some kind of server or service that prizes ease of administration. I refer you to the enterprise use case for TWI: https://docs.google.com/document/d/1sRNAl0KL4h1zt-YcGEetu7Qxm9c5M-asxTJiqC5o5CU/edit

Much like we might want the relying party to have access to the richness of information about the attesters, in scenarios I'm familiar with this creates a management headache that would in fact preclude adoption. Please join TWI discussions to go over your idea and this feedback so we can come up with something that we can all live with.