Guardrails & agent protection
How OpenCognit blocks dangerous commands or holds them for approval — for your input and for what agents run on their own.
AI agents run commands. Mostly harmless — but a git reset --hard, an rm -rf or a careless
git push can destroy work or publish something. Guardrails are rules that catch such commands
before they run.
Three tiers
| Tier | What happens | Examples (built in) |
|---|---|---|
| Block | The command is refused. | git reset --hard, rm -rf /, git clean -fdx, DROP TABLE, TRUNCATE |
| Approval | The command waits until you allow it in OpenCognit. | git push, git push --force, npm publish, deployments, database migrations, curl … | sh |
| Warning | The command runs and you get a notice. | sudo |
You find and edit all rules under Settings → Guardrails. A rule is a regular expression (case-insensitive); you can add your own.
Where guardrails apply
1. Your input
Everything you or the queue send to a terminal is checked before it goes out — pasted multi-line text too, line by line.
2. Commands an agent runs on its own
This is the more important part: an agent does not type its commands into your terminal, it runs them itself. To check those as well, OpenCognit starts every Claude Code, Codex and Gemini session with a small check hook (all three CLIs offer an interface for it):
- Before Claude runs a shell command, it asks the hook.
- The hook asks OpenCognit — over a local connection that is valid for this session only.
- OpenCognit checks the command against your rules:
- Block → Claude gets a refusal with the reason and a request not to work around it.
- Approval → Claude waits. A card with Allow once, Allow for session and Deny appears in the terminal, plus a notification.
- No match → OpenCognit stays out of it; Claude asks as usual.
If OpenCognit cannot be reached, Claude asks you itself — a command is never waved through
silently. Your own Claude configuration (~/.claude) stays untouched; the hook only applies to
sessions OpenCognit starts.
Codex and Gemini: Gemini gets its own settings file, Codex gets the hook at launch — your
configuration (~/.gemini, ~/.codex) stays untouched. Because Codex otherwise wants every hook
confirmed once, OpenCognit starts it with the switch that skips this confirmation for that one
launch. Codex and Gemini have no “ask” in hooks — there an approval rule becomes a refusal with a
reason unless you allow it in the app.
The same hook briefly reports every file read or change to OpenCognit — so the Kosmos shows live what the agents are working on.
Turn it off under Settings → Guardrails → "Also check agent commands" (default: on). The change applies to newly started sessions.
3. In threads
In threads every agent action goes through an approval card anyway. Guardrails come first: blocked actions are never offered, actions that need approval are always asked — even if you otherwise set the tool to "always allow".
Secrets in commits
Before an agent (Claude session or thread) runs git commit, OpenCognit scans the changes going
into the commit — with git commit -a or a preceding git add also unstaged and new files. It
blocks on:
- Known keys: Anthropic, OpenAI, GitHub, GitLab, Slack, AWS, Google, Stripe
- Private keys (
-----BEGIN … PRIVATE KEY-----) and passwords in connection URLs (postgres://user:password@…) - Hard-coded secrets such as
API_KEY = "…"with a random-looking value — placeholders likeyour-api-keyorprocess.env.TOKENdo not trigger - Sensitive files:
.env(templates like.env.exampleare fine), SSH keys,*.pem,credentials.json,.npmrc
The agent learns which file contains what — the key itself is never shown or logged.
Protection against workarounds
Rules check the command the way the shell would run it — not just the text as written:
- Chained:
npm test && git push→ both parts are checked - Wrapped:
bash -c "…",sh -lc '…',eval "…",$(…)and backticks - Disguised:
g"i"t,\git,/usr/bin/git, a leadingsudo/env/timeout,git -C path -c … reset --hard - Through variables:
X=reset; git $X --hard - Encoded: if decoded content is executed directly (
… | base64 -d | sh), there is no telling what runs — that always needs your approval.
Log
Every block and approval is written to the local event log (secrets redacted). The notification bell at the top right shows open approvals.
Turning them off
Under Settings → Guardrails → “Guardrails active” you switch everything off at once: no rule applies, no commit scan — agents run everything unchecked. Meant for environments where nothing can break (e.g. a throwaway VM). The Kosmos still shows file access.
Limits
- The agent hook covers Claude Code, Codex and Gemini. For Kimi and Hermes in a terminal, guardrails apply to your input; in threads (Kimi, Hermes) through the approval cards.
- Rules do not see what is inside a script file the agent writes first and then runs. Guardrails protect against mistakes and simple tricks, not against every intent.
- The commit scan recognises unambiguous patterns. A plain password like
hello123goes unnoticed. - Guardrails do not replace a backup or a look at the diff before you commit.