Why an AI Agent Needs More Than Database Access

The demonstration that misleads

Give a language model read access to a copy of an operational database and it will produce a fluent, plausible and frequently wrong answer within a minute. It will describe a customer as active when the account has been dormant for a year, total a contract value using the renewal terms of a superseded version, and report revenue for a period in which the definition of revenue changed twice. Nothing in the response signals a problem, which is what makes it dangerous.

The reason is not model capability. A schema is a description of where values are stored, and nothing more: it does not say which of two columns is authoritative, what a status value means, which historical state applies to a question about the past, who is entitled to see a record, or what the business considers acceptable. An agent given only a schema is a very fast reader working without the manual.

This matters more as the agent's role grows. A system that only answers questions produces a wrong sentence, which a person catches. A system that writes to an order book, adjusts a credit limit or releases a payment produces a wrong action, which somebody discovers later. The gap between the two is not intelligence; it is context, authorisation and control.

Seven things beyond the connection

For any agent intended to act on enterprise systems, these seven are the minimum, and each answers a question the schema cannot.

• Context: entity definitions, so that 'customer' means one thing and the authoritative field is known.
• Authorisation: a per-entity access rule, resolved at execution time against the acting identity rather than assumed from the service account.
• Business rules: the conditions and thresholds under which the business is permitted or required to act, held outside the prompt.
• Tool access: a defined set of operations with typed inputs, rather than arbitrary query execution.
• Validation: preconditions checked before a write, expressed as assertions that fail loudly.
• Error handling: defined behaviour for a partial failure, a timeout or a conflict, including whether to retry, escalate or reverse.
• Bounded execution: a limit on steps, volume, spend and blast radius, plus a human approval point before anything consequential.

The distinction between the fourth and the seventh items is the one most often missed. Tool access determines what is possible; bounded execution determines what happens when the model is confidently wrong at three in the morning with a batch job running. The second is what makes the first deployable in a regulated process.

Where a database connection is genuinely the right answer

There are cases where the simple design is correct, and refusing to build the extra layers for those is a sign of judgement rather than excess. Exploratory analysis over data the user is already entitled to see, where the output is a chart or a draft answer that a person reviews, and where no write occurs anywhere, is adequately served by read access plus a good data dictionary.

It also helps to name what should not be a model decision at all. Arithmetic over large volumes, deterministic eligibility checks, totals and reconciliations, and anything that must be reproducible exactly are all better done in code. The reasoning behind that division is set out in when to use AI, rules or conventional automation.

Authorisation is the part that is usually skipped

The most common failure in this list is permission, because it is the item that requires an organisational decision rather than an engineering one. An agent that runs under a single service identity inherits that identity's reach, which in most enterprises means far more than the person who asked a question is entitled to see. The result is either that the agent is throttled to the point of uselessness, or that it answers questions the asker could not have asked themselves.

The workable pattern is to resolve access per entity at execution time against the identity that initiated the request, record the resolution with the action, and fail closed when no rule matches. Writing those rules is unavoidably a business exercise: the entitlement to view a price, to see a customer's contact details, or to trigger a refund is a policy, and nobody has written it down. Discovering that is a useful output of the project even when the agent never ships.

The sequence that gets an agent to a state you can deploy

1. Publish the entity definitions the agent will read, with a named owner each, so that context is a versioned artefact rather than prompt text.
2. Expose the operations the agent may perform as typed tools, and refuse the ones nobody has an opinion about.
3. Encode the business rules that gate those operations, each with the condition and the outcome stated separately.
4. Attach the entity-level permission model and resolve it at run time against the requesting identity.
5. Add preconditions as executable assertions, so an invalid write fails at the boundary rather than after it.
6. Define partial-failure behaviour explicitly, including which operations are reversible and how reversal is initiated.
7. Set step, volume and cost limits, and place a human approval point before the first consequential action.

Steps three to seven are the difference between a demonstration and something a risk function will approve. They are also the work that compounds: the rules, the permissions and the tools are reusable across every agent the enterprise subsequently builds, which is the argument for building them once rather than per project. The prerequisite conditions for that work are assessed in the enterprise data readiness checklist for AI projects, and the operating discipline that keeps it true over time is described in deployment and governance for enterprise AI.