You Inventoried Your Non-Human Identities. You Never Asked What They Could Reach.

This is the pillar of the Infozense Non-Human Database Access library. The argument in one line: your non-human identity program inventories the credential and stops at the database door — so nobody can say what those identities can actually read and change. The spokes take one gate at a time.

The connection labelled “Development”

Here is a small thing we measured, because it says everything about the large thing.

When a modern database CLI creates a connection, it labels that connection Development by default. Auto-commit on. Change confirmation off. Those are sensible defaults for a developer poking at a scratch database on their laptop.

Your nightly reconciliation job connects to production through exactly that profile. So does the pipeline that rebuilds your customer table. Nobody chose those settings for production — they are what the tool does when nobody says otherwise, and nobody was there to say otherwise.

Non-human access to your databases isn't badly governed. It is ungoverned by default.

Every control you own assumes a human

Single sign-on assumes a person to authenticate. Ticketed access assumes a person to request and a second to approve. Session review assumes sessions belong to someone with a name. Four-eyes on production assumes two pairs of eyes. Quarterly recertification assumes a manager who can be asked whether this individual still needs this access.

Remove the person and every one of those degrades into a formality. The credential still works. The grant is still there. Nothing revokes itself when the human it was designed around stops being present.

This would be a footnote if non-human connections were rare. They are not. Industry surveys put machine identities at many times the number of human ones in a typical enterprise, and the ratio widens every year. The controls were built for the minority.

Your NHI program stops at the database door

The good news is that this problem now has a name. Non-Human Identity — NHI — appears on CISO priority lists, has a vendor category, and has budget attached. If you have started an NHI program, you are ahead of most.

Now look closely at what those tools do. They discover identities across cloud, SaaS, secret vaults and CI/CD. They tell you an identity exists, who owns it, whether its key is stale, and when it was last rotated. That is genuine and useful work, and it is all about the credential.

None of them answer the next question: once that identity is inside your database, what can it read, and what can it change? An inventory that says “this service account exists and its password is 400 days old” does not tell you it can also delete your customer table.

That is the door. The inventory stops at it, and the blast radius lives on the other side.

You reviewed your staff. You did not review your pipelines.

PDPA obliges you to keep records of how personal data is processed and to demonstrate control over who can reach it. Every organisation that took that seriously ran an access review — and that review covered employees. Names, roles, departments, a spreadsheet signed off by a manager.

Meanwhile the identity that actually reads every customer row, every night, on a schedule, with no session and no reviewer, was never in scope. It has no name, no department and no manager to sign for it.

Your access review is complete — for the minority of your connections.

Where they actually live

Most teams, asked to guess, name three or four. The real count is routinely several times that, because non-human identities are created by whoever needs one, at the moment they need it, and are never created with an end date.

ETL and ELT jobs

The oldest credentials in the estate. Created once, rotated never, because rotation breaks the schedule.

CI/CD pipelines

Run migrations against production, so they usually hold rights to alter your schema.

BI service accounts

Often one shared account behind every dashboard in the company. One credential, everyone's data.

Application database users

Almost always granted more than the application actually does, because it was easier at build time.

Replication and CDC

Broad read plus replication rights by design. Nobody questions it, because it genuinely needs them.

Backup and DR tooling

Read-everything is the entire point, which is exactly why it never gets reviewed.

Third-party integrations

A vendor connects straight to your database. Nobody inside your organisation owns that review.

One-off migration scripts

Created for a project that finished years ago. The account is still valid today.

AI agents and MCP endpoints

The newest, the smallest in number, and the one getting all the attention.

The uncomfortable test

Pick your three most important databases. For every non-human identity connected to them, answer two questions: what can it read right now, and what can it change right now?

If that takes more than a day, the honest answer is that you do not know — and every downstream conversation, including the one about AI agents, is premature. You cannot reason about the marginal risk of a new client when the existing ones have never been mapped.

Mapping them is not a transformation programme. It is read-only, it takes about two weeks, and it needs no new software.