Model chain of trust (4/4): who serves the model and which machine you trust

The three previous articles closed questions about the artefact: what contract the served model exposes, where its bytes come from and why you trust them. What remains is the one almost nobody asks until an auditor asks it: nothing proves that the process currently returning tokens on port 8000 is the inference engine and not something that slipped into the cluster and inherited its token. And a second one, worse: whether the machine it runs on is trustworthy, and against whom.

These are different problems with different projects. Workload identity is solved by SPIFFE/SPIRE, a CNCF graduated project since 2022. Environment isolation is covered by Kata Containers and Confidential Containers, the latter promoted to CNCF incubating on 22 July 2026, four days before this article was published. The first is cheap and almost always worth it. The second is expensive, more than the vendor’s press release suggests, and is only justified against a specific threat model.

TL;DR

• User identity ≠ workload identity. OIDC says which person is behind a request; it does not say which process serves it. ServiceAccount tokens, static keys and gateway API keys are bearer credentials: whoever holds them, is them.
• SPIFFE defines a URI identifier (spiffe://domain/path) and a verifiable document (SVID, X.509 or JWT) delivered by a Workload API that does not require the workload to hold any prior secret. SPIRE implements it with node and workload attestation; defaults: default_x509_svid_ttl 1 h, default_jwt_svid_ttl 5 min, ca_ttl 24 h.
• Identity is only worth something if something enforces it: Istio/Envoy via SDS, Cilium with mutual authentication (with serious reservations) or an ext_authz with OPA in front of the gateway.
• Three rungs of isolation: container with a shared kernel → Kata Containers (its own kernel and VM; v3.32.0 from June 2026) → Confidential Containers (hardware TEE, hypervisor outside the trust base, remote attestation with Trustee per RFC 9334).
• The overhead of confidential mode runs from ~0 % to ~28 % depending on what you measure: GPU-only in CC with large batches sits around 4-8 %, while the full stack (a CVM with Intel TDX plus an H100 in CC), measured independently in 2026, gives +21.8 % to +27.8 % on TTFT and −17.7 % to −21.1 % on throughput. Honest heuristic: reserve 15-25 % extra capacity.
• MIG and vGPU are forbidden in CC mode according to NVIDIA’s reference architecture, and every GPU on a node goes in the same mode.
• Closing criterion: the order is contract → digest → signature verified at admission → workload identity → TEE.

The analogy: the biosafety laboratory

A laboratory handling pathogens solves two problems much like ours, separately.

The first is who gets in. The company badge is not enough: at the airlock there is a specific credential, short-lived and automatically renewed (if lost, it expires on its own within an hour), issued only after independently checking that the applicant is where they say they are and is who they say they are. That credential is the SVID; the prior check is attestation.

The second is which room you work in, and here there are containment levels. On the open bench the air is shared and anything aerosolised affects everyone: the normal container, with a kernel shared by all the neighbours. One rung up, the biological safety cabinet, with a physical barrier and its own airflow: Kata Containers. At the very top, the maximum containment laboratory, where maintenance staff change filters without ever seeing the sample: the TEE, where the operator maintains the machine but cannot read its memory. And before opening the airlock somebody verifies that the integrity of the suit and of the room is as expected: remote attestation with conditional secret release.

The uncomfortable lesson: the maximum containment level is a cost decision before it is one more degree of security. Nobody builds a BSL-4 to grow yeast. The useful question is who it isolates from, not how much.

Part A — Workload identity

Six services talking to each other and none of them knows who the other is

In a serious inference cluster, like the seven layers one, the gateway talks to the serving engine, the engine queries the vector database, the trace collector receives spans from everyone and the agents with MCP invoke tools that in turn call the gateway. Many east-west connections and, in most deployments, none of them authenticated.

User identity says which person is behind the request and is resolved with OIDC, as when putting Keycloak in front of MCP. Workload identity says which process issues it: there is no human on the other side, no browser, no consent, and the process is born and dies in seconds. Its three usual substitutes fail for different reasons:

There is no cryptographic link between credential and process: copy the credential, copy the identity. In a multi-tenant cluster like the H100 cluster one, real isolation then depends on network topology and not on identity.

SPIFFE: the standard

SPIFFE and its implementation SPIRE graduated together in the CNCF on 20 September 2022. As of July 2026 they are settled infrastructure, not a bet.

The SPIFFE ID is a URI of the form spiffe://<trust-domain>/<workload-identifier>, for example spiffe://inferencia.example/ns/inferencia/sa/vllm: a name, not a credential. The trust domain is the root of trust (organisation, environment or site), and the guidance recommends separating workloads from different sites or security environments into different domains.

The SVID is the credential that proves that ID. The X509-SVID carries the SPIFFE ID in the URI-type SAN, not in the CN, which the specification discourages as a source of identity, and it is the preferred format. The JWT-SVID exists for when there are L7 proxies terminating TLS in the middle, with the replay risk the documentation warns about:

Certificate:
    Issuer: C=ES, O=SPIFFE
    Validity
        Not Before: Jul 26 08:00:00 2026 GMT
        Not After : Jul 26 09:00:00 2026 GMT
    Subject: C=ES, O=SPIRE, CN=vllm.inferencia
    X509v3 extensions:
        X509v3 Key Usage: critical
            Digital Signature, Key Encipherment
        X509v3 Extended Key Usage:
            TLS Web Server Authentication, TLS Web Client Authentication
        X509v3 Basic Constraints: critical
            CA:FALSE
        X509v3 Subject Alternative Name:
            URI:spiffe://inferencia.example/ns/inferencia/sa/vllm

One hour of validity, and what authenticates is the SAN URI: the CN is decorative.

The Workload API is the elegant piece: a local UNIX socket from which the workload obtains its SVID, its private key and the trust bundle, without presenting any secret. The documentation is explicit: “the Workload API does not require that a calling workload have any knowledge of its own identity, or possess any authentication token”. That solves the cold start of all identity cryptography: the secret you would need in order to obtain the first secret.

SPIRE: how that document is issued

SPIRE has a server (the authority that signs) and one agent per node (which exposes the Workload API), and it chains two checks.

Node attestation verifies that the agent runs where it says it does. In Kubernetes the reference attestor is k8s_psat, which validates a projected token with an audience against the API server; on bare metal there are TPM-based attestors. A note of honesty: SPIRE v1.15.1, from 28 May 2026, is a security patch over an incorrect PKCS7 validation in the azure_imds attestor that allowed attested documents to be forged and a virtual machine to be impersonated.

Workload attestation answers the opening question. The k8s attestor receives the PID of the process that opens the socket, infers the pod from its cgroup membership and queries the kubelet for the metadata. From there come the selectors: namespace, service account, pod name and UID, labels, owner, node and, above all, container and image by tag or by digest. From SPIRE v1.15.0 (19 May 2026) Sigstore support stopped being experimental, enabling selectors by signature verification status, certificate subject and issuer, and transparency log. That closes the series’ circle: you can require that the engine’s SVID go only to the container whose image carries a valid cosign signature from the expected issuer, which is what was verified in article 3/4. Provenance goes from being a one-off admission check to a precondition of identity at runtime.

spire-server entry create \
  -parentID spiffe://inferencia.example/spire/agent/k8s_psat/prod/nodo-gpu-a \
  -spiffeID spiffe://inferencia.example/ns/inferencia/sa/vllm \
  -selector k8s:ns:inferencia \
  -selector k8s:sa:vllm \
  -selector k8s:container-name:vllm \
  -selector k8s:container-image:vllm/vllm-openai@sha256:aa11bb22cc33 \
  -x509SVIDTTL 3600 \
  -federatesWith spiffe://sede-b.example

The selectors are conjunctive: a pod in another namespace, with another SA or with another image does not obtain that SVID even if it shares the node.

The default TTLs have three consequences. Rotation is continuous, not a one-off event: code that loads the certificate once at startup will break exactly one hour later. Server downtime has a clock: twenty minutes are invisible, two hours bring down the cluster’s authenticated communications, and the scaling guide admits that “a single SPIRE Server instance represents a single point of failure”, with the datastore as the bottleneck and indicative figures running from two replicas of 1 CPU and 1 GB for 10 agents to eight of 16 CPU and 16 GB for 5,000 agents and 10,000 workloads. And tag-based selectors are fragile: the runtime may report one tag or another depending on the node and the moment, so the correct selector is the digest, as in article 2/4.

Federation between trust domains

Two sites with independent clusters, or an external partner exposing a reranker, should not share an authority. SPIFFE federation makes each domain publish a bundle endpoint with its public trust material and the other poll it periodically: the https_web profile authenticates it with web PKI and https_spiffe with an X509-SVID from the domain itself, enabling automatic rotation and revocation of the root. The relationship is one-directional, bundles from different domains must never be merged and refresh is by polling with a default suggestion of five minutes. In practice, site A’s gateway accepts requests from site B’s engine without sharing a CA or an identity database, and cutting the relationship means deleting a bundle, not revoking certificates.

From identity to effective authorisation

An SVID blocks nothing by itself; somebody has to compare the presented ID against a policy.

Istio + SPIRE is the best-worn integration: Istio detects a UNIX socket implementing Envoy’s SDS API and the proxy obtains its identities from there instead of from istiod, mounted with the SPIFFE CSI Driver (recommended over hostMount). Two conditions break deployments: SPIRE’s trust domain and Istio’s must match exactly, and SPIRE only issues to previously registered workloads, including Istio’s own components. With that, policy is written in terms of identity and not IP:

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: vllm-solo-desde-gateway
  namespace: inferencia
spec:
  selector:
    matchLabels:
      app: vllm
  action: ALLOW
  rules:
    - from:
        - source:
            principals: ["inferencia.example/ns/inferencia/sa/gateway"]
      to:
        - operation:
            methods: ["POST"]
            paths: ["/v1/chat/completions", "/v1/completions"]

It is a layer on top of the NetworkPolicy from layered hardening: there we closed communication pairs by topology; here we also require who calls and on what path.

Cilium offers mutual authentication backed by SPIRE, tempting if you already use eBPF for the data network. It deserves criticism: it is still marked beta in the stable documentation, and The New Stack published a reasoned critique arguing that the design does not preserve mTLS properties over the life of the connection (it uses the handshake only to authenticate and discards the session keys) and that the identity model rests on eventually consistent per-node IP-identity caches, which can allow traffic that policy should deny.

The inference gateway and LiteLLM do not speak SPIFFE natively as of this article, and saying so is better than suggesting an integration that does not exist. The pattern that does work is the one the project itself documents: an Envoy in front that terminates mTLS with an X509-SVID or validates a JWT-SVID and delegates to OPA via ext_authz. The gateway carries on with its own job (quota, budget, routing), as we saw when choosing an OSS gateway and in the L7 router; workload identity is resolved one hop earlier.

AI agents and MCP: the missing piece

An agent invoking tools over MCP is a shared secret with legs: it is handed a static credential, the MCP server cannot know whether the caller is the legitimate agent or any process holding the same string, and the blast radius is the entire set of exposed tools. The threat model for agent isolation warned that a granted permission is a usable permission; with bearer credentials it is also transferable.

SPIFFE provides what is missing: the agent presents a short-lived SVID obtained through attestation and the MCP server authorises against the SPIFFE ID. In 2026 this stopped being theory: there is work at the IETF on dynamic OAuth client registration based on trusted SPIFFE issuers, and in June 2026 Google published a SPIFFE-based Agent Identity in its IAM. None of it is fully standardised.

Two honest caveats. SPIFFE answers “who”, not “why”: to know whether the action is the one the user asked for you need traceability (MCP with OTel) and runtime detection with Tetragon. And both identities must be composed: the agent proves its own with an SVID and propagates the delegating user’s in the token, authorising on the pair. Collapsing them into one is how you end up with agents able to do, in the system’s name, things no user could.

Part B — Isolation of the execution environment

Kata replaces runc with a runtime that boots a lightweight virtual machine per pod, with its own kernel and a kata-agent inside; for Kubernetes it is transparent via RuntimeClass. As of July 2026 the stable branch is 3.32.x (3.32.0 is from June 2026, with Rust 1.94, Go 1.25.11, QEMU 11.0.1, guest kernel 6.18.35 and containerd 2.3), and in April 2026 the 4.0.0 preview was published, making the Rust runtime (runtime-rs) the default and leaving the Go one deprecated until 5.0.0, because of memory footprint.

For GPUs the route is VFIO passthrough. The NVIDIA GPU Operator automates it with sandboxWorkloads.enabled=true and sandboxWorkloads.mode=kata, installing the VFIO Manager, the Sandbox Device Plugin, the Confidential Computing Manager and the Kata Manager. It requires virtualisation and ACS in the BIOS, IOMMU, kata-deploy 3.29.0 or later, containerd (not CRI-O), the KubeletPodResourcesGet feature gate (on by default from Kubernetes 1.34) and removing the NVIDIA drivers from the host: the GPU is handed over whole to the VM and the guest manages it.

apiVersion: v1
kind: Pod
metadata:
  name: vllm-kata
  namespace: inferencia
spec:
  runtimeClassName: kata-qemu-nvidia-gpu
  containers:
    - name: vllm
      image: vllm/vllm-openai@sha256:aa11bb22cc33
      resources:
        limits:
          nvidia.com/pgpu: "1"

Two measurable costs. Memory: the VM reserves its own and you have to declare it as overhead in the RuntimeClass so the scheduler does not overcommit the node. And startup: according to the SESAME'24 study on serverless confidential containers, cold start goes from around 6 s with runc to around 7 s with Kata, and warm start from 1 s to 2 s. Acceptable for an engine that takes minutes to load weights; unacceptable for ephemeral functions.

Confidential Containers: the TEE

Confidential Containers (CoCo) takes the hypervisor and the platform operator out of the trust base. The CNCF promoted it to incubating on 22 July 2026, with more than 150 active contributors, 26 repositories and over 1,200 merged pull requests, and with Microsoft Azure, Intel, AMD, IBM, NVIDIA, Alibaba and Red Hat behind it. A serious project, but incubating means it is not graduated and that its integration surface changes between versions.

The components are the CoCo pods (unmodified containers run in a TEE via Kata) and Trustee: KBS (Key Broker Service, which releases secrets conditionally), AS (Attestation Service, which validates the hardware evidence) and RVPS (Reference Value Provider Service, which holds the reference values). Inside the guest, the Attestation Agent collects the evidence and the Confidential Data Hub consumes the secrets.

The flow is a clean instance of the RATS architecture from RFC 9334: the agent inside the TEE is the attester, the Attestation Service the verifier and the Confidential Data Hub the relying party. The evidence is a hardware-signed report with the boot measurements; the AS validates it against the RVPS values; and only if it matches does the KBS release the key that decrypts the image layers or the weights. Without valid attestation there is no key, and without a key there is no model: that is what stops the operator extracting it.

A mapping warning: the confidential-containers/operator repository was archived in February 2026 and deployment moved to the Helm charts and the trustee-operator. As of July 2026 the latest chart release is v0.21.0, aligned with kata-deploy 3.31.0, and Trustee v0.20.0, with TLS 1.3 and post-quantum cryptography, external plugins for the KBS and multi-GPU support via Intel Trust Authority and NVIDIA NVSwitch.

apiVersion: confidentialcontainers.org/v1alpha1
kind: TrusteeConfig
metadata:
  name: trusteeconfig
  namespace: operators
spec:
  profileType: Restrictive
  httpsSpec:
    tlsSecretName: trustee-tls-cert

The Permissive profile exists for development and should not leave it: it is the mode in which attestation does not block.

The hardware: CPU and GPU

On the CPU side the two relevant TEEs are AMD SEV-SNP and Intel TDX; NVIDIA’s reference architecture sets EPYC Milan/Genoa and Xeon Emerald/Granite Rapids as the baseline. Host support is no longer the hard part.

On the GPU side, the technical description of the design of the first confidential GPUs explains what CC mode on an H100 buys you. Memory is split into a Compute Protected Region that hardware firewalls stop both the CPU over PCIe and other GPUs over NVLink from accessing. Everything crossing the CPU-GPU boundary passes through bounce buffers encrypted with AES-GCM-256, and command buffers and CUDA kernels are encrypted and signed before crossing the bus. There is a chain of trust from GPU boot with a signed attestation report, and only NVIDIA-signed firmware runs in CC mode, validated against NRAS or locally in isolated environments. And the performance counters are disabled in hardware as a side-channel mitigation: that is the telemetry much of observability with DCGM depends on.

What it does not protect: the package’s HBM memory is not encrypted (it is considered resistant to interposers, which is a claim about physical difficulty and not a cryptographic guarantee); nothing against denial of service, because the operator who cannot read you can still switch you off; nothing against timing or access-pattern side channels; and nothing against a bug in your own code inside the enclave or prompt injection, which remains the job of guardrails.

On Blackwell, NVIDIA announces (2 July 2026) NVLink encryption that extends confidential computing to up to 8 GPUs, non-existent on Hopper and a condition for serving a large model with tensor parallelism. The reference architecture lists H100, H200, RTX Pro 6000 Blackwell Server Edition and B200 in single-GPU passthrough, and H100/H200 in PPCIe mode and B200 for multi-GPU.

The overhead numbers, with source and with judgement

Here it pays to distrust everybody, papers included. The published spread runs from 0 % to 28 % because the studies do not measure the same thing.

The reconciliation: the penalty is in the data path, not in the GPU’s compute. NVIDIA itself quantifies the bottleneck: the effective bandwidth of the CPU-GPU interconnect in CC mode is limited by the CPU’s encryption throughput, “around 4 GB/s”. From there, three rules. The higher the compute/I-O ratio, the lower the overhead: a 70B with large batches and long sequences amortises the toll almost entirely, and a 7B with small batches and short prompts pays it in full. Adding the CPU TEE brings its own cost, and that is where most of the difference between 4-8 % and 20 % lies. And model loading and cold start are the worst cases, with tens of gigabytes crossing an encrypted bus at 4 GB/s, which makes everything discussed in from disk to HBM and in speeding up cold start more important.

The recommendation from the authors of the 2026 study, reserving between 15 % and 25 % extra capacity, is the figure I would take to a capacity planning exercise, and not the vendor’s “98 % of native performance”. Both can be true at once; only one is prudent for sizing.

When each rung is worth it

The nuance that saves the most money: the two axes are independent. Kata without a TEE is cheap and delivers most of the isolation between tenants; CoCo only adds something if your threat model includes the operator. If you build a sovereign factory with your own iron and your own staff and you answer “no” to that question, the TEE is a cost with no return.

Operational traps

MIG and vGPU against confidential mode. NVIDIA’s GA 1.0.0 reference architecture is blunt: MIG and vGPU are forbidden in CC mode, and mixed-mode nodes are not supported; every GPU on a host goes in CC or none does. The forums show the typical contradiction of a moving area: in February 2026 a moderator states that MIG+CC is not supported and in April a user cites the MIG page suggesting that Hopper and Blackwell already allow it. As of this article the reference architecture overrides the product page: if your multi-tenancy rested on partitioning the GPU with MIG, enabling CC sends you back to “one whole GPU per tenant”.

Startup grows non-linearly. SESAME'24 breaks down where: SEV memory provisioning adds around one second per 2 GB of guest (SEV pins every page in advance, and an inference VM allocates a lot), the OVMF firmware about three seconds and layer decryption another three to five. Scaling from 0 to 16 instances goes from 16 s with runc to 190 s: irrelevant for a stable Deployment, a design change for aggressive autoscaling with KEDA.

Version coupling is brutal. Kata, kata-deploy, GPU Operator, containerd, QEMU with its own patches, guest kernel, NVIDIA driver and Trustee are a matrix that has to be treated as a unit: the reference architecture fixes Kubernetes 1.32 or later, Kata 3.29, GPU Operator 26.3.1 or later, containerd 2.2.2 or later and QEMU 10.1. Add it to the weight the stack’s operators already carry.

Attestation fails after a firmware update, and that is normal. The RVPS reference values describe a specific boot state. When you patch the SEV-SNP firmware, the microcode or the GPU firmware, the TCB version changes, the evidence stops matching and the KBS does not release keys, so the pods do not start. Since these updates usually respond to a security bulletin, the typical scenario is “we applied the critical patch on a Friday and on Saturday inference would not start”. The correct procedure reverses the order: update the reference values first with an overlap window, and patch the iron afterwards.

The attestation service is a single point of failure by design. If the KBS does not answer, no new confidential pod gets its key; those already started survive, but any rescheduling or scaling does not. The same dependency as the SPIRE server and the same treatment: real high availability, its own alert and rehearsed degradation.

Closing the series: the complete chain

Article 1/4 set the contract: what the endpoint exposes and what control plane governs it reproducibly. In 2/4 the subject was the provenance of the bytes: which registry they come from, by immutable digest and not by a moving tag. 3/4 added the cryptographic proof of what they are, with signatures, build attestations and an AIBOM verified at admission. This 4/4 closes with who runs them and where: an SVID that proves the serving process’s identity and an isolation rung chosen for the adversary you actually have. If one of the four fails, the other three are worth less than they look: an impeccably signed model served by an unidentified process on a machine a third party can dump is still a problem.

With a limited budget, the order follows cost per unit of risk removed. First, digests everywhere: almost free, and it removes a whole family of substitution attacks. Second, signature verified at admission, low cost and the first thing an auditor asks to see. Third, a declarative contract and control plane, which make everything else auditable. Fourth, workload identity with SPIFFE/SPIRE: expensive to operate, but it is the only thing that turns east-west traffic into something authorisable, and it becomes mandatory as soon as agents with MCP arrive. And last, the TEE, only if the infrastructure operator is in your threat model; Kata without a TEE can jump ahead to fourth place if there are tenants that do not trust each other.

Mapping the series to ENS, ISO/IEC 42001 and the EU AI Act

The detail is in technical controls ENS × ISO 42001 × EU AI Act; this table is the summary by link.

Art. 15(5) carries the most weight: it requires high-risk systems to be “resilient against attempts by unauthorised third parties to alter their use, outputs or performance”, and it enumerates data and model poisoning and confidentiality attacks. Links 3 and 4 are its technical implementation. For the management framework, see ISO/IEC 42001 as an AIMS and the AI Act mapping.

For an inference factory

Start workload identity with the gateway↔engine pair and with the agents, not with the whole cluster. Registering all forty workloads on day one is the most reliable way to abandon the project: register two entries, set up the Istio policy that requires the gateway’s principal and live with it for a couple of weeks to learn what breaks when the certificate rotates. Then the agents with MCP, where static credentials are the entire threat model.

Separate the Kata decision from the TEE decision, and take them in that order. Kata is a RuntimeClass change with a second of startup and some memory. CoCo is a redesign: you lose MIG and the GPU’s performance counters, you gain ten seconds or more of startup, you pay 15-25 % of capacity and you add two dependencies whose failure prevents workloads from starting. Evaluate the second with a written threat model, not with a slide.

If you go to CoCo, rehearse patch day before you need it. The failure that will take your inference down will not be an attack, it will be a firmware update that misaligns the RVPS reference values. Write the runbook (update the RVPS with overlap, patch, retire the old value), rehearse it on one node and monitor the attestation success rate as a first-class metric, just as for SPIRE: alert on attestation failures before they turn into 401s at the gateway.

That closes the series: from the contract to the artefact, from the artefact to its proof, and from the proof to the process and the machine. What lies below is no longer a chain of trust but daily operation: seeing what each process does with Tetragon and measuring whether what is served is still good with evals. Trust is established once; vigilance is continuous.

See also

• Model chain of trust (1/4): KServe and the Open Inference Protocol — the API contract that opens the series.
• Model chain of trust (2/4): registry and distribution with OCI and ORAS — why the digest is everything.
• Model chain of trust (3/4): signature, provenance and AIBOM — the proof that Sigstore selectors turn into a precondition of identity.
• MCP grows up: authentication with Keycloak — the user identity to compose with the workload one.
• Isolating AI agents: from workstation to cluster — the threat model that SPIFFE gives a non-transferable credential.
• Tetragon: runtime security — the vigilance that starts where the chain of trust ends.
• Infrastructure and regulatory compliance in defence — where the TEE stops being over-engineering.
• H100 cluster: multi-tenant platform — where MIG and confidential mode collide head-on.
• Keycloak in an AI platform — the other identity plane, the one for people, and where it overlaps with SPIFFE.
• Completing Keycloak for MCP — the authorisation of the tools an agent invokes, which neither SPIFFE nor the IdP solves.

Sources

• CNCF, SPIFFE and SPIRE Projects Graduate from CNCF Incubator (20 sep. 2022) — https://www.cncf.io/announcements/2022/09/20/spiffe-and-spire-projects-graduate-from-cloud-native-computing-foundation-incubator/
• SPIFFE, SPIFFE Concepts (SPIFFE ID, trust domain, SVID, Workload API) — https://spiffe.io/docs/latest/spiffe-about/spiffe-concepts/
• SPIFFE, SPIFFE Federation specification — https://spiffe.io/docs/latest/spiffe-specs/spiffe_federation/
• SPIFFE, Scaling SPIRE (dimensionamiento y punto único de fallo) — https://spiffe.io/docs/latest/planning/scaling_spire/
• spiffe/spire, Releases (v1.15.0 de 19 may. 2026; v1.15.1 de 28 may. 2026, parche de azure_imds) — https://github.com/spiffe/spire/releases
• spiffe/spire, Kubernetes Workload Attestor plugin (selectores, kubelet, cgroups, Sigstore) — https://github.com/spiffe/spire/blob/main/doc/plugin_agent_workloadattestor_k8s.md
• spiffe/spire, SPIRE Server configuration reference (default_x509_svid_ttl, default_jwt_svid_ttl, ca_ttl) — https://github.com/spiffe/spire/blob/main/doc/spire_server.md
• Istio, SPIRE integration (Envoy SDS, SPIFFE CSI Driver, trust domain) — https://istio.io/latest/docs/ops/integrations/spire/
• SPIFFE, OPA Authorization with Envoy and JWT-SVIDs — https://spiffe.io/docs/latest/microservices/envoy-jwt-opa/readme/
• The New Stack, How Cilium’s Mutual Authentication Can Compromise Security — https://thenewstack.io/how-ciliums-mutual-authentication-can-compromise-security/
• Riptides, Bringing SPIFFE to OAuth for MCP — https://riptides.io/blog/bringing-spiffe-to-oauth-for-mcp-secure-identity-for-agentic-workloads/
• CNCF, Confidential Containers becomes a CNCF incubating project (22 jul. 2026) — https://www.cncf.io/blog/2026/07/22/confidential-containers-becomes-a-cncf-incubating-project/
• Confidential Containers, Attestation with Trustee (KBS, AS, RVPS, CDH) — https://confidentialcontainers.org/docs/attestation/
• Confidential Containers, Deploy Trustee in Kubernetes (11 feb. 2026) — https://confidentialcontainers.org/blog/2026/02/11/deploy-trustee-in-kubernetes/
• confidential-containers/trustee, Releases (v0.20.0: TLS 1.3, PQC, multi-GPU ITA, NVSwitch) — https://github.com/confidential-containers/trustee/releases
• IETF, RFC 9334 — Remote ATtestation procedureS (RATS) Architecture — https://www.rfc-editor.org/info/rfc9334/
• Kata Containers, Kata Containers 4.0.0 Preview (28 abr. 2026, runtime-rs por defecto) — https://katacontainers.io/blog/release-4-0-0-preview/
• kata-containers, Release 3.32.0 — https://github.com/kata-containers/kata-containers/releases/tag/3.32.0
• NVIDIA, Deploy with Kata Containers — GPU Operator — https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/latest/deploy-kata-containers.html
• NVIDIA, Deploying Proprietary Models Securely with Confidential Computing on Self-Hosted Kubernetes (GA 1.0.0; MIG y vGPU prohibidos en CC) — https://docs.nvidia.com/enterprise-reference-architectures/deploying-proprietary-models-confidential-compute-self-hosted-kubernetes/latest/reference-implementations.html
• CACM, Creating the First Confidential GPUs (CPR, bounce buffers, contadores deshabilitados, HBM no cifrada) — https://cacm.acm.org/practice/creating-the-first-confidential-gpus/
• NVIDIA, Confidential Computing on H100 GPUs for Secure and Trustworthy AI (límite de ~4 GB/s, NRAS) — https://developer.nvidia.com/blog/confidential-computing-on-h100-gpus-for-secure-and-trustworthy-ai/
• NVIDIA, Hardware-Rooted AI Security That Won’t Slow You Down (2 jul. 2026; Blackwell, NVLink cifrado hasta 8 GPU) — https://developer.nvidia.com/blog/hardware-rooted-ai-security-that-wont-slow-you-down
• Corvex, Confidential Computing Meets NVIDIA HGX B200 (claim comercial) — https://www.corvex.ai/blog/confidential-computing-meets-nvidia-hgxtm-b200-secure-ai-without-the-performance-trade-off
• arXiv 2409.03992, Confidential Computing on NVIDIA Hopper GPUs: A Performance Benchmark Study — https://arxiv.org/html/2409.03992v1
• arXiv 2509.18886, Confidential LLM Inference: Performance and Cost Across CPU and GPU TEEs (23 sep. 2025) — https://arxiv.org/abs/2509.18886
• arXiv 2607.19353, Benchmarking Confidential GPU Inference on NVIDIA H100 under Intel TDX (may. 2026; heurística del 15-25 %) — https://arxiv.org/html/2607.19353
• Segarra et al., Serverless Confidential Containers: Challenges and Opportunities (SESAME'24) — https://carlossegarra.com/assets/papers/sesame24-serverlesscoco.pdf
• EU Artificial Intelligence Act, Article 15: Accuracy, Robustness and Cybersecurity — https://artificialintelligenceact.eu/article/15/
• EU Artificial Intelligence Act, Article 12: Record-Keeping — https://artificialintelligenceact.eu/article/12/