Command warden
Add a fail-closed judgment layer before an agent runs a shell command—without pretending it is a sandbox.
- Time
- 60–90 min
- Level
- Safety pattern
- Shape
- Command + goal → local rules + Jev checks → allow, confirm, or deny
- You’ll practice
- Guardrails · Fail closed · Policy layering
The agent prompt
Copy this brief into your coding agent from the root of the project you want to build in. It names the behaviour, the constraints, and the checks to run — the decisions Jev makes stay explicit so you can see what the model actually decided.
Build a non-executing "Command warden" demo in this repository using Jev from TypeSafe AI.
Inspect the codebase and preserve its stack. Follow the official TypeSafe skill, installing it with npx skills add typesafe-ai/skills --skill typesafe-ai if needed.
The UI accepts a proposed shell command plus a short stated goal. It must never run the command. First apply deterministic deny rules for destructive patterns, privilege escalation, secret access, and network exfiltration. Only commands not denied locally go to Jev, with separate Noul questions for goal alignment, reversibility, and whether human confirmation is warranted, plus a Choice risk tier. Show which local and model signals produced the final allow_for_demo, confirm, or deny result.
Requirements:
- This is an educational policy visualizer, not a security boundary; say so prominently.
- Keep TYPESAFE_API_KEY server-side and never interpolate or execute input.
- Deterministic denial always wins. API errors and low confidence fail closed.
- Put policies in named pure functions with exhaustive tests.
- Include benign and dangerous sample commands, all inert strings.
- Add accessibility and end-to-end tests for the decision explanation.
Run checks and summarize threat assumptions and limitations.Built something like this
Community projects in the directory that solve a similar problem: