The model should not decide whether the config is safe
A language model can explain a finding. It should not choose the severity, the score, or whether a vulnerability exists. Foo Guard keeps that decision in deterministic rules.
The review that comes back as a paragraph
Someone pastes an agent config into a chat and asks, “Is this safe?” The reply is fluent. It mentions least privilege. It may even suggest a patch. Nothing in that paragraph is tied to a rule you can re-run tomorrow.
Ask the same question after the config gains a shell tool and the answer can change tone without changing method. The model is grading a story about the file. The file’s permissions are still whatever was declared.
A model paragraph beside a deterministic rule result
Model reply
Looks reasonable.
Nothing here can be re-run tomorrow.
Rule result
AG-013
CriticalShell or Command Execution
Same configuration, same result.
Separate the explanation from the decision
Foo Guard’s rules engine decides whether a rule matched, how severe that match is, and what the score and grade are. The same configuration produces the same result.
An optional model can explain a finding and suggest a remediation. That suggestion does not raise or lower the severity, and it does not delete the finding. The score changes when the configuration changes and the rules run again.
This is the product boundary. If a reviewer cannot point at a rule id and a location in the file, they are reading commentary.
Start from the evidence path
Each finding names the rule, the severity, and the place in the configuration that triggered it. That path is the review. Wildcard permissions, a general-purpose HTTP tool, shell execution, and a long-lived credential are findings because the declaration says those capabilities are present.
A finding is not a claim that the bad outcome already happened. An agent that can read data and send arbitrary requests, with no approval step, is a configuration to fix before it runs. The scan does not execute the agent or the tools named in the file.
Treat the suggested patch as a draft
When remediation is available, read it as a proposed edit. Apply it in your source, then scan the revised file. The new assessment is the one that shows whether the rule still matches.
Keep reviewed versions of configs you intend to reuse. A published Library version is a sanitized copy your team can retrieve. Publishing it does not install the file into an agent.