forcecage

Forcecage

Contain untrusted code, agents, or operations inside a tested cage before anything leaves it.

Sigil

+-------------+
|  x     x    |
|    .-.      |
|   (###)     |
|    `-'      |
|  x     x    |
+-------------+

What This Skill Does

Forcecage creates a pre-tested containment boundary around a subject that has not yet run. It is not about stopping, pausing, or muting something already in motion. The cage is built first, self-tested, then the subject enters. The operator watches from outside and decides whether to release. In this grimoire, Forcecage is treated as a literal spell with a prototype delivery profile. Canonical reference input: Forcecage (spell).

When To Use

• Trigger this spell when the user asks to contain, cage, sandbox, isolate, or box untrusted/experimental/dangerous code, agents, tools, or operations before they run. Look for:
• Explicit boundary requests: "only inside", "cannot reach", "blocked from", "disposable", "throwaway"
• Subject types: untrusted code, third-party binaries, experimental agents, red-team samples, vendor scripts, refactor tools
• Observation intent: "watch what it does", "log denied actions", "see what it reaches for", "observe from outside"
• Release conditions: "before we trust it", "prove itself first", "step-down after", "authorize descent"

Prerequisites

• No extra runtime dependencies beyond Hermes Agent and the normal toolset for this session.

Procedure

1. Restate the target, the success condition, and any no-touch boundaries before taking action.
2. Define the boundary: List exactly what the subject CAN access (specific files, URLs, namespaces) and what is BLOCKED (network egress, credential stores, process spawning, writes outside a target directory). Default to deny-all.
3. Build and self-test the cage: Create the containment environment (disposable workspace, copied repo, fake namespace, egress-blocked container). Run probes to confirm blocked surfaces actually block. A cage that hasn't been challenged is not trusted.
4. Run the subject inside, observe from outside: Execute the subject within the boundary. Collect audit logs of denied actions, attempted escapes, and resource access patterns. The operator stays outside the cage.
5. Set release condition before descent: Define what must be true for the subject to leave the cage (e.g., zero unauthorized writes, specific test pass, operator sign-off). If the condition is not met, the subject stays cage-only. If met, authorize a single step-down to a less restricted environment.
6. Stop for explicit confirmation before taking a live action that changes access, triggers an alert, or touches a real system boundary.
7. Package the result as the deliverables below, with confidence, assumptions, and unresolved risk called out explicitly.