Red-Teaming Our Own Agent Sandbox: 9 Attack Payloads, All Blocked

Modern AI agents execute commands generated directly by a large language model. Because prompt injection can easily steer these models into unintended behaviors, running an agent without a proper isolation boundary hands your shell, filesystem, and network credentials over to an executor that can be manipulated. A secure sandbox is not an optional add-on; it is the absolute foundation of production agent architecture. To build reliable systems using frontier models like Claude 3.5 Sonnet, GPT-4o, or deep reasoning models via efficient infrastructure like n1n.ai, we must treat model fallibility as a design premise rather than an unexpected exception.

This guide walks through the red-team testing suite we built for the sandbox of hmharness, an open-source (MIT) agent framework designed for HarmonyOS and OpenHarmony development. We will examine how nine sophisticated attack payloads were executed, why they failed, and how you can implement these defensive patterns in your own LLM-driven workflows.

The Three Pillars of the Sandbox Architecture

Before diving into the specific attack vectors, we must understand the security primitives that protect the environment. Our sandbox relies on three core design choices:

1. Egress Allowlist: Outbound network traffic is deny-by-default, backed by an explicit, strict allow table.
2. Mount Policy: Filesystem boundaries are heavily restricted; the sandbox cannot cross designated workspace limits.
3. SecretBroker Architecture: Secrets exist exclusively as reference handles. Raw values are only resolvable under an active, scoped grant, and audit transcripts are automatically redacted. The underlying LLM sees a handle, never the secret itself.

When developing complex multi-step agents powered by APIs aggregated on platforms like n1n.ai, ensuring that downstream execution tools respect these boundaries prevents lateral movement and catastrophic data exfiltration.

The Nine Attack Payloads (Sandbox 2.1)

To validate our defense mechanisms, we subjected Sandbox 2.1 to a barrage of nine distinct red-team payloads, targeting network filters, filesystem integrity, and credential leakage.

Analyzing Network and Egress Defenses

Network exploits typically attempt to bypass the strict egress filtering rules. Attackers know that if an agent is tricked via prompt injection into fetching an external resource, it can leak environment variables or download malicious payloads.

1. DNS-Rebinding Lookalike Hosts: Attackers used homoglyphs and visually similar internationalized domain names (IDN) to trick the egress filter into matching an allowed domain. The sandbox resolver performs strict canonical IP resolution and rejects domain spoofing attempts before opening sockets where Latency < 50ms is maintained for legitimate internal checks.
2. Subdomain Wildcard Boundary: An attempt to exploit a loose wildcard parsing rule (e.g., matching notexample.com against *.example.com). The validator enforces strict dot-boundary checks.
3. URL Userinfo/Fragment Spoofing: Hiding malicious endpoints inside the userinfo (user:pass@host) or fragment segments of a URL. The normalization parser extracts the true authority component, neutralizing the deception.

Filesystem Isolation and Traversal Prevention

Filesystem attacks aim to break out of the designated project workspace to read sensitive system configuration files or write persistent malware.

4. Path Traversal: Injecting numerous ../ sequences to escape the root directory. The sandbox normalizes all paths through a chroot-equivalent virtualized root, immediately flagging and dropping any traversal attempts.
5. Cross-Drive Escapes: On multi-drive environments (particularly Windows), attackers attempted to reference alternate drive letters. The mount policy restricts absolute path resolution to the explicitly mounted workspace volume.

SecretBroker and Credential Safety

Even if code execution is contained, an agent with access to deployment tokens or API keys can cause severe damage. The SecretBroker pattern ensures that raw secrets never touch the model's context window.

6. Cross-Subject Secrets: Attempting to read a session secret belonging to Session A from within the sandbox execution context of Session B. Session isolation tokens prevent cross-talk.
7. Forged Handle References: Crafting artificial SecretBroker handles (e.g., handle_sec_9999) to trick the resolver into outputting raw values. The resolver validates handles against an in-memory cryptographic registry tied to the active execution grant.
8. Revoked Token Replay: Reusing a grant token that was explicitly revoked after a previous tool call completed. The grant state machine enforces strict single-use or time-bounded validations.
9. Grant Confusion: Grafting a high-privilege grant token onto a low-privilege execution thread. Context-bound cryptographic signatures ensure that grants cannot be swapped across execution boundaries.

Integrating Regression Tests into CI

Achieving an "all green" test suite once is a minor milestone; the true engineering value lies in running this entire red-team suite on every single commit to the sandbox code. This creates a permanent regression-proof barrier. Anyone who modifies the sandbox meets the nine payloads first, ensuring security debt cannot accumulate silently.

When building workflows that integrate with high-performance LLM gateways like n1n.ai, having automated test suites for your local execution layer guarantees that your entire application stack remains resilient against evolving prompt injection techniques.

Completing the Security Trilogy

The sandbox defense is part of a broader security trilogy designed for agentic workflows:

• LSP Pinning (Supply Chain): sha256-pinned language servers where any tampering results in an immediate refusal to execute.
• Browser Extension Bridge: Pairing codes combined with local tokens and explicit per-action approvals for browser automation (page_act).

By combining these layers, every surface an agent touches—execution, dependencies, and browser interactions—is defended, and every defense is fully testable in CI.

Conclusion

Treating the premise that "the model will make mistakes" as an absolute certainty changes how we architect autonomous systems. The level of fault tolerance your system possesses for model errors dictates whether it can successfully execute long-running tasks without human babysitting.

hmharness is an open-source (MIT) agent framework tailored for HarmonyOS and OpenHarmony development. It wires project creation, checks, builds, signing, installation, launching, log reading, and result verification into a cohesive local toolchain so AI does not just generate static code—it proves execution results directly against the local machine. (Note: This is an independent community project with no affiliation with Huawei or OpenAtom.)

Explore the project on GitHub: https://github.com/swsgbl/hmharness and review the audit evidence at https://swsgbl.github.io/hmharness/evidence/aisecurityopensourceharmonyos.

Get a free API key at n1n.ai