The problem
Most identity governance ends at a finding. A stale key gets flagged, a review gets completed, a PDF gets filed, and the risk itself is still live. Next year's audit finds the same key.
The estate has also changed shape. Service accounts, API keys and AI agents now outnumber people by a wide margin, and most governance tooling was designed around the people. The identities that nobody owns are exactly the ones that never make it into a review.
The idea
NDGM treats governance as a loop rather than an annual event: discover every identity, classify it (type, owner, risk, actual access), govern it with reviews, enforce the outcome, and prove what happened. Then run it again.
The step that matters is the fourth. Enforce means rotating the credential, vaulting the secret or revoking the access that shouldn't be there, so a finding ends as a fix rather than a ticket. Every enforcement action waits for a person to approve it.
How it's built
NDGM runs single-tenant on dedicated UK infrastructure behind Cloudflare. Isolation is enforced in the database, not the application: every query is scoped to one organisation by Postgres row-level security. Five roles (super admin, org admin, reviewer, auditor, viewer) decide who can see and change what, and auditors can read but not change.
Every write emits a matching audit event, and every governance decision writes two records at once: a checksummed evidence item and an immutable audit entry. Evidence packs for an auditor are built from those records rather than assembled by hand afterwards.
Reeve, the agent
Reeve watches the identity graph. When it finds an orphaned service account or an ageing credential, it triages it with a model running locally, opens a job with its reasoning and a confidence score attached, and acts only once someone approves: assign the owner, rotate and vault the secret, open a review.
A lightweight edge agent covers what cloud APIs can't see: keys in .env files, private keys on disk, and the AI tools and MCP servers running inside an environment, each of which is a non-human identity with real credentials. It reports metadata only, over an outbound-only connection, and never moves the secret itself.
Where it doesn't fit (yet)
NDGM is early. It is recruiting UK design partners, and the estate it governs day to day is its own, about 400 identities, so large-enterprise scale is still to be proven in production. Connector depth varies by system, and anyone evaluating it should check the specific platforms they depend on rather than a headline count.
Local models keep data inside the boundary but are smaller than the frontier models, which is one reason Reeve recommends and people decide. NDGM is not a replacement for a PAM vault either: it integrates with one to rotate and store secrets. And self-hosting, the sovereign option, means someone has to run it.
What I took from it
Finding identity risk is the easy part. The hard parts are ownership (someone has to be accountable for every account and key) and the last step, where a fix touches production. That is why the loop is built around approval gates and evidence rather than automation for its own sake: a governance tool has to hold itself to the standard it asks of everyone else.
