Orbis Sentinel

The problem

Two problems at once. The immediate one: after an incident, the findings, the indicators, and the detection rules live in whoever's memory was in the room, and the next incident starts from scratch. The second is newer and less recognised — a developer workstation now runs AI coding agents, MCP servers, and lifecycle hooks that execute code on every turn. That is a real attack surface, with prompt injection, secret exfiltration, compromised MCP servers and over-permissioned agents, and endpoint security, application scanners and network tooling do not look at any of it.

Approach

1. 01

   Kept the whole thing zero-dependency — Node's own HTTP server and JSON on disk — so the security tool does not itself become a supply-chain risk.

2. 02

   Recorded incidents with the exact commands the attacker used and mapped them to MITRE ATT&CK, so each one produces reusable indicators and detection rules instead of a post-mortem nobody reads.

3. 03

   Built a read-only scanner for the agentic surface: every MCP server, lifecycle hook, skill and per-project permission mode, deduplicated by real path.

4. 04

   Organised those findings as See, Govern and Protect — inventory first, then over-permissioned agents and missing deny rules, then remote endpoints and non-first-party local servers.

5. 05

   Made it a control plane rather than a dashboard: hosts run a collector that gathers local posture and reports findings only, so code and secrets never leave the machine.

Outcome

Every finding, incident and detection rule lives in one register that survives the people who were on the call — and the agentic-AI surface, which conventional tooling ignores entirely, is inventoried and scored.

Key decisions

1. 01

   Zero runtime dependencies — Node's own HTTP and JSON on disk

   Instead of: A conventional framework with an ORM and a package tree

   A security tool with a large dependency graph is itself a supply-chain risk. Given this was built in response to a compromise, the tool auditing the estate could not be the least audited thing in it.

2. 02

   JSONL and JSON files rather than a database

   Instead of: SQLite or Postgres from the start

   Volume did not require it, and files keep the data readable without the application. A database can be introduced later if history outgrows the format; the reverse is much harder.

3. 03

   Collectors report findings only, never code or secrets

   Instead of: Central scanning with agent access to each host

   Central access to every machine creates exactly the concentrated target the tool exists to reduce. Sending findings outward keeps the blast radius on the host.

In short

Why do AI coding agents and MCP servers need their own security scanning?

Because they are code execution that arrived without going through any of the usual gates. An MCP server runs with your privileges and can reach whatever you can reach. A lifecycle hook executes on every turn, silently, which is persistence by any other definition. An agent set to auto-approve will accept whatever a prompt-injected page tells it to do. None of this is visible to endpoint security, which sees a trusted editor; to application scanners, which see no vulnerable dependency; or to network monitoring, which sees ordinary HTTPS. The scan is deliberately read-only and local: inventory what is installed, flag what runs with too much authority, and flag what talks to somewhere else. Knowing the surface exists is most of the work.