harshaIntentGuard is my alpha Python and LiteLLM command-review project. The CLI submits a proposed command and user context to a local API, then translates the result into allow, warn, or block behavior.
The interesting part is how several imperfect signals become one decision. A persuasive explanation alone is not enough.
Start with the inexpensive signals
The reasoning engine evaluates shell-command rules first. A matched rule above 0.9 risk returns immediately. Otherwise, a lightweight classifier contributes another risk signal.
Command history comes from SQLite. The context stage examines up to 100 recent actions, filters them by user, tokenizes commands with shlex where possible, and uses BM25 to select five relevant examples. Those examples become bounded context for the LLM assessment.
BM25 here is lexical history retrieval. It is not evidence that two commands have identical consequences, and a history anomaly is not proof that a command is malicious. The pipeline needs to keep those meanings distinct.
Preserve a critical signal
The scoring function combines rule risk, classifier risk, a context anomaly score, and an LLM contribution weighted by its reported confidence. If an individual rule, classifier, or LLM signal exceeds 0.8, the function preserves that high risk instead of letting the weighted combination dilute it.
The final thresholds map scores above 0.7 to block and above 0.4 to warn; lower scores allow. A warn decision requires the user to type CONFIRM. A block decision exits before the interceptor executes the command.
These values are implementation settings, not calibrated probabilities of harm. Their usefulness needs evaluation against representative commands, missed hazards, and unnecessary interruptions.
Understand the failure path
The current interceptor allows execution when the local API cannot be reached or times out. That choice keeps the developer's command path available, but it means the tool is an advisory layer rather than a mandatory security boundary.
This is the tradeoff I want the project page to make visible. Rules, classification, history retrieval, and an LLM can help explain an action; they do not turn the alpha into a guarantee of safe execution.
A useful review should still identify the command, its target, the context used, and the consequence the user is being asked to accept. The space before Enter is valuable because the operation has not happened yet. Keeping the decision concrete is what makes that space useful.
Read IntentGuard's engineering notes and inspect the risk-scoring implementation.