OpenCognitOpenCognitDOCS

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

TierWhat happensExamples (built in)
BlockThe command is refused.git reset --hard, rm -rf /, git clean -fdx, DROP TABLE, TRUNCATE
ApprovalThe command waits until you allow it in OpenCognit.git push, git push --force, npm publish, deployments, database migrations, curl … | sh
WarningThe 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):

  1. Before Claude runs a shell command, it asks the hook.
  2. The hook asks OpenCognit — over a local connection that is valid for this session only.
  3. 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 like your-api-key or process.env.TOKEN do not trigger
  • Sensitive files: .env (templates like .env.example are 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 leading sudo/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 hello123 goes unnoticed.
  • Guardrails do not replace a backup or a look at the diff before you commit.