Mythos-class models have made sophisticated vulnerability discovery and exploit development cheaper, faster, and easier to scale. Organisations should assume that weaknesses in widely deployed software will be found and exploited quickly, making rigorous defence in depth a baseline for critical workloads.
Confidential computing should be part of that baseline. Hardware-backed trusted execution environments isolate workloads from hosts and infrastructure administrators, while remote attestation and reproducible builds can make supply-chain compromise, workload substitution, host compromise, and unauthorised access to data or secrets detectable or less damaging. The precise guarantees depend on the TEE and deployment architecture.
Caution packages these protections into a practical platform: workloads run inside secure enclaves, traffic can remain encrypted until it reaches the enclave, and fresh hardware-backed attestations can be verified against deterministic builds from source. Caution reproducibly builds the toolchain, platform, operating system, and application when the application and its inputs are reproducible. For critical systems, omitting comparable protections should require an explicit security justification.
Table of contents
Post-Mythos security changes the infrastructure threat model
Anthropic describes Claude Mythos Preview as a pivotal moment for cybersecurity. In testing, Mythos developed exploit primitives, combined them into end-to-end attack chains, and found and exploited vulnerabilities across major operating systems and browsers. Engineers without formal security training were able to ask it to find remote code execution vulnerabilities overnight and return to working exploits.
The permanent shift in what this means for securing systems is significant. Expertise, funds and time once constrained sophisticated attacks; organisations can no longer treat that scarcity as an implicit security control. The cost of some forms of vulnerability discovery and exploit development is falling sharply, and as the cost of tokens for LLM usage becomes even lower, the problem will be exacerbated.
There is also an emerging asymmetry in who has access to these capabilities. OpenAI limits access to GPT-5.5-Cyber through Daybreak to verified defenders, while Anthropic limits Mythos 5 to a small group of vetted partners. At the same time, increasingly capable open-weight models are becoming broadly available. Moonshot’s Kimi K3 is a recent example, with publicly released model weights and strong capabilities across coding, reasoning, and agentic tasks. An adversary can self-host and adapt an open-weight model without depending on continued access from a model provider that’s gating capabilities. Defenders that rely on gated frontier models may not have equivalent access. As open-weight models continue to improve, organisations should assume that sophisticated offensive capabilities will diffuse broadly, regardless of whether the most capable proprietary systems remain restricted. Defenders should make sure they have access to capable models too, including open-weight models where appropriate.
Defenders gain powerful tools too. Models can accelerate code review, triage, patch development, and migration away from unsafe components. But an attacker needs one exploitable path, while a defender must protect the whole system and deploy every fix. Post-Mythos security therefore has to combine faster defensive work with infrastructure designed so that compromise of one layer does not automatically compromise the entire system.
Traditional security controls remain essential, but cannot by themselves protect a workload when a vulnerability is exploited before a fix exists, a build or deployment system substitutes different code, or a compromised host, privileged administrator, or cloud operator gains access to a workload’s memory and credentials.
Software supply chain security has to cover the full path from source and build tools to the platform, operating system, deployment, and live runtime. Policies, access controls, software bills of materials, scanners, and signed artefacts all help, but none independently proves that a remote service is isolated from its operator or matches inspectable source.
For low-impact services, organisations may accept that gap. For systems that hold signing keys, process sensitive data, control customer assets, or give AI agents production credentials, isolation and independent verification should be the default, not capabilities omitted because they were too difficult to deploy.
Confidential computing should be a security baseline
Confidential computing protects data in use by running software inside a hardware-backed trusted execution environment, or TEE. The TEE creates a boundary that the surrounding host cannot ordinarily inspect or modify, even with administrator access. Depending on the hardware and deployment model, it can reduce the trust placed in the host operating system, hypervisor, cloud operator, and other surrounding infrastructure.
That boundary addresses several important attack classes:
- Host, administrator, and cloud operator compromise. Access to the surrounding infrastructure does not automatically grant access to memory, code, data, or keys inside the protected workload.
- Data-in-use and secret exposure. Sensitive data is processed inside hardware-isolated memory, and credentials can be released only to an approved environment.
- Workload substitution. Remote attestation supplies signed measurements that verifiers and key-management policies can compare with an approved identity.
- Infrastructure-level lateral movement. A compromised host does not have to expose every sensitive workload protected by a hardware isolation boundary.
Major cloud platforms and standards bodies increasingly treat confidential computing and remote attestation as core cloud security components. Continuing to place high-value workloads directly inside infrastructure that administrators or compromised hosts can inspect is an avoidable concentration of risk. This is especially important for AI agents, which execute generated code, process untrusted inputs, and often hold powerful credentials. Confidential computing can add a hardware-enforced boundary around an agent and its secrets as well as components surrounding it. Of course, this does not replace application sandboxing, least privilege, capability restrictions, or network controls.
Confidential computing does not prove that application logic is correct or prevent every side channel, denial-of-service attack, or vulnerability inside the protected workload. It changes the trust boundary and can prevent a failure elsewhere in the infrastructure from automatically exposing a critical workload.
From remote attestation to verifiable compute
Isolation answers whether the surrounding infrastructure can read or alter a workload. Remote attestation uses hardware-backed cryptography to provide signed evidence about the measured software environment running on a server.
A code measurement is only a hash. If a verifier cannot reproduce it from auditable source, the attested image remains an opaque binary. Attestation alone does not establish the provenance of the compiler, operating system, libraries, platform services, and application inside the image.
Verifiable compute closes that gap by connecting the live hardware measurement to the source and build process that produced it. Doing this properly requires more than a reproducible application: the toolchain, platform, and operating system are part of the trusted computing base too.
Caution supplies both layers. It deploys hardware-isolated workloads with remote attestation and support for end-to-end encrypted application traffic that terminates inside of the TEE. Its build process uses StageX, a toolchain built through a full-source bootstrap, combines the application with a minimal EnclaveOS environment, and produces a deterministic enclave image.
For a reproducible deployment, verification then follows a simple path:
- Caution reproducibly builds the platform, operating system, and application and runs the result inside a secure enclave.
- The live workload returns a fresh, hardware-signed attestation containing its measurement.
- A verifier rebuilds the environment from source and compares the expected measurement with the live one. Alternatively, the verifier uses separately approved expected measurements.
- A match provides cryptographic evidence that the isolated runtime was launched from the measured image built from the source and configuration that were reviewed.
For network services, the request, encrypted channel, or secret release must also be bound to the attested enclave so that a valid attestation cannot be presented while traffic is routed to a different workload.
Source-to-runtime software supply chain security
Connecting source to an isolated runtime makes deployment integrity measurable:
- Security teams can verify that a reviewed release, rather than a stale or substituted image, is serving production traffic.
- Unauthorised changes to measured code or configuration produce a different result and fail verification.
- Customers, auditors, and partners can verify a deployment without relying only on policies, screenshots, or a vendor-controlled dashboard.
Reproducibility does not prove that the source is vulnerability-free; compromised source will reproduce compromised software. Its value is concrete: unauthorised changes can no longer hide in an opaque build or deployment process, while confidential computing protects the verified workload from its host.
A responsible adoption path
Not every service has the same risk, and an entire estate need not move at once. Start where host access, silent code changes, or supply chain compromise would have the highest cost:
- Signing, authorisation, custody, and payment services
- AI agents with production credentials or authority to take external actions or access sensitive data
- Inference endpoints processing private or regulated data
- Identity, key-management, and secret-handling systems
- Software build, verification, and release infrastructure
- Systems managing confidential and sensitive data
For those systems, architecture reviews should ask whether data is protected while in use, whether administrators can access it, whether secrets are released only to approved workloads, whether the measured software environment can be reproduced from source, and whether production matches that approved build.
Caution integrates these controls into a practical deployment workflow, so teams can adopt verifiable compute without assembling a specialist confidential-computing team or replacing every CI/CD and change-management process.
Point-in-time verification should ultimately become continuous attestation monitoring. We have built Canary to request fresh attestations on an ongoing basis, compare them with approved reproducible releases, and alert when a deployment changes, becomes unverifiable, or stops responding.
The burden of justification has shifted
As exploitation becomes cheaper and more scalable, security architectures can no longer depend on every layer of the infrastructure remaining uncompromised. Critical services need smaller trust boundaries, hardware isolation, and independently verifiable deployments.
Confidential computing provides the isolation and remote attestation. Caution makes those protections practical to use and completes the chain with a reproducible, full-source build process. In the post-Mythos era, enterprises should have to explain why their most critical workloads are safe without these protections, not why they need them.
Supply-chain attacks such as SolarWinds could have been detected—and prevented from reaching customers if reproducible verification had been enforced as a release gate.
If you are evaluating confidential computing, software supply chain security, or verifiable infrastructure for critical workloads, talk to a Caution engineer for a free consultation.
