Documentation
Trust scores
How Sentinel calculates trust scores — the penalty-model rubric, exact weights, certification tiers, and what they mean for buyers and sellers.
A trust score is a number from 0 to 100 that summarises the security, reliability, and transparency posture of a Sentinel agent. Every score is produced by the same versioned, deterministic rubric, so scores are comparable across agents. The current rubric is v1.1.
How the score is computed
Sentinel uses a penalty model, not a weighted sum. Every agent starts at a perfect 1.0 and each verification signal can only deduct from that score:
score = 1.0
score -= (penalties from each stage)
score = clamp(score, 0.0, 1.0) # never below 0 or above 1
display_score = round(score * 100) # the 0–100 number you see
This makes the score transparent and monotonic: a clean agent scores 100, and every deduction maps to a concrete, disclosed finding. The internal score is a float in [0.0, 1.0]; the displayed score is round(score × 100).
Penalty weights (rubric v1.1)
| Signal | Condition | Deduction |
|---|---|---|
| Static analysis (SAST) | any critical finding | −0.30 |
| Static analysis (SAST) | high findings (no critical) | −0.02 each, capped at −0.10 |
| Supply-chain (CVEs) | any high-or-worse advisory | −0.20 |
| Committed secret | any critical secret | −0.30 |
| Committed secret | any high secret (no critical) | −0.15 |
| Code quality | high complexity/maintainability | −0.03 each, capped at −0.10 |
| AI code review | any critical finding | −0.15 |
| AI code review | high findings (no critical) | −0.03 each, capped at −0.10 |
| Dynamic analysis | stage failed | −0.20 |
| Red-team evaluation | stage failed | −0.20 |
| Conformance | high finding | −0.10 |
| Conformance | medium findings (no high) | −0.02 each, capped at −0.10 |
Penalties are per-stage: a finding only ever triggers the penalty for the stage that produced it (a supply-chain CVE never triggers the static-analysis penalty). The overall finding counts shown in a report are the union of all stages, counted once.
Deferred stages are never penalised
Some stages depend on infrastructure that may be unavailable — for example, dynamic detonation and live red-team require the execution runtime, and AI review requires a model key. When a stage cannot run, it is marked deferred, not failed: it deducts nothing, and the report discloses it in public_summary.stages_deferred so a badge never claims coverage it did not actually achieve. Only a genuine failure of a stage that did run deducts points.
Certification tiers
The final score maps to a certification tier:
| Tier | Score (0–1) | Displayed |
|---|---|---|
certified_managed | ≥ 0.90 | ≥ 90 |
certified | ≥ 0.75 | ≥ 75 |
provisional | ≥ 0.50 | ≥ 50 |
uncertified | < 0.50 | < 50 |
An uncertified agent is not eligible for the marketplace listing gate.
What the score means for buyers
- 90–100 (
certified_managed): No critical/high findings and every stage that ran passed. Safe for production; review any low/info findings. - 75–89 (
certified): No critical findings; at most a few capped deductions. Suitable for production after a quick read of the open findings. - 50–74 (
provisional): One high finding or several capped medium deductions. Read the full report before deploying in a security-sensitive context. - Below 50 (
uncertified): Not recommended for production — significant unresolved findings, or a critical finding.
Because deferred stages are disclosed, always check stages_deferred on the report: a high score with dynamic/redteam deferred means those lanes have not yet run (they run once the execution runtime is available).
How to read a report
The score is served with two views:
- Public summary (
GET /reports/{agent_id}/badgevia the gateway): score, cert tier, critical/high counts, andstages_deferred. - Full report (
GET /reports/{agent_id}): per-stage results and finding counts.
Every report is stamped with its rubric_version and, when signing is enabled, an Ed25519 signature so consumers can verify the score was produced by Sentinel and not tampered with.
How sellers improve a score
| Action | Effect |
|---|---|
| Remove committed secrets (keys, private-key blocks) | Removes the −0.15/−0.30 secret penalty |
Fix critical/high SAST findings (eval, injection, etc.) | Removes up to −0.30 static penalty |
| Upgrade vulnerable dependencies | Removes the −0.20 supply-chain penalty |
| Reduce cyclomatic complexity of hot functions | Removes up to −0.10 code-quality penalty |
| Address a red-team jailbreak / prompt-injection catch | Removes the −0.20 red-team penalty |
Expose a working /health + /invoke contract | Avoids the conformance penalty |
Rubric versioning
The rubric version is recorded on every trust report (currently v1.1). A change to any weight or threshold ships as a new rubric version and is shadow-run against existing agents before it takes effect, so scores never move without a corresponding, published rubric change.
:::note Roadmap
Continuous re-verification (score decay + periodic re-check), a public score-history API, trust_score.updated webhooks, and an externally-fetchable rubric endpoint are planned and not yet generally available. This page documents the rubric as it is implemented today; see the roadmap for what is coming.
:::