Evaluating Containment of AI Agents: A Nine-Rule Sandbox Standard

Develops a nine-rule, incident-grounded audit for AI agent sandboxes to test attacker movement across package, network, cloud, cluster, and identity boundaries before deployment.

Endorsed by

John

Ved

Develops a nine-rule, incident-grounded audit for AI agent sandboxes to test attacker movement across package, network, cloud, cluster, and identity boundaries before deployment.

Endorsed by

John

Ved

Project Details

A nine rule, incident grounded audit for AI agent sandboxes, derived from the July 2026 Hugging Face intrusion. The audit tests whether an attacker who compromises an initial worker can move through package, network, cloud, cluster, and identity boundaries, using local checks that can be run before deployment.

Hackathon paper: Evaluating Containment of AI Agents: A Nine-Rule Standard for Verifiable Sandbox Security
Code: github.com/Somay-kousis/Apocalypse

Theory of Impact

The paper’s core claim is that a real incident can be turned into a set of tests anyone can run offline. That claim is much stronger if the tests are shown to hold on live infrastructure, not just on our fixtures. This funding pays for that validation.

If the live-cluster results agree with the offline audit, operators and evaluators have a reason to trust the checks as a pre-deployment baseline. If they disagree, we find out where the static approach fails and fix it, which is still useful to the field. The attacker test supports the same goal. Our red-team rounds showed that first-pass checks can look sound while preserving an attack path, so independent adversarial testing is how the standard earns credibility.

A validated version would give other researchers a worked example to apply to future incidents, so each new incident adds to a shared containment baseline.

People

Vikas Reddy

Team Member

Track Record

AI Incident Response Sprint (Apart Research), 2026

Grants Received– no grants recorded

Add grant

Funding Asks

Evaluating Containment of AI Agents: A Nine-Rule Standard for Verifiable Sandbox Security

Open

Minimum

$100

Ideal

$500

What this ask is

The biggest limitation in the paper is that our checkers audit declared configuration in a reconstructed fixture environment, so a deployment could pass and still drift. The funding would go toward testing whether the nine rules hold on live infrastructure.

At the minimum, we would stand up a small multi-node Kubernetes cluster on cheap cloud credits and run the checkers against it, comparing the audit’s pass/fail results with what actually happens when we attempt the documented attack steps against live workloads. We would use the same budget for a limited LLM-driven attacker test, to see whether an agent that doesn’t know our fixtures can find paths our hand-written adversarial cases missed. These are the two checks the paper names as missing.

With the ideal budget, we would run the live test on a larger, more realistic cluster with separate worker and control-plane nodes, a metadata service, and a proper identity graph. This would let us exercise Rules 6, 7, and 9 properly, since those depend most on real network and IAM structure. We would also run the attacker test for longer, so we can report how many new bypasses it finds and fix the checkers accordingly. Any remaining funds would cover workshop or conference registration so the revised results can be submitted.

How the money will be spent

Cloud credits for a larger multi-node Kubernetes test environment (separate control plane, metadata service, IAM): $200
LLM API credits for extended autonomous-attacker testing: $150
Workshop or conference registration fees: $150

Discussion

Private comments in this thread are only shown to approved funders and grant reviewers. Email hi@grantmaking.ai or to request access.

Private UserPrivate7d?

John HahnJudge · AI Incident Response SprintEndorsement7d

I thought this was one of the more directly useful submissions for the containment track. I especially liked that you worked backwards from the actual July incident rather than starting from a generic sandbox security checklist. Turning the crossed boundaries into nine executable checks makes the proposal much more concrete and gives a third party something they can actually test.

The red-teaming was also a strong part of the submission. I think the fact that your initial checks looked reasonable but adversarial testing still exposed 17 bypasses is a useful result in itself. It makes the case that a containment standard should not just have checks, but checks that have themselves been attacked.

For the innovation dimension, I think the most interesting contribution is the incident-grounded methodology and executable audit harness, rather than the individual security controls. Default-deny egress, non-root workloads, metadata isolation, credential scoping, and control-plane separation are all established practices. I would make it even clearer that the innovation here is how you translate a real incident into a reproducible containment test suite.

I would also be interested in seeing this tested beyond a reconstructed fixture environment. Right now the checker mostly evaluates declared configuration, and as you point out, a real deployment can drift after passing the audit. A natural next step would be running the same rules against a live cluster or against other incident classes.

Overall, great project! :)

Ved KJudge · AI Incident Response SprintEndorsement7d

The best Track 1 fit in this batch: nine rules, each tied to a boundary the real attacker crossed, with offline checkers anyone can run without lab access. The red team round is the standout — finding 17 bypasses in their own checkers and reporting that Rules 2, 6 and 7 only looked sound until adversarial fixtures hit them.