Ops · Safe terminal utility

A terminal agent that runs your shell commands — except the five that could kill the server.

Run commands exactly as given. Get raw stdout, stderr, and exit code — no interpretation. A hardcoded denylist of five dangerous families blocks structurally, with a full audit trail on every run.

Book a 30-min scoping call →See how it works

Hardcoded denylist families, no override

Interpretation of command output

100%

Audit coverage on every execution

The Challenge

Shell access is all-or-nothing — and the "all" side includes the command that wipes the server.

A junior engineer is debugging a failing deploy. Three hours in, tired, they paste a command from memory. They mean rm -rf ./tmp but they mash a space in the wrong place. The server loses a directory you needed. Nobody meant to do this.

The failure mode is the same every time. Every organization "solves" it the same way: a senior engineer becomes the bottleneck, reviewing every shell command before execution. Under pressure, some reviews get thorough and some get skipped. Onboarding juniors becomes a calculated risk, and scripts that need user input get written defensively or not at all.

The root cause isn't the typo. It's that safety is a cultural practice rather than a structural one. You can't review your way to safety on every command, and you can't write a playbook that survives a 2am incident. The dangerous commands don't announce themselves.

This agent flips the default: run almost anything, hard-block a fixed denylist of five dangerous families before execution, and return raw output with no interpretation. The bottleneck goes away. The catastrophic commands stay impossible.

How the agent handles it

Denylist check. Execute or block. Raw output. Audit trail.

Denylist, not allowlist — so actual ops work still works.

Allowlists cripple engineers. Denylists stay ergonomic. The catch: the denylist is exactly five families and it doesn't grow by committee. rm -rf, gateway stop/start/restart/run, disk formatting, fork bombs, disk wipe. Everything else runs.

Hardcoded and immutable. There is no override.

The five families cannot be disabled at runtime. No "just this once" flag. No sudo escape. No metacharacter that bypasses parsing. The consistency is the product — you can tell a junior engineer "just try it" and mean it.

Output comes back raw. The agent has zero opinions.

You get exactly what the shell returned: stdout, stderr, exit code. No filtering. No helpful summaries. No AI judgment. The output is paste-ready for the next script in the pipeline, which is the whole point of a shell in the first place.

Every command and its output is logged by default.

Postgres-backed immutable audit log: who ran what, when, and what came back. When a blocked command is attempted, the ops team gets a Slack alert with the user and the command. Pattern analysis shows who's learning and who's trying to escape the guardrails.

What you get

Three things change once the denylist is live.

5families

Dangerous commands blocked before execution

Not more. Not less. Tight enough to stay ergonomic, strict enough to prevent the catastrophic ones.

0false positives

Safe commands wrongly blocked

The denylist is deliberately narrow. Common ops work (git, docker, bun, python, find, grep) never hits a wall it shouldn't.

100%

Audit coverage on every run

Every command, timestamp, user, output captured in immutable storage. SIEM-ready and replayable during post-incident forensics.

Numbers observed in Brilworks' internal reference deployment. Actual figures on your stack will depend on user volume, command mix, and how strict you want the alerting thresholds.

Is this right for you?

Honest fit criteria. We'd rather say no than oversell.

✓Strong fit if

You have 3+ junior engineers who need shell access for diagnostics and operational tasks
You currently review shell commands manually before execution and it's becoming a bottleneck
You need an audit trail for compliance, post-incident forensics, or regulatory reviews
Your team operates across multiple cloud providers and wants a consistent denylist

✗Not a fit if

Your team is 1–2 engineers and you trust every command implicitly
You need to grant sudo, systemctl, or privileged access beyond a user shell
Your compliance policy requires human sign-off on every individual command
You use a proprietary shell that doesn't match standard Unix command names

Book a 30-minute scoping call.

We'll walk through your current shell-access policy, map it against the five-family denylist, and tell you honestly whether structural safety beats review-based safety for your team.

Book a scoping call →See other case studies