Every Agent is a Database User

Key Takeaways

• An agent is a login – Strip away the vocabulary and an AI agent reaches your data the way everything else does: through a credential, with whatever permission that credential carries. The question is thirty years old. The thing asking it now acts at machine speed.
• The registry is the easy part – The platforms will tell you which agents exist. What each may read, change or delete inside a database was decided by whoever granted the login – and in most estates that decision was never taken deliberately.
• Non-human identities already outnumber you – Forty-five to one, one in twenty with full administrative rights, half of organisations unable to say who owns them. Agents arrive on top of service accounts nobody has reviewed.
• The prompt is not a control – A production database and its backups were deleted in nine seconds this April because a token could; the agent’s instructions said it should not. Permission decided the outcome: there a platform token, in your estate the login on the database.
• Four questions need no new platform – Which non-human identities reach each database and who owns them; what each can write, not only read; when each access expires; who reviews the log. A board can ask all four this quarter.

Microsoft Ignite opens in San Francisco on 17 November, and one subject runs through its security programme. Agents, Microsoft says, are “your newest insiders”; they “now act with real access to your identities, your data, and your cloud”, and “every adoption decision is a trust decision”. The sessions ask whether access controls are ready for agents at scale, and whether you can find those running on staff laptops.

The conversation about AI agent governance is the right one, and it is being held one layer too high. At the database an agent is not a new kind of thing. It is a login.

Whether it connects directly or through an application, it arrives at the engine as a login – its own, or the application’s, which is usually worse – and it is served exactly as a person at a keyboard would be, with whatever permission that login holds. The question has sat on a DBA’s desk for thirty years. What is new is the speed – and that most estates never answered it for the logins they already had.

Three Hundred and Seventy-Five

South Africa is not starting from a clean estate. The Information Regulator received 1,220 security-compromise notifications in the first five months of this financial year – roughly 240 a month, with more than 3,000 projected – and attributes them to weak passwords, human error and “inadequate security controls”. Sophos’s study of 135 South African organisations hit by ransomware found that in 85 percent of cases the attack and the organisation’s most serious identity compromise were the same event.

The credential is already how data leaves this country. An agent is another credential.

October gave the point a number. A pathology laboratory group disclosed an attack; the attacker claimed to have copied ten of what it said were roughly 375 databases, one admissions table alone holding more than 80 million records. The group’s own statement was measured and, I think, accurate: the figure counts records, not patients; no clinical results appear to have been taken; an application vulnerability has been fixed.

If the count is even roughly right, it is an ordinary one for an organisation of that size – which is the point.

How many boards could say which logins reach each of theirs?

Newest Insiders

Microsoft has already described what Ignite will put on stage. Its identity leadership wrote in October that an agent should start with no authority and receive only what the approved task needs, scoped and time-bound, with higher-impact actions held for a verified human. It does not inherit the permissions of the employee who sponsors it. Assume it can fail or be compromised, and build controls that do not depend on the model behaving.

The practitioner guidance Microsoft published in July is more specific. Treat every agent as a principal in its own right, with a dedicated identity rather than a shared secret or a reused service account. Separate what it may read from what it may write.

Prefer short-lived elevation to standing access, because “temporary access that lacks an expiry mechanism becomes permanent access in practice”. Log the agent, its scope and the person it acted for, because “logging only the LLM response creates an audit trail that looks present but is useless for forensics”.

Every one of those is a permissions sentence – a login, a role, a grant, an expiry, an audit. None of it is new to anyone who has run a database estate. In the estates I see, almost none of it has been done.

One preview of Ignite put the gap precisely: “an agent registry is the easy part; deciding what each agent is allowed to see is where the work sits”. That decision is taken where the data is, by whoever holds the keys to the engine – usually years ago, for something else.

Forty-Five to One

The Cloud Security Alliance collected the numbers in May. Non-human identities – service accounts, API keys, integration logins, and now agents – outnumber people forty-five to one in the average enterprise and 144 to one in cloud-native estates. One in twenty holds full administrative rights. Half of organisations cannot say who owns their AI or agent identities; 78 percent have no documented process for creating or retiring them. The paper’s own summary of the lifecycle problem: “The agent is gone; the credential is not.”

Agents are joining that population fast – active agents in Microsoft 365 are up fifteen-fold in a year, on Microsoft’s own telemetry – and Gartner expects 40 percent of enterprises to have demoted or decommissioned autonomous agents by 2027 because of governance gaps found only after a production incident. Found, that is, the way most permission problems are found.

Nine Seconds

The reference incident of the year is small, well documented and entirely about permission.

