Intro

Sentinel is a CLI-first security scanner for AI/LLM applications and model supply chains. These docs explain what each Sentinel finding detects, why it matters, and how to fix it.

The goal is to make AI security documentation useful during engineering decisions: which file is risky, which finding should block a release, and which command should be used for retest.

With Sentinel, you can:

• Find model artifact risks — pickle, PyTorch, ONNX, GGUF, safetensors, and compressed bundles.
• Test prompt and template security — prompt injection, unsafe Jinja2, RAG leakage, and guardrail bypass patterns.
• Validate agent and MCP surfaces — manifests, permissions, tool boundaries, and network exposure.
• Report in CI/CD — JSON, SARIF, JUnit, CSV, HTML, and Markdown outputs.

Who uses Sentinel?

Sentinel is not built for a single persona. The developer downloading a model, the platform team building release gates, the researcher testing an LLM app, and the security lead explaining risk all use the same finding IDs.

What Sentinel covers

• Artifact scanning — model files, archives, and model metadata.
• SAST — AI/ML anti-pattern checks across Python and multi-language code.
• Prompt Firewall — prompt injection, jailbreak, and output guardrail checks.
• Supply chain — dependency, HuggingFace repository, and model provenance checks.

Where Sentinel fits in the AI security landscape

Awesome AI Security lists consistently group the field around governance, attack techniques, red teaming, MCP security, model artifact scanning, guardrails, privacy, and supply-chain controls. Sentinel docs focus on the applied evidence layer: scan the asset, close the finding by rule ID, reproduce it in CI/CD, and explain risk through OWASP LLM and CWE language.

• ottosulin/awesome-ai-security
• TalEliyahu/Awesome-AI-Security
• AISecHub Awesome AI Security
• Awesome AI for Security
• Floating Pragma Awesome AI Security

How outputs are used

Use readable tables for local review, SARIF or JUnit in CI/CD, and Markdown/HTML for security reports. The same finding ID stays consistent for engineering and security teams.

Recommended workflow

1. Start with a small known model directory so the team understands scanner behavior.
2. Map rule IDs and severity levels to your release policy.
3. Attach remediation and retest commands to CRITICAL/HIGH findings.
4. Map findings to OWASP LLM, CWE, and your internal risk language.

CLI

The shortest workflow starts with a single artifact scan, then expands to project and CI output.

sentinel artifact model.pt
sentinel artifact ./models/ -f sarif -o report.sarif
sentinel scan ./project/

FAQ

Does Sentinel replace a pentest?

No. Sentinel catches reproducible technical signals; live exploit chains, business-logic abuse, and risk acceptance still require manual security validation.

What search intent does Sentinel answer?

It serves teams searching for AI security scanner, LLM security scanner, prompt injection firewall, model artifact scanner, MCP security scanner, and AI supply chain security guidance.

Which command should run on day one?

Start with a small model directory: `sentinel artifact ./models/`. Then run `sentinel scan ./project/` and move SARIF output into CI.

How should findings be explained to customers?

Use OWASP LLM and business impact in the executive summary; include Sentinel rule ID, CWE, evidence, fix hint, and retest command in the technical appendix.