Guardrails & agent protection

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

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, Gemini, Kimi and Hermes session with a small check hook (all five 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.

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.

Kimi and Hermes: both read their hooks only from their own configuration file. OpenCognit therefore starts them with a configuration folder of their own (KIMI_CODE_HOME or HERMES_HOME): everything in it links to your real folder — login, sessions, history, skills — only the configuration file is a copy with the check hook. Your own configuration (~/.kimi-code, ~/.hermes) stays untouched. If the CLI renews its login along the way, OpenCognit carries that over into your real folder when the session ends — so you stay signed in outside OpenCognit too. Kimi and Hermes have no “ask” in hooks either (approval rule → refusal until you allow it in the app), and both wait for the hook only for a limited time (Kimi 10, Hermes 5 minutes) — if you do not decide in time, the command is refused, never let through.

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 → Security → "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".

Protected targets

Some places almost never have anything to do with an agent's actual work, but can later run code unnoticed or expose credentials. If an agent wants to write there, it always needs approval – whether through a shell command or its file tool (Claude Code "Write/Edit", Codex "apply_patch", Gemini "write_file"):

Normal project files (including .env in the project) are not affected, and rm -rf node_modules or dist inside the project run without asking. "Allow for session" applies per protected target. Reading credentials is covered in the next section.

Protect secrets

An agent steered by crafted text (a README, an issue, a web page) does not need to change keys – reading them and sending them away is enough. So the app asks first here too:

Not affected: using keys (ssh -i …, git push), listing folders (ls ~/.ssh), public keys (*.pub), your own project's .env, downloading.

Keep credentials out of the environment: Agent terminals do not get environment variables that look like credentials (AWS_SECRET_ACCESS_KEY, GITHUB_TOKEN, DATABASE_URL, STRIPE_SECRET_KEY …). The CLIs' own logins (ANTHROPIC_API_KEY, OPENAI_API_KEY, GEMINI_API_KEY …) stay, and so do your own terminals. The Settings → Security tab shows which variables are affected on your machine – names only, never values.

Both switches live under Settings → Security and are on from the start.

Package protection

Agents like to install packages — and sometimes invent names that do not exist. Attackers register exactly those names, and look-alikes of well-known packages. Before an agent installs with npm, pnpm, yarn, bun, npx, pip, uv, poetry or pipx, OpenCognit checks every package — also when wrapped in bash -c "…":

If anything applies, an approval banner holds the installation and names the reasons. Well-known packages (React, Express, Requests …) are not looked up; for unknown ones OpenCognit briefly asks npm or PyPI (only the package name, at most 3 seconds). Without a network only the name check counts. Only agent commands are checked — what you type yourself is left alone.

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.

Turning them off

Under Settings → Security → “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.

Check log

Settings → Check log shows what the guardrails did — newest first: blocked, secret in commit, held back, approved (once or for the session) and denied. Each entry shows the rule, the command or input (secrets redacted), where it came from (your input, an agent command or a thread), the agent and the project folder. The Blocked and Approvals filters narrow the list.

The log reads the local event log — it never leaves your machine and is cleaned up with its retention period (Settings → Data).

The notification bell at the top right also shows open approvals.

Limits

• The agent hook covers Claude Code, Codex, Gemini, Kimi and Hermes in the terminal; in threads, guardrails apply through the approval cards.
• Download first, run later: if an agent downloads a file (curl -o, wget, curl … > file) and later runs it in the same session (bash, sh, ./file, python …), that needs approval ("Downloaded script") — even though each command looks harmless on its own.
• Rules do not see what is inside a script file the agent writes itself and then runs.
• For Kimi and Hermes, protected targets currently apply to shell commands only, not to their file tools. Reading credentials with the read tool is caught for Claude Code, Gemini and Kimi; Codex and Hermes read through the shell, which is checked.
• If a program reads credentials by itself (e.g. aws s3 cp with ~/.aws/credentials), only that program sees it. If agents should have no access at all, run them as a separate user or in a VM.
• 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.