Session Analyzer
Guardrails stop what you can name in advance. The Session Analyzer reads the rest: an agent that scores every action for intent and syntax, before it executes.
The gap
A deny list catches what you thought of. DROP, TRUNCATE, DELETE without a WHERE. Those are the easy ones, and they are worth blocking outright.
The harder case is a statement that breaks no rule. Every query below is permitted. Read in sequence, they are an extraction. Nothing in a list of forbidden operations sees that.
How it works
The analyzer runs on the statement your agent just sent, in the same pass as the deterministic rules. It returns a risk score. The score decides what happens next.
Syntax alone says a statement is well formed. Intent asks what it is for. A SELECT with no WHERE on a table of ten rows and the same statement on a table of ten million are different acts.
The score comes back while the statement is still in the sidecar. Nothing has reached your database yet, so the outcome is still a choice.
The score decides: pass, block, or route to a human. The same three outcomes every other control produces, so a scored action and a rule-matched action are handled the same way downstream.
Point the analyzer at the provider you already cleared. Your API key, your data policies, your region.
Why an agent
The Session Analyzer does not understand your business. It is not trying to. It has one job and a few hundred milliseconds to do it: read this statement, judge what it is for, return a score.
It matches a pattern you wrote in advance. That is why it is reliable, and that is also its ceiling.
Your agent issues the next statement in milliseconds. A person reading a queue is already behind.
One that moves at the speed of the thing it watches, with a single job: read every statement live and stop the dangerous one before it lands.
One key in the config file, and every action your agents take gets read before it runs. Free and open source under MIT.