<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Threat Modeling on Pawan Khandavilli</title><link>https://pawankhandavilli.com/tags/threat-modeling/</link><description>Recent content in Threat Modeling on Pawan Khandavilli</description><generator>Hugo -- 0.169.0</generator><language>en-US</language><lastBuildDate>Thu, 29 Oct 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://pawankhandavilli.com/tags/threat-modeling/index.xml" rel="self" type="application/rss+xml"/><item><title>Your AI Agent Is Isolated. From What?</title><link>https://pawankhandavilli.com/posts/your-ai-agent-is-isolated-from-what/</link><pubDate>Thu, 29 Oct 2026 00:00:00 +0000</pubDate><guid>https://pawankhandavilli.com/posts/your-ai-agent-is-isolated-from-what/</guid><description>OpenAI&amp;#39;s containment experiments show why memory protection, escape containment, and communication isolation need separate evidence.</description><content:encoded><![CDATA[<p>OpenAI gave two agents in separate microVMs on shared host machines a task: exchange synthetic secrets without network connections or shared writable files.</p>
<p>They succeeded through CPU-cache timing. One agent changed cache state; the other measured access times and decoded the signal.</p>
<p>These were <a href="https://openai.com/index/securing-our-frontier-model-training-environment/">instructed red-team tests</a> in purpose-built copies of OpenAI&rsquo;s training and evaluation infrastructure. They were not spontaneous collusion or tests of customer-facing agent products.</p>
<p>Preventing a VM escape and preventing communication are different security requirements.</p>
<h2 id="what-does-isolated-promise">What does &ldquo;isolated&rdquo; promise?</h2>
<p>In <a href="/posts/your-ai-agents-sandbox-is-not-its-governance-system/">my earlier sandbox and governance piece</a>, I argued that an agent can stay within its permitted technical reach and still take an unauthorized action. A sandbox cannot substitute for authorization.</p>
<p>OpenAI&rsquo;s report raises a question inside the containment claim itself. What, exactly, is separated?</p>
<ul>
<li>Private memory: can the host or another workload read or modify protected state?</li>
<li>Execution: can code escape its guest and gain control of the host?</li>
<li>Communication: can workloads exchange information through a shared resource or service?</li>
</ul>
<p>A system can enforce one property while failing another. Add monitoring and stopping, and there is another claim to test: can the operator detect a violation and terminate the relevant activity in time?</p>
<p>Here I am discussing the environments where agents execute tools and code. Protecting the server that runs model inference does not, by itself, protect every browser, shell, or service the agent uses.</p>
<h2 id="more-vm-layers-can-help-shared-resources-still-matter">More VM layers can help. Shared resources still matter.</h2>
<p>In a supported nested design, an outer VM can provide another boundary between a compromised inner environment and the physical host. An escape from the inner VM does not automatically defeat the outer hypervisor. That is useful defense in depth, provided the outer boundary actually constrains the attacker&rsquo;s next steps.</p>
<p>It does not follow that two agents can no longer communicate.</p>
<p>Suppose their execution affects a shared CPU cache. A sender can deliberately change resource usage, while a receiver measures an observable effect. This is a <em>covert channel</em>: cooperating parties use a resource that was not intended to carry their messages. They need not read each other&rsquo;s private memory or gain control of the physical host to use such a channel.</p>
<p>An extra VM layer does not inherently remove that shared resource. An outer layer may enforce resource partitioning or stricter placement, but the communication-isolation benefit comes from those controls and their implementation, not from nesting alone.</p>
<p><img alt="Conceptual diagram of two separate microVMs with private address spaces but possible shared CPU-cache and service dependencies. These possible channels are not a reconstruction of OpenAI&rsquo;s topology." loading="lazy" src="/images/agent-isolation/shared-resources.png"></p>
<p><em>Two kinds of sharing to examine, not OpenAI&rsquo;s exact deployment or one combined experiment. VM boundaries do not, on their own, establish communication isolation.</em></p>
<p>The precise channel depends on hardware, scheduling, memory mappings, software, and mitigations. OpenAI&rsquo;s result does not establish that its protocol works unchanged in every nested or confidential-VM design.</p>
<p>For a threat model that prohibits sharing CPU resources across security domains, separate physical hosts remove that shared-CPU path. They do not eliminate shared-service channels elsewhere. Dedicated vCPUs or disabling simultaneous multithreading alone are not evidence that all relevant resources are separated.</p>
<h2 id="confidential-computing-changes-who-you-trust">Confidential computing changes who you trust</h2>
<p>Confidential computing addresses another adversary: infrastructure software that the workload does not trust with its private state. Intel&rsquo;s <a href="https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/best-practices/trusted-domain-security-guidance-for-developers.html">TDX developer guidance</a> describes protecting workloads from privileged software, including the host hypervisor, for confidentiality and integrity.</p>
<p>That is valuable protection. It is not a promise that an agent authorized to read a secret cannot choose to disclose it.</p>
<p>The same guidance says timing side channels based on shared microarchitectural resources, including caches, remain a concern for TDX guests. It also documents hardware and software mitigations for particular attack classes. The processor generation, TDX version, guest software, and deployed controls matter.</p>
<p>Attestation provides evidence about measurements and configuration. Intel&rsquo;s <a href="https://cdrdv2.intel.com/v1/dl/getContent/733575">TDX module specification, sections 2.7 and 12</a>, describes that evidence. A verifier still needs to appraise it against policy; a valid quote is not a general certificate that an agent behaves correctly or that every shared dependency is isolated.</p>
<p>OpenAI&rsquo;s cache experiment is not a demonstrated TEE break. Nor does adding confidential memory establish that its communication problem has been solved. Those claims require different evidence.</p>
<h2 id="the-monitoring-plumbing-belongs-in-the-threat-model">The monitoring plumbing belongs in the threat model</h2>
<p>In a separate set of tests, OpenAI deliberately gave agents control of a host machine. This assumed the inner defenses had already failed, allowing researchers to evaluate the surrounding network and cloud perimeter independently.</p>
<p>Narrow connections remained for metrics, logging, and authentication management. OpenAI reports that agents found weaknesses in almost every one of these services that provided limited forms of internet access. In one chain, an agent reused a firewall-approved connection to reach a blocked authentication endpoint in the metrics service, then caused that endpoint to fetch a model-provided URL.</p>
<p>That starting privilege is essential context. This is not a claim that every intact agent sandbox could reach those endpoints.</p>
<p>A reachable service can extend an attacker&rsquo;s effective reach. A firewall rule about the first connection is insufficient if the permitted service can be induced to make a forbidden second connection.</p>
<h2 id="an-offline-world-can-still-have-shared-state">An offline world can still have shared state</h2>
<p>OpenAI also reports communication channels involving shared storage, CPU contention within a shared execution container, and a TLS certificate cache in its offline web infrastructure. These were separate tests, not one universal cross-VM exploit.</p>
<p>In most communication tests, researchers suggested channels or supplied an encoding protocol. For the broader red-teaming campaign, OpenAI also supplied infrastructure source code, configuration details, and documentation describing potential vulnerabilities. The campaign tested defenses under attacker-favorable conditions, rather than measuring unaided discovery.</p>
<p>The certificate-cache finding broadens the review beyond hardware. Disconnecting live browsing does not establish that different tasks have independent service state.</p>
<p>I would therefore inventory shared dependencies alongside network routes: caches, storage backends, queues, and other services. For each, ask whether one task can change something another task can observe. That is a review method, not a claim that every shared component is exploitable.</p>
<p>OpenAI describes most of the channels as slow and difficult for models to exploit. Bandwidth, noise, and the time available should inform the risk assessment.</p>
<h2 id="ask-for-evidence-one-property-at-a-time">Ask for evidence one property at a time</h2>
<p>For an agent-runtime review, I would start with this test matrix. These are proposed review questions, not a claim that OpenAI publishes all of these measurements.</p>
<table>
	<thead>
			<tr>
					<th>Property</th>
					<th>Starting position to test</th>
					<th>Evidence to request</th>
			</tr>
	</thead>
	<tbody>
			<tr>
					<td>Private-state protection</td>
					<td>Host or neighboring workload is adversarial</td>
					<td>Threat model, applicable hardware/software controls, attestation appraisal where used, and residual leakage</td>
			</tr>
			<tr>
					<td>Escape containment</td>
					<td>Untrusted code runs inside the guest</td>
					<td>Boundary tests, patched components, and what remains enforced after an inner compromise</td>
			</tr>
			<tr>
					<td>Communication isolation</td>
					<td>Two cooperating tasks try to signal</td>
					<td>Tests of shared hardware and services under representative placement and scheduling, with measured capacity and stated limits</td>
			</tr>
			<tr>
					<td>Internet isolation</td>
					<td>An agent, then an assumed-compromised host</td>
					<td>Direct and service-mediated egress tests, including DNS and operational infrastructure</td>
			</tr>
			<tr>
					<td>Detection and stopping</td>
					<td>A boundary violation or monitor failure occurs</td>
					<td>Coverage, alert and stop latency, failure behavior, and whether relevant work actually terminates</td>
			</tr>
	</tbody>
