Jumping the Sandbox Without Touching It

Host: Welcome back to Runtime AI Security. This is episode two of five, and we're working through the book Zero Trust and Sandbox Isolation. Last time we established the central thesis, which is that author trust is an identity concept, sandbox isolation is a technical concept, and the two are orthogonal. Today we get to the part of the book that makes that abstract point feel very concrete. Chapter two is called Attack Vectors, Jumping the Sandbox. And the episode title I've given it is Jumping the Sandbox Without Touching It. So let's start there. What does it mean to jump a sandbox without touching it?

Expert: It means the attacker never engages with the technical isolation mechanism at all. The manuscript is quite precise about this. When a host system relies on reputation to relax security controls, attackers shift their focus from breaking the technical sandbox to exploiting the trust signals themselves. That's the whole chapter in one sentence. If the host has built a policy that says, in effect, code from a verified publisher gets filesystem write access, or code from a high reputation author gets network egress, then the attacker doesn't need a memory corruption bug in the sandbox. They need to look like a verified publisher. The sandbox stays intact. It just gets told to stand down.

Host: So the sandbox is fine. The sandbox is doing exactly what it was designed to do.

Expert: Exactly. And that's why the book frames the failure as a policy failure on the host system rather than a failure of the sandbox technology. You can have a beautifully engineered isolation layer, system call filtering, no network egress, read-only filesystem, and none of it matters if there's a line in your policy engine that says skip all of that when the signature checks out. The attacker attacks the line, not the layer.

Host: The book presents this as a table of attack vectors, and I know we don't read tables aloud, but can you give me the shape of it? What's the organizing principle?

Expert: The organizing principle is the trust signal being exploited. Each row pairs a vector with the specific signal it targets and a real-world analogue. So you have vectors that target cryptographic signatures, vectors that target reputation scores, vectors that target account identity, vectors that target community endorsements, brand recognition, third party endorsements, policy engine heuristics, build provenance, transitive trust from dependencies, community governance, and stale trust signals. Twelve vectors in total in the manuscript's taxonomy. What I find useful about that framing is that it forces you to ask a diagnostic question about your own system. Not which sandbox escape am I vulnerable to, but which trust signals does my policy engine actually consume? Because every signal you consume is an attack surface.

Host: That's a genuinely different question than most people ask. Let's take them in the order the book takes them. First up is trusted publisher certificate abuse. Walk me through the mechanism at a conceptual level.

Expert: The manuscript describes it as one of the most direct methods of jumping the sandbox. An attacker compromises or forges a verified publisher certificate that the host uses to automatically grant elevated permissions to the software. And the effect is that the sandbox is effectively disabled. The book is careful about where the danger lives. It says this attack is particularly dangerous because it operates at the policy layer. The sandbox itself may be technically sound, but the host's policy engine has been tricked into disabling it.

Host: So the certificate isn't the vulnerability. The certificate is doing its job.

Expert: Right, and this connects back to the distinction the first chapter draws. A cryptographic signature's domain is integrity verification. Its purpose is to confirm artifact authenticity. Its correct operational effect is that it verifies origin. What it does not do, and the manuscript states this flatly, is imply safety of behavior. A signature tells you where something came from. It tells you absolutely nothing about what that thing will do when you run it. The failure isn't in the cryptography. The failure is in treating a provenance statement as a behavioral guarantee.

Host: Okay. Second vector, reputation-based privilege escalation. This one has a time dimension to it that I found unsettling.

Expert: It does. The setup is that a host maintains a trust score for authors based on past contributions or account age. Perfectly reasonable design on its face. The attack is that an adversary may build a high reputation over months or years by contributing benign code. Real code. Useful code. Code that passes review, because it's genuinely fine. And then once a sufficient trust threshold is reached, the attacker uses that trust to push a malicious update that bypasses normal sandbox restrictions.

Host: Months or years. That's a patient adversary.

Expert: The manuscript's real-world analogue for that row is a long-term sleeper agent in open source. And I want to be careful here, because the defensive point isn't that we should be suspicious of long-serving contributors. The defensive point is structural. If your system is built so that accumulated history converts into technical privilege, then you have created an incentive to accumulate history. You've built a mechanism that rewards patience, and patience is something a well-resourced adversary has in abundance. The fix isn't to distrust contributors. The fix is to sever the conversion. History informs the user. History does not adjust the sandbox.

Host: And the book says this process can be accelerated. That's the sock puppet piece.

Expert: Yes. Sock puppet reputation farming. The trust signal being exploited there is community endorsements, and the mechanism is that the attacker creates a network of fake accounts to artificially inflate the trust score of a malicious package. The real-world analogue the book gives is coordinated review manipulation, which anyone who's shopped online will recognize instantly. The consequence in a software supply chain context is more serious though. The manuscript says the inflated score causes the host to treat the package as low-risk and apply weaker sandboxing.

Host: So you don't have to wait years if you can manufacture the appearance of a community.

Expert: That's the shortcut, yes. And it's worth noting what the first chapter says about community endorsement as a category. Its domain is social proof. It's a supplementary risk signal. And the manuscript's stated operational effect is that it is non-authoritative and must not relax technical controls. The reason it has to be non-authoritative is precisely that it's cheap to fabricate. A cryptographic signature at least requires you to compromise or forge a key. An endorsement requires you to create an account.

Host: Let's move to the next section, which the book titles Account Takeover and CI/CD Compromise. This feels like the shift from building fake trust to stealing real trust.

Expert: That's exactly the framing the manuscript uses. It says that rather than building reputation from scratch, attackers frequently target existing trusted entities. Account takeover is the first of those. An attacker compromises a legitimate, high-reputation developer account. The book names three routes at a high level, phishing, session hijacking, or credential reuse. The attacker then publishes a malicious skill under that trusted identity, and the host automatically grants elevated permissions based on the account's history.

