Concepts
Sentinel documentation connects rule ID, evidence, severity, and remediation into one operating model.
The Sentinel concept model treats finding, evidence, severity, owner, release decision, and closure evidence as one operational risk record.
What is a finding?
A finding is a verifiable signal that Sentinel detects in a file, prompt, manifest, dependency, or runtime configuration. A finding is not always an exploit by itself; it is interpreted with severity and evidence.
Evidence model
- Rule ID — keeps the same finding traceable across reports, CI, and retests.
- Evidence — shows the opcode, regex, AST node, manifest field, or metadata clue.
- Fix hint — gives engineering the first actionable remediation direction.
Risk taxonomy
Sentinel findings are read across three layers: file or code signal, AI/LLM attack surface, and business impact. Unsafe pickle is first a file-format risk, then a supply-chain risk, and finally a code-execution impact on the runner that loads it.
- File or code signal: what did the scanner observe?
- Attack surface: model, prompt, agent, network, container, or secret?
- Business impact: data leakage, code execution, cost blow-up, or release trust?
- Closure evidence: does the same command produce a clean result?
Release decision
CRITICAL and HIGH findings usually block promotion. MEDIUM findings should get an owner and tracking item. LOW and INFO findings are used for hygiene, inventory, and policy tuning.
OWASP AI Exchange threat taxonomy
OWASP AI Exchange classifies threats to AI systems into three categories. Each Sentinel module maps directly to one or more of these categories.
- Threats through use — Covered by Prompt Firewall, Runtime Gateway, and MCP/Agent Security. Prompt injection, indirect injection, and misuse of legitimate tools fall here.
- Development-time threats — Covered by HuggingFace Guard and Supply Chain/AIBOM. Model poisoning, rogue checkpoints, poisoned training data, and dependency vulnerabilities fall here.
- Runtime conventional threats — Covered by API/Dashboard and Runtime Gateway. Authentication issues, rate-limit bypass, unauthorized access, and log manipulation fall here.
The Red Team/Evals module can run targeted probe suites against all three categories and cross-map to OWASP LLM Top 10 2025 categories.
Agentic AI security
In tool-using and multi-step agents, risk is not only the model response; goal hijack, tool misuse, identity scope, memory poisoning, and inter-agent trust also affect release decisions. Sentinel MCP/Agent Security produces verifiable evidence on these surfaces.
- ASI01 — Agent Goal Hijack: attacker-controlled content changes the agent goal or action path
- ASI02 — Tool Misuse and Exploitation: legitimate tools are used for harmful or unintended action
- ASI03 — Identity and Privilege Abuse: agent identity and inherited permissions exceed intended scope
- ASI04 — Agentic Supply Chain Vulnerabilities: MCP servers, tools, prompts, or dependencies are poisoned or swapped
- ASI05–ASI10 — Unexpected code execution, memory and context poisoning, insecure inter-agent communication, cascading failures, human-agent trust exploitation, and rogue agent behavior
How to read AppSec evidence
Sentinel documentation focuses on the evidence teams need for decisions, not a stack of scanner acronyms. Code, runtime, dependency, secret, and infrastructure findings become useful when they connect to the same release decision.
| Control area | Sentinel evidence | Release decision |
|---|---|---|
| Source code analysis | AST node, data flow, dangerous usage, and secret trace | High-risk findings need an owner and remediation PR before closure. |
| Runtime application testing | HTTP request/response, role or tenant scenario, and runtime log | Release stops when exploit impact is confirmed. |
| Dependency and package review | Package name, version, CVE/OSV record, and usage point | A critical package on a production path needs upgrade or explicit exception. |
| Secret scanning | Key pattern, file path, commit, or artifact source | Finding stays open until the key is rotated and blast radius is reviewed. |
| IaC and container review | Manifest field, image digest, permission, and network exposure | Production exposure enters the release gate. |
Governance frameworks
Sentinel findings align with multiple AI governance and security frameworks. Each framework in the table can be used for compliance tracking via finding metadata.
- OWASP LLM Top 10 2025 — Sentinel rule IDs map to LLM categories in SARIF output so teams can quickly see the AI risk class.
- MITRE ATLAS — Adversarial ML threat matrix; tactic and technique IDs (AML.T*, AML.M*) surface in evidence context
- OWASP AI Exchange — Comprehensive control catalog for runtime and development-time threats; Runtime Gateway and HuggingFace Guard map explicitly
- NIST AI RMF — Govern, manage, measure, and mitigate functions; Sentinel findings support the measure and mitigate workflows
- ISO/IEC 42001 — AI management system standard; Sentinel AIBOM output supports ISO 42001 supply chain evidence requirements