Loading today’s stories
Build1 distinct publisher2 min readUpdated
A maintainer's walkthrough shows sentinel-scan-cli reporting 10 HIGH findings and still exiting 0. The ten-line wrapper that fixes it is also where the policy decision quietly lives.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
Follow any of these and your For You feed starts watching them — no settings page required.
Both demo numbers are fixtures. The 3-of-15 injection result comes from the CLI's own mock target, and the 18 MCP findings come from a seeded-vulnerable manifest that ships with the package [3][4]. What they prove is that the harness runs and that the JSON is shaped the way a gate needs, not that anything in your repository is on fire.
The consequence for anyone who already added this to a workflow is more concrete. If the step is a bare scanner invocation and the pipeline trusts the shell's default, that step is green right now while printing HIGH-severity findings into its own log [7]. The structured JSON file is the only channel that carries a verdict a machine can act on [9], and reading it is work someone has to do on purpose.
The taxonomy is worth an adding-up. The ten heuristic counts in the MCP summary sum to exactly 18, matching the reported total [15], so nothing lands in an unclassified bucket. The largest single bucket is excessive_agency_schema at 4 [18], which is a schema problem rather than a text problem: no amount of prompt hardening moves it. The HIGH examples the author lists span four separate OWASP categories, covering prompt injection, excessive agency, sensitive information disclosure and supply chain [6]. A single severity threshold treats an unpinned remote source and a poisoned tool description as the same event, which is fine for stopping a merge and useless for routing the fix.
The injection half sits on a different footing again. The author's own phrasing is that 3 of 15 attacks "got past this system prompt" [3], and the suite needs a live endpoint to run against [11]. That makes it a test whose result can change with nothing in the diff: a provider-side model update, or an edit to a system prompt held outside the repo, flips yesterday's pass without a commit. A pull-request trigger will never observe that. A scheduled run against staging will.
Which leaves the pre-commit half doing less than the headline suggests. The static manifest scan runs anywhere because it makes no network calls [11], so it is a reasonable local hook. The 15-attack suite is not, unless developer laptops can reach a deployed model, and most cannot. The honest split is a blocking static check on every PR and a scheduled endpoint check that pages someone, and the maintainers' own disclosure of the exit-code gap [2] is the more useful contribution here than the workflow YAML.
Ranked by verification strength, evidence, and original report placement.
The walkthrough wires both scanners into GitHub Actions and pre-commit as a CI gate that fails the build, and includes a gap the author found in the CLI itself plus the fix; the author states all command output shown is from real local runs and not fabricated.
In the prompt-injection demo run against the CLI's built-in mock target, 3 of 15 attacks got past the system prompt: story_injection (LLM02: Sensitive Information Disclosure), prompt_leak_direct (LLM07: System Prompt Leakage) and markdown_exfil (LLM05: Improper Output Handling), each with a literal secret leaked.
The MCP demo scan of the CLI's built-in seeded-vulnerable manifest reported 5 tools and 2 servers scanned with 18 findings: 10 HIGH, 6 MEDIUM and 2 LOW.
The MCP scan is pure static analysis with no network calls, so it can run on every PR unconditionally, while the prompt-injection scan needs a live LLM endpoint and only makes sense once a staging deployment exists that the runner can reach.
The post's authors describe sentinel-scan-cli as a free, zero-dependency scanner comprising a 15-attack prompt-injection suite run against your own LLM endpoint and a static MCP manifest scanner for tool poisoning and excessive agency, both mapped to the OWASP LLM Top 10 (2025).
The MCP demo findings_by_heuristic breakdown was: tool_description_injection 1, hidden_unicode_instructions 2, excessive_agency_schema 4, missing_hitl_confirmation 2, overbroad_tool_scope 1, tool_name_shadowing 2, hardcoded_credential 1, unpinned_remote_source 2, indirect_injection_surface 1, missing_provenance 2.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Reproducible transcripts, single self-interested source
The post supplies unusually checkable artifacts for its central claims: full console and JSON output, the gate.py source, the workflow YAML, and a verification transcript showing exit status 1. The internal arithmetic holds (the ten heuristic counts sum to the reported 18 findings). But every number originates from the maintainer's own local runs against fixtures the tool ships, there is no second publisher or independent reproduction in the cluster, and the broader assertion about how other scanners handle exit codes is unsupported. One documented discrepancy exists between the ledger's account of the workflow path filter and the YAML as published.
No usage signal beyond vendor demo runs
The supplied source reports no downloads, dependent repositories, third-party pipelines, customers or deployments. The only observed activity is the maintainer running the CLI's own demo fixtures and a sample workflow file; that establishes the tool executes, not that anyone has adopted it. No adoption value can be assigned without inventing facts.
Slightly understated relative to what is shown
Claims are narrow, mechanical and mostly demonstrated rather than promised, and the author volunteers the least flattering fact about his own tool - that both scans exit 0 while reporting 10 HIGH findings and 3 successful injections - before offering the fix. That candour pushes the story marginally below neutral. It is not more negative because the fixture-derived numbers are presented with headline prominence despite coming from a seeded-vulnerable manifest, and because the unsupported claim about scanners in general does modest inflationary work.
Maintainer promoting own tool, disclosed
The author states outright 'We maintain sentinel-scan-cli' and the post functions as an install-and-integrate funnel for that CLI, including the pip command and a ready-to-copy workflow. That is a strong commercial or reputational incentive to present the tool favourably. It is mitigated, not removed, by explicit disclosure of maintainership, by the choice to publish the tool's own CI weakness, and by the absence of any paid tier or upsell in the supplied text.
Internally consistent, single-source, unverified externally
Confidence is moderate: the mechanics of the story - JSON output, threshold wrapper, exit codes, static-versus-live scan placement - are well evidenced and internally consistent, so the practical takeaway is dependable. Confidence is capped by there being exactly one publisher, that publisher being the tool's maintainer, no adoption data, one contested detail about the workflow trigger, and no way to judge the scanner's heuristic quality on real manifests.
build
Rate limit your MCP servers, because a retrying agent turns one error into a billing incident1 distinct publisher
product
A 2x LLM bill is not a bug report: token spend is an observability problem1 distinct publisher
build
The Slack CLI that skips admin approval keeps live tokens in a file your agent can read1 distinct publisher
build
Thirty minutes a day, and none of it from letting the agent write Swift1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 23, 2026