For twenty years we trusted software a particular way. You wrote code, you checked it against your policies, and once it passed you shipped it knowing it would behave. The code was deterministic. Check it once, trust it for good. That model held because the thing you were reasoning about stayed still. Agents move. An agent reasons, decides, and acts while it runs, and it makes those calls across whatever tools and data you connected it to. That movement is the reason an agent is worth having. It is also the reason the old trust model needs a partner. You can review the agent's code as carefully as you like. What review cannot tell you is what decision the agent will make three tool calls from now, against a customer record it just pulled. So a fair question sits in front of every team adopting agents: when an agent touches your most sensitive systems, how do you prove what it actually did? We work alongside teams in regulated and high-stakes environments who live with that question every day, and the good news is the answer already exists in hardware most of you are already paying for. Here is how it works and how to put it to use this week.
A promise and a proof
Software guardrails give you a promise. You prompt the agent to stay in its lane, you wrap it in policy checks, and most of the time it complies. For many workloads, most of the time is a perfectly reasonable bar. In a room with an auditor, a promise is a harder thing to stand behind, and it asks more of you as you grow from one agent to a fleet, each one carrying its own surface where context can travel somewhere you did not intend. A Trusted Execution Environment gives you a proof to hold alongside the promise. A TEE is a hardware-isolated region of a CPU or GPU with an encryption key set into the silicon at the factory. Two capabilities come out of that key. The first is the one most people picture: an encrypted runtime. Your workload runs on data while it stays encrypted in memory, so a privileged process on the host that dumps memory sees only ciphertext. That is genuinely useful, it is table stakes, and on its own it leaves the agent question open. The second capability is the one that answers the question, and it is called attestation. That same factory key cryptographically signs a measurement of exactly what loaded into the enclave: which container image, which configuration, which policies. A remote party verifies that signature before it sends any data. Now you are holding a proof of what ran, where it ran, and under which rules. The report your auditor asks for becomes a natural product of how the system is built, ready whenever you need it.
Three steps you can take with what you already run
This is closer to hand than most teams expect, especially on a hyperscaler you are already using.
Step one: run inside an encrypted enclave. On Google Cloud this is a single flag at instance creation. AMD SEV-SNP runs on the N2D family, Intel TDX runs on C3, and you turn it on with --confidential-compute-type=SEV_SNP. It looks like this:
gcloud compute instances create vektor-enclave \
--machine-type=n2d-standard-2 \
--min-cpu-platform="AMD Milan" \
--confidential-compute-type=SEV_SNP \
--maintenance-policy=TERMINATE \
--zone=us-central1-a
Your code runs as written and memory is encrypted in hardware. This step gives you the encrypted runtime and stops there, so think of it as the floor you build on. Step two: gate your data behind attestation. This is the step that earns its keep. Package your workload as a container, run it inside the TEE, and let the hardware issue a signed attestation token describing precisely what image loaded. Then bind a resource, a key or a secret or a storage bucket, to a policy that releases it only to a workload whose attestation matches that exact image in that exact project. The data stays mathematically out of reach until the workload you authorized is the one asking for it. Access control becomes a gate the silicon enforces for you. On Google Cloud this is Confidential Space, and it is generally available today on the Intel TDX machine families. Step three: bring the enclave to the GPU. When the sensitive thing is a model or its weights, you extend the boundary to the GPU itself. On Google Cloud that is the A3 family with an H100 in confidential mode. The weights decrypt only inside an attested enclave you control, which speaks directly to a question many regulated teams are weighing right now about whether sensitive model weights can run in places they do not fully own. A few field notes so the work goes smoothly. The SEV-SNP attestation report format recently moved to version four, so set your parser library to match. Pin your guest images on purpose, since both SEV-SNP and TDX have shipped firmware advisories this year. And the confidential-GPU options are still limited and priced accordingly, so prove out the CPU attestation path first and reach for the GPU step when you have weights or inference that truly call for it.
Two strong roads, and the teams that travel both
There is a real engineering conversation here, and both sides are holding something valuable. One approach puts the enforcement in hardware, for the reasons above. The other approach offers an idea we admire: have the agent generate deterministic procedural code while it runs, then check that generated code against your policies the same way we have always checked code. It carries the agent's output back into the world where the original trust model works beautifully. We think the strongest teams will travel both roads together. The agent still reasons over sensitive systems to decide what procedural code to write, and the checker itself may be agent-assisted. Wrap both inside an attested enclave and you get the clarity of deterministic checking together with a cryptographic proof of the whole pipeline. That combination is where the most durable systems are going to live.
Why this clears the runway
It is tempting to file confidential computing under compliance cost. We read it as a way forward. The teams we meet who feel stuck are often stuck inside long audit cycles, working to convince internal and external reviewers that an agent will behave. Attestation turns that conversation into a signature a reviewer can verify in minutes. This trust upgrade is what lets you connect agents to the high-value, sensitive data that has been off the table, and that data is exactly where the meaningful work waits. We have done this once already. Moving to the internet, we upgraded the trust layer and encrypted data in transit, and that upgrade is what made the whole thing safe to build on. Agents are asking for the same upgrade at runtime. The teams that make it early earn the right to build in rooms others are still waiting to enter. A simple starting point: stand up a Confidential Space environment and bind one key to one attested image. Watch the key hold firm against everything except the workload you signed, and the rest of the model settles into place quickly. That is the work we care about at KITSCo. We advocate for your security posture, we integrate this into the stack you already run, and we leave your builders empowered to ship into rooms that used to be closed. Advocate. Integrate. Empower.