How governance works
Termyte uses deterministic local analysis. It does not ask an agent or LLM whether a command is safe.Shared decision flow
Two operating paths
Dependable check path
termyte check:
- understands the command;
- resolves visible targets;
- calculates risk;
- loads built-in, global, and repository YAML policy;
- applies exact user memory;
- writes a redacted JSONL event;
- returns a decision without execution.
Experimental execution path
termyte run -- <command> and termyte shell use repository-local SQLite
runtime policy, ledger, and semantic memory. They can execute approved commands
and record outcomes.
The governed shell uses command shims and supported shell hooks to request a
decision before execution. Intercepted commands fail closed if the local guard
is unavailable.
How blocking works
A recognized action can be blocked by built-in risk or policy. Policy decisions are combined using:- secret access is blocked by the default YAML preset;
- broad wildcard deletes are blocked;
- force push to
main,master, ortrunkis blocked; DROP TABLE,TRUNCATE TABLE, and unscoped SQL delete are blocked;- package publishing and destructive Git history operations warn.
How agents are governed today
termyte run <agent> prepares repository policy, logs, memory, and session
context, then launches the supported agent in limited mode.
It does not currently guarantee that all agent subprocesses pass through the
experimental governed shell. Use termyte check to validate policy and
termyte shell when deliberately testing interception.