Host: And from the host's point of view, nothing looks wrong at all.

Expert: Nothing looks wrong, because in a meaningful sense nothing is wrong. The identity is genuine. The account really does have that history. The contributions really were made. Every fact the trust system is reasoning about is true. The trust system's conclusion is simply not the conclusion it thinks it's drawing. It thinks it's concluding this code is safe. What it has actually concluded is this code was published from an account with a good history. Those are different statements, and the gap between them is where the entire attack lives.

Host: Now the book pushes one step further and says even if the developer's account is secure, the build pipeline may not be. That's the CI/CD compromise vector.

Expert: Right, and I think this is the most instructive one in the chapter, because it removes the last human from the equation. In a compromised CI/CD pipeline attack, the attacker infiltrates the author's build environment. The manuscript gives GitHub Actions and GitLab CI as examples of the kind of environment involved. The attacker injects a malicious payload into the published artifact. And here's the crucial part, quoting the logic of the book directly: because the published artifact still carries the trusted author's automated signature, the host grants it elevated permissions.

Host: The signature is automated. So the signing happens after the injection.

Expert: That's the structural flaw. If your signing key lives inside the same automated pipeline that assembles the artifact, then whoever controls the pipeline controls the signature. The signature stops being an attestation by a human being that this is the thing I built and intended to publish. It becomes a rubber stamp applied by a machine to whatever the machine happened to produce. And the trust signal that reaches the host is indistinguishable from a legitimate one, because as far as the cryptography is concerned it is a legitimate one.

Host: This brings us to SolarWinds, which the book calls the canonical example. Tell me how the manuscript presents it.

Expert: The manuscript describes the SolarWinds attack of 2020 as the canonical example of this vector. Attackers compromised the SolarWinds Orion build system and injected the SUNBURST malware into a legitimately signed software update. That update was then distributed to approximately eighteen thousand customers, including multiple United States government agencies. And then the book delivers the line that I think every architect should have taped to their monitor. The trust signal, a valid cryptographic signature from a known vendor, was entirely intact, yet the software was malicious.

Host: Entirely intact. Not forged, not bypassed, not expired.

Expert: Correct. There was nothing to detect at the signature layer, because the signature layer was working perfectly. It faithfully attested that this artifact came from SolarWinds. That statement was true. The problem is that eighteen thousand downstream systems were treating that true statement as though it meant something it does not mean. That's the defensive lesson of the entire chapter, and I'd state it as plainly as the book does. A valid trust signal can be entirely genuine while the software it attests to is malicious.

Host: That's a hard thing to internalize, because signature verification feels like such a solved problem. It either checks out or it doesn't.

Expert: And it is solved, for the question it answers. The trouble is that signature verification answers a question about origin, and we keep asking it a question about behavior. The book's model handles this by keeping the two in separate lanes. You verify the signature, absolutely, and you use the result for what it's good for. But the sandbox parameters are set by policy that doesn't read the signature at all. Under the book's secure boundary model, the SolarWinds update would still have been installed, and its signature would still have verified, and it would still have run inside exactly the same minimum-permission sandbox as an unsigned package from an anonymous author. The blast radius would have been a function of the sandbox, not a function of the vendor's reputation.

Host: I want to give listeners something concrete. If somebody is running a platform today that executes third-party code, what's one thing they can do this week off the back of this chapter?

Expert: Do a trust signal inventory of your policy engine. Sit down with whoever owns permission decisions and enumerate every input that can change a sandbox parameter. Signatures, publisher verification status, reputation scores, account age, download counts, star counts, endorsement flags, allow lists, and any manual override anybody has ever added. Write them all down. Then for each one, ask a single question. Can this input, on its own, cause us to grant a permission we would otherwise withhold? Every input where the answer is yes is a documented attack vector against your platform, and the chapter you've just heard describes how each of those categories gets attacked.

Host: And presumably the ideal outcome of that inventory is a very short list.

Expert: The ideal outcome is an empty list. That's the zero-trust baseline the book argues for. Trust signals become purely informational, shown to the user in the permission prompt so they can make an informed decision, but with no path into the enforcement layer at all. Most teams will not get to empty on the first pass. But going from an unexamined list to a documented list is enormous progress, because you cannot defend a surface you haven't enumerated. And a lot of these entries turn out to be conveniences that somebody added years ago for a reason nobody remembers.

Host: One thing that strikes me across all four of these vectors, certificate abuse, reputation farming, account takeover, pipeline compromise, is that the attacker's target is never the thing we usually spend our defensive energy on.

Expert: That's the thesis of the chapter. We spend our energy hardening the sandbox, which is the right thing to do, and it works, which is precisely why the adversary goes elsewhere. Attackers are economically rational. If the sandbox is expensive to break and the policy engine is cheap to persuade, they will persuade the policy engine every single time. And the first chapter of the book anticipated this with that finding from the sandbox escape research, that the agent's blast radius is not the agent process. It includes everything the agent can write that the host later trusts. Trust is where the leverage is.

Host: That's a good place to close. Next episode we take the taxonomy further into its stranger corners, impersonation and homoglyph attacks, deepfaked endorsements, time-based trust activation, governance manipulation, and the surprisingly effective trick of using legal language to talk an automated risk scorer into lowering its guard. That's episode three, Impersonation, Time Bombs, and Legal Loopholes. Thanks for listening to Runtime AI Security.

Expert: Thanks. And the thread to carry into that episode is the one we ended on. Everything we discussed today involved a trust signal that was, in some real sense, authentic. Next time we look at what happens when the signal itself is fabricated, and why the defense turns out to be exactly the same.