1. The problem: too many alerts, not enough attention
A scanner can easily produce hundreds of lines. That doesn't mean each one deserves an interruption. The real product has to answer three questions: is this real, does it matter right now, and can we fix it without breaking something else?
Agent Security was designed as a cross-cutting cockpit — a place independent of the applications it monitors, capable of covering multiple GitHub accounts and organizations without needing unlimited access.
2. What's working today
- Four deterministic engines: Gitleaks for secrets, OSV-Scanner for dependencies, Trivy for vulnerabilities and configurations, Semgrep Community for dangerous patterns.
- Four scan depths: targeted PR checks, lightweight weekly audits, monthly deep scans, and quarterly adversarial reviews.
- Multi-GitHub: each account or organization is a distinct trust domain, with its own installation and an explicit list of repositories.
- Memory: each finding gets a stable fingerprint; the system knows whether it's new, recurring, resolved, or reopened.
- Explainable priority: severity, repository criticality, scanner confidence, sensitive area, and recurrence all feed into the score.
- Cockpit in HL-OS: global score, per-project dial, date, link to evidence, fix status, and a red → green readout.
- Controlled AI: OpenRouter analyzes only minimized metadata under Zero Data Retention. A second — and if needed, a third — model from a different family validates uncertain cases.
3. The protections don't rely on the AI's goodwill
- Minimal permissions: the audit agent reads metadata, content, PRs, and Actions — nothing more.
- Explicit allowlist: no automatic enrollment of all private repositories.
- Isolated credentials: compromising one GitHub domain must not open up the others.
- Secrets out of the code: keys and credentials live in GitHub Secrets, never in the repository.
- Reproducible chain: sensitive Actions are pinned to immutable SHAs; tools are verified and updated via PR.
- Deterministic verdict: no model can single-handedly flip a HIGH or CRITICAL finding to "OK."
4. What we borrowed — and what we did differently
Blume inspired the experience: an immediately readable global posture, a per-project dial, and a before/after history. The goal isn't to replicate its product — which focuses on agent observability — but to apply that same clarity to repository security.
Detail.dev inspired the product logic: finding bugs is easy, picking the ones that matter is hard. That's where finding memory, contextual priority, and — eventually — learning from accepted or rejected fixes come in.
Agent Security's structural differentiator comes down to its trust boundaries: reproducible open source scanners, isolated access, verdicts that are independent of LLMs, and a separate fix agent.
5. Spotting a vulnerability isn't enough — you need a fix loop
The first agent observes. Agent Security Fix, installed separately, prepares a plan or a draft PR. The main branch is never modified directly. The fix has to bring its own evidence: tests, a new scan, and a limited diff.
When a fix is ambiguous, multiple models from different families review it. If they disagree, the system keeps the most cautious risk assessment and asks for more evidence. The long-term goal is to allow auto-merge only for low-risk, reversible, fully validated changes.
6. What isn't presented as done yet
- Automated remediation doesn't cover all finding families yet.
- Secrets, authentication, payments, permissions, infrastructure, and migrations remain off-limits for auto-merge.
- Adversarial analysis still needs to be enriched with dynamic tests: authorization checks, webhook replay, SSRF, path traversal, and fuzzing.
- Learning from fix turnaround times and team decisions is a product direction — not a capability being announced as ready.