Install
$ agentstack add skill-hmbown-wizards-of-the-ghosts-forcecage ✓ scanned · ✓ verified, works with Claude Code, Cursor, and more.
Security review
✓ PassedNo issues found. Passed automated security review. · v0.1.0 How review works →
- ✓ Prompt-injection patterns
- ✓ Secret / credential exfiltration
- ✓ Dangerous shell & filesystem operations
- ✓ Untrusted network calls
- ✓ Known-malicious package signatures
What it can access
- ✓ Network access No
- ✓ Filesystem access No
- ✓ Shell / process execution No
- ✓ Environment & secrets No
- ✓ Dynamic code execution No
From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.
Verified badge
Passed review? Show it. Paste this badge into your README, it links to the public security report.
Reliability & compatibility
Declared compatibility
Compatibility is declared by the source manifest. End-to-end runtime verification is coming, see below.
We're building live execution health for every listing: tool-call success rate, median latency, uptime, and last-checked timestamps, measured, not self-reported. It isn't live yet, so we don't show numbers we can't stand behind.
How agent discovery & health will work →About
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
- Restate the target, the success condition, and any no-touch boundaries before taking action.
- 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.
- 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.
- 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.
- 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.
- Stop for explicit confirmation before taking a live action that changes access, triggers an alert, or touches a real system boundary.
- Package the result as the deliverables below, with confidence, assumptions, and unresolved risk called out explicitly.
Deliverables
- Containment boundary spec: allowed surfaces, blocked surfaces, resource limits
- Execution report: attempted violations, denied actions, escape telemetry
- Safety assessment: release condition stated, recommendation (stay caged vs. descend one layer)
Pitfalls / Guardrails
- Call out the glue, permissions, or missing infrastructure before you imply this is fully operational.
- Do not use for: Freezing/pausing a running workflow → use a halt/interrupt spell
- Do not use for: Muting a specific stream or endpoint → use a filter/silence spell
- Do not use for: Editing CI/config to restrict a job → use a policy/config spell
- Do not use for: Inspecting existing sandbox logs → use an audit/inspect spell
- Do not use for: Disabling a feature temporarily → use a toggle/disable spell
- Do not use for: Forcecage is the only spell that combines: (1) pre-run boundary definition, (2) cage self-test, (3) outside observation with violation logging, and (4) explicit release authorization.
Verification
- Check that the result includes every deliverable promised above.
- Check that confirmed facts, assumptions, and inferences are visibly separated.
- Check that the exact live target, confirmation gate, and rollback or recovery path are explicit.
- Check that any missing glue code, permissions, or future work is labeled before the skill is treated as ready.
Example Invocation
/forcecage run this inside a tested containment boundary, keep the dangerous parts sealed, and tell me the release condition before anything leaves the cage
Source & license
This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.
- Author: Hmbown
- Source: Hmbown/Wizards-of-the-Ghosts
- License: CC0-1.0
Install and usage instructions live in the source repository linked above.
Reviews
No reviews yet, be the first.
Write a review
Versions
- v0.1.0 Imported from the upstream source.