Semantic action classification describes the potential effects of a shell command by its domain, action and destructive character, rather than recording only that a command was run. Sentience Governor currently applies deterministic classification to Claude Code shell commands and records unknown or incomplete classifications rather than assuming an effect it cannot establish.
“The agent ran a command” is nearly useless as a record. rm -rf build deletes files. git push --force origin main rewrites a shared branch’s history. aws elbv2 delete-load-balancer removes a piece of cloud infrastructure. All three are, at the level of a tool call, the same thing: a shell command. To govern an agent, review what it did, or decide where a person should look first, the record has to say what the command does.
Three ways to recognize what an action does
| Approach | How it works | Where it fails |
|---|---|---|
| By name | Match the command or tool name, often with patterns | Aliases, wrappers and chained commands slip past; anything unparsed is often allowed |
| By declaration | Trust what the tool says about itself, such as the Model Context Protocol’s read-only or destructive hints | Hints are self-declared, describe a whole tool rather than one call, and should be treated as untrusted |
| By effect | Describe what each part of the command would do | Depends on rules for the commands it recognizes; some effects cannot be known from the text alone |
Most published guidance on blocking dangerous agent commands takes the first approach: lists of patterns such as rm -rf or git push --force. It works for the obvious cases and fails quietly on the rest, and a hook that cannot parse a command usually lets it through. Semantic action classification takes the third approach, and pairs it with an explicit answer for what it cannot classify.
Describing an effect
An effect is described along three lines:
- Domain. What the command affects, described by its material consequence rather than its transport: version control, the filesystem, packages, cloud infrastructure, processes. A call to a cloud provider’s control plane is a cloud infrastructure effect, not a network one.
- Action. What it does there: read, create, modify, delete.
- Destructiveness. Whether it discards data or state: yes, no, or undetermined.
A compound command is described part by part. In git fetch && git push --force origin main, the fetch reads from a remote and updates local references without discarding anything, while the forced push sends changes to a remote and destructively rewrites version-control history. The parts are never merged into one summary, so a rule about destructive version-control changes matches the push and is not triggered by the fetch.
The unknown case
The most important design choice is what happens when the classifier cannot tell. Some commands hide their effect: a subshell, a command built from a variable, a script whose contents are not on the command line. Some effects depend on state the text does not show: an infrastructure command that applies whatever plan it finds is destructive or not depending on the plan.
An honest classifier records “unknown” rather than guessing. It keeps the effects it could establish, marks the classification as incomplete, and leaves destructiveness undetermined where the text does not decide it. That is the opposite of a pattern list that fails open: the uncertainty stays visible to whoever reads the record, instead of disappearing into an implicit “allowed”.
Classification is not a decision
Classifying an action describes it. Deciding what to do about it is a separate step, made by policy or by a person. Keeping the two apart has practical value. The same classification can feed a record, a review, a high-consequence designation or an approval step, and changing a policy does not require reclassifying anything. It also means a classification can be checked on its own terms: did it describe the command correctly?
An example
The scenario is illustrative. The descriptions are, in plain language, what Sentience Governor 0.3.2.1 records for this command.
An agent working on infrastructure runs cd infra && terraform plan && terraform apply -auto-approve. A pattern list sees terraform and either ignores it or blocks every use of it. The effect description says more: the plan reads cloud state, and the apply changes cloud infrastructure, with its destructiveness undetermined, because whether anything is destroyed depends on the plan, which the command text does not show. Every part of the command was recognized, so the classification is complete, and it still says plainly what it cannot establish. A reviewer reading the record knows exactly what to check.
How Sentience Governor applies it
Sentience Governor classifies Claude Code shell commands with deterministic rules: no model is called, nothing is executed, and the same command always produces the same description. Each part of a command is described by domain, action and destructiveness, and constructs the rules cannot interpret are recorded as unknown, with the classification marked incomplete. The description is stored with the action in the execution record and can be used to designate high-consequence operations by effect. Tool calls from Sentience Governor’s other integrations are not classified this way today; they are recorded by tool name.
Where this is heading
Emerging approaches. Effect-based description is spreading beyond shell commands to other tool calls, combined with tool-declared metadata that is weighed as a claim rather than a fact. Research systems pair deterministic checks for clear cases with model-based judgment for ambiguous ones.
Open questions. How to describe effects that only the target system knows, such as what an infrastructure plan will change. How to classify consistently across tools that do the same thing under different names. And how to measure a classifier’s accuracy on the commands agents actually run.
Where the concept stops
Semantic action classification describes what a command could do, based on its text and the rules for the commands it recognizes. It does not confirm what the command actually did, it does not judge whether the command served the task, and it is limited to the command families its rules cover. It describes the kind of effect, not the importance of the target: deleting a build directory and deleting a database’s files are both destructive filesystem deletions, and telling them apart is a judgment about context. Its value lies in describing actions precisely, and in saying plainly when it cannot.