In April a start-up’s coding agent hit a credential mismatch in a staging environment and set about fixing it. It found an API token in an unrelated file, “guessed” – its own word afterwards – that deleting a storage volume would be scoped to staging, and called the delete endpoint. The volume held the production database and its backups. “It took 9 seconds,” the founder wrote. The token had been created to manage custom domains; the platform offered no way to narrow it, so it could do anything.

The agent’s instructions – the tool’s system prompt and the project’s own rules – said no destructive action without asking. It acted anyway, and admitted as much. The hosting provider’s chief executive put the other side with a candour I respect: “if you (or your agent) authenticate, and call delete, we will honor that request.” The data was restored within the hour once he stepped in, and the legacy endpoint the agent had called, which lacked the delayed-delete safeguard the provider’s newer ones carry, was patched within days.

The lesson had already been taught.

A prompt is a policy the model is asked to enforce. A permission is a policy the system enforces for you, every time, at any speed. When the two disagree, the permission wins – which is why governance has to live there.

There is more than one such place. The permission that matters sits wherever the data can be reached – the login on the database, the identity the application connects with, the platform token that can delete the volume underneath it all. The database is the last of these, and the one most estates have never reviewed.

I have seen the same shape for years without an agent anywhere near it. An application login created in 2014 as db_owner because the installer asked for it, still db_owner on the database that now holds every customer’s identity number. A scheduled job running as sysadmin because it always has, owned by a consultant who left in 2019. A service account whose password sits in a configuration file the whole company can read, used by three systems, one of them decommissioned.

Point an agent at that estate and you have not introduced a new risk. You have introduced a user who never sleeps to a privilege nobody has reviewed.

The right pattern exists and is not exotic. The best demonstration I read this year was a database administrator building an agent to diagnose a SQL Server estate: a login with view-server-state and read rights only, an allowlist every statement must pass before it reaches the engine, and one standing instruction – “You detect and report; you never remediate.”

“The model never touches the database.” Every control in that design is enforced outside the model – a login, an allowlist, a human in the path for anything that changes state. It is April’s lesson, built in from the start.

On Whose Behalf

A permission settles a second thing: accountability. Here the agent complicates matters.

When an agent acts under a person’s delegated access, the log shows the person. When it acts under a shared service account, the log shows the account. In neither case does anyone later know whether a human decided or software decided on their behalf – the distinction Microsoft’s own guidance insists the audit trail must preserve.

King V asks the board for human oversight and override of AI. POPIA is blunter: for processing it decides on, the responsible party is the organisation. Not the vendor, not the model, not the agent.

After an incident nobody asks what the software recommended. They ask who approved what it did – and at the database that answer is a grant with a name on it, or it is nothing.

Gartner’s four levels of agent autonomy – observe, advise, act with approval, act autonomously – map almost exactly onto database privilege: read only; read and propose; write with a human in the path; write freely. Most of the estates I have looked into grant the fourth level to things that needed the first. The fastest test is to list every login that is not a person and ask what each can delete.

Four Questions

None of this waits for a platform announcement. A board, or the committee it delegates to, can ask four questions this quarter and expect answers within a month.

Which identities that are not people can reach each database holding personal information, and who owns each one? The list will contain service accounts, integration logins, scheduled jobs and reporting connections before it contains a single agent, and the owner column will have gaps.

What can each of them change, not merely read? Anything that is not a person and holds sysadmin, db_owner or the equivalent needs a reason in writing, and most will not have one.

When does each access expire? Standing access with no end date is, in Microsoft’s phrase, permanent access in practice. Agents given task-bound credentials by design may end up better governed than the integrations installed a decade ago.

Who reviews the log, and does it record on whose behalf the action was taken? A log that shows only the account answers no question an incident will ask.

Ignite will bring registries, conditional access for agents, risk scores that move with behaviour, and sandboxes that keep the controls out of the model’s reach. Every one of those instruments assumes that, at the end of the chain, someone has set the permission on the database correctly. That someone is the customer, and the work does not wait for a keynote.

Agents are already in the data. The question in eighteen months is, for each one, what it was allowed to do – and whether that was the same as what it could.

The Last Word

I have spent my working life around database estates, and the pattern has not changed in thirty years: access is granted in a hurry and reviewed never. Agents will not change the pattern. They will run it at machine speed.

The organisations that treat every agent as the database user it is – a login with an owner, a scope, an expiry and a log – will adopt agents faster than the ones waiting for a platform to do it for them, because they will have an answer when the Regulator’s question arrives. Who had access, and who approved it.

Also See

> AI Readiness Is Data Readiness
> Data Sovereignty in South Africa Is Not an Address
> Database Administration and Support Service (DB Admin)

By: Johan Lamberts