The strategic cases have been made, the legal liabilities mapped, and the 24-hour reporting stopwatches calibrated. If you have followed this series from Part 1’s AISVS-to-GATE map through Part 5’s CRA reporting clock, you know the thesis by heart: the model is not the product; the runtime is the product. The work is in the wiring.
Strategy without syntax is an executive slide deck. Part 6 closes the series by moving from abstract primitives to a concrete, production-ready reference architecture: a hardened deployment pattern built to satisfy the EU Cyber Resilience Act (CRA) and the AI Act at the same time. Where Part 4 established the engineering substrate for AI Act Article 15 cybersecurity, this instalment shows the runtime that satisfies CRA Annex I on the same physical footprint.
The operational stack has three moving parts and one decision. We use Enclave as the infrastructure-as-code (IaC) substrate, an agent runtime container running inside a VM-level Trusted Execution Environment (TEE) to execute the agent loops, and a dual enforcement tier you choose based on your footprint: Apigee for enterprise API management, or Envoy Proxy for a fully open-source deployment.
The Architectural Target
To meet CRA Article 14 vulnerability and incident reporting obligations from 11 September 2026 and CRA Article 13 manufacturer obligations against Annex I, including the conformity assessment procedures specified in Article 32, from 11 December 2027, an agentic platform cannot lean on defensive prompt configuration. The runtime has to enforce a zero-trust topology on two fronts at once: it must produce continuous cryptographic evidence of its own code integrity (the AI-BOM), and it must intercept and validate every side effect at kernel speed.
The blueprint below does this by enforcing a hard separation between the probabilistic execution zone and the deterministic network perimeter. The model proposes. The runtime disposes. Nothing crosses the boundary without an evidenced decision.
1. The Substrate: Enclave-Bound IaC
The foundation of the architecture is the complete denial of host-level privilege. If a hypervisor administrator or a compromised cloud utility can read the memory of your running agent, the system fails the CRA’s essential confidentiality requirements (European Parliament and Council, 2024a, Annex I). We use Enclave as the declarative IaC substrate to build and provision confidential virtual machines.
Hardware isolation. Enclave bootstraps the system directly into a VM-level Trusted Execution Environment, either Intel TDX or AMD SEV-SNP. All data-in-use, transient model weights, and prompt contexts in RAM are encrypted with hardware-managed keys, rendering memory opaque to the host node.
Attestation at boot. During boot, Enclave measures the cryptographically signed base image, the kernel components, and the init-system state, and generates a hardware-backed attestation report. If any file has been modified or an unvetted package introduced, attestation fails, the workload is denied its decryption tokens, and the runtime halts before it ever enters service. This is how you automate GATE Control C03 (Runtime Integrity Attestation). The same VM-level TEE pattern Part 4 introduced for AI Act Article 15 confidentiality is what satisfies the CRA’s Annex I confidentiality and integrity requirements here. A workload that cannot attest does not boot.
2. The Execution Zone: The Agent Runtime Inside the TEE
Inside the confidential VM sits the agent runtime container. This holds the agentic application logic, whether built on LangChain, AutoGen, or raw Python, alongside an ephemeral SPIFFE/SPIRE workload agent.
Non-Human Identity (NHI). The runtime stores no static API keys and no long-lived database credentials. The local SPIFFE agent, via a TEE-aware node attestor, interacts with the TEE’s hardware attestation layer to fetch short-TTL, cryptographically signed X.509-SVIDs. Identity is minted from a measured boot state and expires in minutes, not months. A long-lived secret is a breach with a delay timer.
The tool-intercept invariant. The runtime is configured so the agent application has no direct route to the external network interface. It is bound to a loopback interface that talks exclusively to the local GATE proxy. When the model emits a tool call, the request is forced across that boundary; the local proxy appends the active SPIFFE token and forwards the envelope out of the TEE toward the enterprise API tier.
3. The Enforcement Tier: Choosing Your Gateway
The local proxy routes the payload to your Tool Gateway, the point where written legal policy becomes a real-time operational perimeter. To stay true to the open, vendor-neutral spirit of the GATE specification, the architecture supports two gateway configurations.
Option A: The Enterprise Path (Apigee)
For organisations already embedded in corporate API management, Apigee serves as a turnkey enforcement barrier. It terminates mutual TLS (mTLS), extracts the workload’s SPIFFE identity from the client certificate, and checks it against the active attestation registry. It then applies a JSON Threat Protection policy to cap structural complexity (array element counts, containment depth, and string lengths), defeating the parser-exhaustion and content-level denial-of-service class, and an OASValidation policy to enforce schema conformance against your OpenAPI contract. Malformed tool arguments are rejected before they reach backend services. Schema validation rejects the malformed; the policy engine, below, authorises the action.
Option B: The Open Source Path (Envoy Proxy)
For teams running a fully open-source substrate, Envoy Proxy is the functional equivalent inside the GATE pattern.
Native SPIFFE via SDS. Envoy’s dynamic configuration uses the Secret Discovery Service (SDS) to retrieve and rotate TLS material straight from a running SPIRE Agent, which acts as the SDS provider. Incoming SPIFFE identities are validated at the edge from the URI field of the X-Forwarded-Client-Cert header.
The ext_authz hook. Envoy runs decoupled Policy-as-Code through its built-in External Authorization filter. Before a single byte reaches a tool, Envoy halts the request and calls out to an external policy decision point via ext_authz. Open Policy Agent integrates natively over gRPC through the opa-envoy-plugin, which implements Envoy’s external authorization API directly. Cedar deployments typically front cedar-agent over HTTP. Either way, an unauthorised call returns a 403 at the proxy.
WASM schema validation. Structural validation runs inside Envoy’s worker threads via custom WebAssembly (WASM) filters. Compiling a JSON Schema engine into a WASM module strips free-form text vulnerabilities out of tool-argument inputs at line speed.
| Strategic prerequisite | Enterprise tier (Apigee) | Open-source tier (Envoy Proxy) |
|---|---|---|
| Identity termination | Native mTLS termination; SPIFFE ID extracted from client cert | Native SPIFFE/SPIRE SDS integration |
| Decoupled Policy-as-Code | External policy via extension / target callout | Native ext_authz gRPC filter hook to OPA / Cedar |
| Structural schema validation | JSON Threat Protection + OASValidation policies | Custom compiled WASM filter chain |
| Compliance telemetry | Integrated analytics portal | Native OpenTelemetry (OTel) export |
4. The Vulnerability Validation Loop
To satisfy the CRA’s vulnerability-handling mandate, the architecture needs an active, continuous feedback loop between the deployment pipeline and the live gateways. You cannot wait for a quarterly penetration test to discover an unpatched package buried in your agent’s dependencies. We treat the AI-BOM as code.
- Continuous scan: Every CI/CD run runs static analysis across the agent runtime container layers, the Python dependencies, and the model-wrapper manifests.
- Attestation generation: The pipeline emits an updated, machine-readable SBOM and signs it, producing a verifiable attestation package.
- Gateway sync: When an upstream library is flagged with an active CVE (for example, an exploitation vector found in an open-source MCP server), the pipeline immediately pushes updated OPA policy bundles to the Apigee cluster or the Envoy fleet.
- Live revocation: The gateway dynamically imports the new policy state. The next time that agent instance tries to invoke a tool, the gateway blocks the request on the package hash, revoking the agent’s privilege in real time until the patch ships.
This is the runtime answer to Part 5’s 24-hour reporting clock: the gap between “CVE disclosed” and “exposure contained” collapses from a sprint cycle to a config push. The GATE conformance runner described in “The GATE Conformance Runner: What You Can Automate and What You Cannot” is the CI-time half of this loop; the gateway sync is the runtime half. Our Managed Services team operates this loop for clients who would rather consume the outcome than staff the rotation.
5. Host-Level Containment: Kernel-Speed eBPF
What happens if an attacker achieves full remote code execution inside the agent runtime container through an unmapped zero-day, bypassing the local proxy entirely?
To stop the agent from opening a reverse shell or exfiltrating data to a command-and-control server, we add host-level eBPF (Extended Berkeley Packet Filter) egress containment. Operating inside the Linux kernel on the host, the eBPF filter inspects every outbound packet leaving the TEE’s virtual network interface and evaluates the destination against a strict allow-list synchronised directly with your IaC definitions.
If the agent tries to reach an endpoint or IP that is not explicitly registered in the active IaC manifest, the filter drops the packet in the kernel. The network boundary does not depend on application configuration; it is enforced beneath it. The allow-list is the perimeter, and it is version-controlled.
The Core Invariant Realised
When this reference architecture is deployed, compliant, hash-chained evidence falls out as a structural by-product of routing data.
If a market surveillance authority opens an inquiry under the CRA or the AI Act, your operations team does not assemble a historical narrative or grep through mutable text. Every tool proposal, validation path, policy evaluation, and host egress decision has already been cryptographically bound to a unique request_hash and committed to a Write-Once-Read-Many (WORM) ledger. A report is an assertion. A hash chain is a proof.
The Sakura Position
We have travelled from high-level compliance gaps down to kernel-level filter configuration. The regulatory landscape of 2026 and 2027 has drawn a clear line: the era of the ungoverned prototype is over. You cannot protect a probabilistic system with a deterministic checklist, and you cannot secure an autonomous agent with a system prompt.
For the engineering leaders who have to build this, the pattern reduces to three invariants:
Boot into attestation, not into trust. Provision the runtime from signed, measured images inside a VM-level TEE. A workload that cannot prove its own integrity at boot is denied its keys and never enters service.
Intercept every side effect. Strip the agent of direct network and credential access. Route every tool call through a gateway that validates schema and authorises the action with decoupled Policy-as-Code, and backstop it with eBPF egress containment at the kernel.
Make evidence a by-product, not a project. Bind every decision to a request hash and commit it to a WORM ledger as it happens. Conformance is then a query, not a fire drill.
The firms that scale safely will treat verification as an infrastructure constraint, not a compliance afterthought. Our Sentinel framework operationalises this pattern for AI and data security; our Praxis solution turns its evidence into regulator-ready packs against the regimes our GRC service supports. The control-to-regulation map that ties this together was set out in Part 1: AISVS Has 14 Categories. GATE Has 16 Controls. and the boardroom investment case in Part 2: Why the Boardroom Should Be Funding the Verification Layer in 2026.
Architecture is the dominant perimeter. Build it right. The work is in the wiring.
If your platform teams are ready to implement this reference architecture, an Accelerate engagement is the focused sprint that puts a production-grade slice into your environment, jointly built with your engineers. If you need senior cloud, data, or security engineers embedded in your roadmap for the long term, Professional Services is the path. And if you need someone to wrap existing agentic workloads in a conformant GATE control plane before the September 2026 and December 2027 deadlines, get in touch. The complete configuration manifests and schema definitions ship with our Trustworthy Agentic AI Blueprint and the GATE white paper.
Disclosure: The author is a lifetime member of the OWASP Foundation. This article reflects an independent reading of public OWASP material and does not represent the views of the Foundation.
Disclosure: Sakura Sky implements the Governed Agent Trust Environment (GATE) in client engagements. GATE is an open framework, published under CC BY 4.0 at deterministicagents.ai, and is vendor-neutral. The framework was authored by Andrew Stevens; readers should weight the GATE references in this article accordingly. The Trustworthy Agentic AI Blueprint cited here is likewise Sakura Sky and Stevens work, and the same weighting applies. Enclave, Sentinel, Praxis, and the service lines referenced (GRC, Managed Services, Accelerate, Professional Services) are Sakura Sky offerings.
Not legal advice. This article offers general commentary on the EU Cyber Resilience Act (CRA) and the AI Act for an engineering and platform audience. It is not legal advice and is not a substitute for counsel. Readers must obtain independent legal advice on how these regulations apply to their specific products and commercial operations.
References
European Parliament and Council, 2024a. Regulation (EU) 2024/2847 of the European Parliament and of the Council of 23 October 2024 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act). Official Journal of the European Union, L 2024/2847, 20 November. Available at: https://eur-lex.europa.eu/eli/reg/2024/2847/oj [Accessed 18 June 2026].
European Parliament and Council, 2024b. Regulation (EU) 2024/1689 of the European Parliament and of the Council of 13 June 2024 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). Official Journal of the European Union, L 2024/1689, 12 July. Available at: https://eur-lex.europa.eu/eli/reg/2024/1689/oj [Accessed 18 June 2026].
Sakura Sky and Stevens, A., 2026. The Trustworthy Agentic AI Blueprint: 16 Missing Primitives for Enterprise Autonomy, Version 1.0.4. Available at: https://www.sakurasky.com/white-papers/trustworthy-agentic-ai-blueprint/ [Accessed 18 June 2026].
Stevens, A., 2026. GATE: Governed Agent Trust Environment, Version 1.3 framework paper. Deterministic Agents. Available at: https://deterministicagents.ai [Accessed 18 June 2026].