Workload Identity

Capabilities answer what an agent is allowed to do. Workload identity answers which process is allowed to present the capability. Chio treats SPIFFE as its canonical workload-identity scheme: every runtime-attestation evidence record carries a typed workloadIdentity projection, and policy can require a specific SPIFFE trust domain and path before a token is honored.

Why SPIFFE Is the Canonical Scheme

A capability token that is not bound to a workload is only as strong as the bearer secret. A leaked token is a full compromise. SPIFFE fixes this by giving every workload a cryptographically verifiable identity that is issued locally by the runtime (mesh, node agent, or attestation service) and is not transferable between processes.

Chio does not reinvent workload identity, and it does not try to federate arbitrary identity schemes. Instead it pins one: the SPIFFE normalized shape. Every verifier bridge (Envoy ext_authz principal, Azure MAA JWT, AWS Nitro, Google Confidential VM) projects into the same workloadIdentity record, and policy matches against that one shape.

Pairing the two layers gives defense in depth. SPIFFE binds workload identity. Chio binds capability. An attacker who steals a token still needs to control the specific SPIFFE-identified workload the token was issued to. That shrinks the blast radius of credential theft without adding a new sidecar.

The Normalized Shape

Runtime-attestation evidence carries workload identity in one normalized object. Chio policy, governed validation, and receipt metadata all consume this exact shape:

{
  "workloadIdentity": {
    "scheme": "spiffe",
    "credentialKind": "x509_svid",
    "uri": "spiffe://prod.chio/payments/worker",
    "trustDomain": "prod.chio",
    "path": "/payments/worker"
  }
}

The trustDomain and path fields are derived from uri at evidence-ingestion time. Policy matches on the derived fields rather than parsing the URI on every admission.

Credential Kinds

The credentialKind field records how the identity was presented to chio. All three are valid SPIFFE credential shapes:

How an Identity Reaches Chio

Chio does not issue SPIFFE identities. It consumes whatever the runtime already emits. Three delivery paths cover every production surface:

1. Envoy ext_authz principal

In a mesh that issues SPIFFE IDs via SPIRE, the ext_authz CheckRequest carries the caller's SPIFFE ID in the source principal. The chio ext_authz adapter lifts that principal directly into workloadIdentity with credentialKind: uri (the mTLS peer certificate already anchored the identity; chio does not re-verify it). See the Envoy ext_authz integration for the configuration surface.

2. Explicit runtimeAttestation

SDK callers and CLI issuance paths pass runtimeAttestation.workloadIdentity on the governed or issuance request. This is the canonical surface when the caller already holds the SPIFFE ID and wants chio to bind the capability to it without going through a verifier bridge.

3. Verifier-bridge projection

Chio's attestation verifier bridges (Azure MAA JWT, AWS Nitro, Google Confidential VM) can project a SPIFFE ID out of vendor claims into the same normalized shape. For Azure this is a configured x-ms-runtime.claims.* field; for Nitro and Google CVM it is a trust-policy projection against the preserved vendor claims. The projection rules are identical to path 2: the derived workloadIdentity must be a valid SPIFFE URI, or issuance fails closed.

Relationship to Runtime Assurance

Workload identity is one leg of chio's runtime-assurance story. The other leg is the assurance tier: how strongly the environment that presented the identity has been attested. Policy can require both independently.

Issuance resolves the highest satisfied tier at token-mint time and stamps the capability with a minimum runtime-assurance constraint. Governed execution later re-checks that the presented evidence still clears the stamped tier. Workload identity can be required at any tier, including basic.

Matching on Workload Identity in Policy

Rules consume workload identity through require_workload_identity (hard) or prefer_workload_identity (soft). Both accept a WorkloadIdentityMatch object that gates on trust domain, path prefix, and credential kind:

rules:
  payments_write:
    enabled: true
    default: block
    allow:
      - transfer_funds
    require_workload_identity:
      scheme: spiffe
      trust_domain: prod.chio
      path_prefixes:
        - /payments/worker
        - /payments/reconciler
      credential_kinds:
        - x509_svid
        - jwt_svid

The match is additive. An identity satisfies the rule when trust_domain matches exactly, path starts with one of the configured prefixes, and credentialKind is in the allowed set. A missing field means "any value is acceptable" for that dimension. The full schema lives in the policy-schema reference.

Fail-Closed Rules

Workload-identity evaluation follows the same fail-closed stance as the rest of the kernel. The following conditions deny issuance or governed execution outright:

• An explicit workloadIdentity conflicts with the raw runtimeIdentity in the same evidence record
• A claimed SPIFFE URI is malformed (wrong scheme, missing trust domain, empty path)
• A require_workload_identity rule is configured and the presented identity does not satisfy it
• The verifier bridge projects a non-SPIFFE identifier into the workload-identity slot

Operator-facing recovery for each of these is documented in the WORKLOAD_IDENTITY_RUNBOOK reference. Treat any of the above as a trust failure, not a transient transport failure.

Receipts Carry the Identity Forward

When a governed request clears with workload identity bound, the resulting receipt records the exact workloadIdentity object that was accepted. This turns the receipt into portable evidence: a downstream auditor can confirm not only that the capability was valid and the guards passed, but that the specific SPIFFE workload the capability was bound to was the one that actually presented it.

For the full set of receipt fields and how workload identity appears in the enterprise-profile projection, see the receipt format reference.

Summary

1. SPIFFE is canonical. Chio does not federate arbitrary identity schemes; it pins one normalized shape.
2. Three credential kinds. uri, x509_svid, and jwt_svid cover mesh, serverless, and explicit-claim surfaces.
3. Three delivery paths. Envoy principal, explicit runtime attestation, and verifier-bridge projection all converge on the same workloadIdentity record.
4. Identity and assurance compose. Policy can require the SPIFFE path and the runtime-assurance tier independently.
5. Bound receipts. The accepted workload identity lives in the signed receipt, making capability-to-workload binding auditable offline.

Next Steps

• Bind Workload Identity · policy recipes and issuance commands for gating capabilities on a SPIFFE ID
• Envoy ext_authz · how the mesh path lifts a SPIFFE principal into chio
• Trust Model · the zero-ambient-authority stance that workload identity fits into
• Policy Schema · the full WorkloadIdentityMatch contract