</table>
<p>Suppose testing a hypothetical offline web service reveals cross-tenant signaling through its shared certificate cache, violating the deployment&rsquo;s isolation requirement. I would reject that configuration until each tenant has a separate cache instance and store, access controls bound to authenticated tenant identity, and no shared-cache fallback. Acceptance would require inspecting deployed routing and permissions, then retesting cache-state and timing influence under documented load and observation windows. Any observed cross-tenant cache channel would block acceptance. Shared hardware and other services would still need review.</p>
<p>Passing a finite set of channel tests cannot prove that no possible channel exists. It can provide bounded evidence for a stated threat model and deployment.</p>
<p>OpenAI says its red-teaming exposed gaps in monitoring, automatic pausing, and agent-team safety mechanisms, and that it repaired specific failures. Those controls deserve adversarial testing alongside the boundaries they supervise.</p>
<p>The report also says researchers did not find an internet route agents could trivially exploit while concealing activity from monitors. That is a narrower finding than either &ldquo;containment is broken&rdquo; or &ldquo;containment is proven.&rdquo;</p>
<p>I want an isolation claim to name the adversary, the property, the enforcement point, and the evidence.</p>
<hr>
<p><em>Disclaimer: The views expressed here are my own and do not represent those of my employer.</em></p>
<h3 id="sources">Sources</h3>
<ul>
<li>OpenAI, <a href="https://openai.com/index/securing-our-frontier-model-training-environment/">Securing our frontier model training environment</a>, especially &ldquo;Red-teaming containment at scale,&rdquo; &ldquo;Finding novel paths to the internet,&rdquo; &ldquo;Communicating across isolated tasks,&rdquo; and &ldquo;Resuming frontier training with stronger defenses.&rdquo;</li>
<li>Intel, <a href="https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/best-practices/trusted-domain-security-guidance-for-developers.html">Trust Domain Security Guidance for Developers</a>, especially &ldquo;Overview,&rdquo; &ldquo;Software Hardening Recommendations,&rdquo; and &ldquo;Timing Side Channels.&rdquo;</li>
<li>Intel, <a href="https://cdrdv2.intel.com/v1/dl/getContent/733575">Intel TDX Module Base Specification</a>, May 2026, document 348549-008US, sections 2.7 and 12 on measurement and attestation.</li>
</ul>
]]></content:encoded></item></channel></rss>