A database account that can read invoices is very different from one that can delete them. The distinction becomes urgent when software agents are given tools that act on a user’s behalf. An agent asked to summarize overdue payments may need access to a reporting view. Giving it broad write privileges would expose the organization to consequences far beyond the reporting task.
Tool-using AI systems can perform useful multistep work, including running approved queries and preparing reports. Their access must still be bounded by conventional permissions, independent checks, and human accountability. A persuasive answer from a language model provides no evidence that an action was authorized.
Reading a database is different from changing it
A reporting agent may need read-only access to a limited set of tables or views. It rarely needs administrative permissions. The database account should enforce that restriction itself. A prompt that says “never modify records” is helpful as guidance, but it is not a substitute for database privileges.
Even read access needs limits. Customer records can include sensitive fields that have nothing to do with a revenue report. Carefully designed views or query services can expose only approved columns and rows, while a request boundary restricts which business user’s data the agent may see. Query limits, timeouts, and audit trails help contain mistakes and make their consequences easier to investigate.
What prompt injection changes
An agent may read a web page, document, or support ticket that contains text telling it to ignore instructions and send information to another location. That content is not the user’s authorization. It is untrusted material encountered while doing the task. If the agent treats the document as a command, it may make tool calls its user never intended.
This class of failure is called prompt injection. OWASP’s guidance on excessive agency describes how harmful actions can result when an LLM-based system has unnecessary functions, permissions, or autonomy. The technical design must preserve a boundary between data the model reads and actions the application is allowed to execute.
A database agent should not be able to elevate its own privileges by deciding a task is urgent. It should not receive a broad write credential just because one possible future workflow might need updates. Particularly consequential actions deserve deterministic checks and, often, a human approval step.
Designing an agent with limited authority
A practical starting design is intentionally modest. Define a small set of approved tools, such as “retrieve aggregate sales for a specified period” or “list invoices visible to this user.” Validate tool inputs separately from the model. Authenticate the user and enforce authorization in trusted code. Return bounded results and prevent the agent from executing arbitrary database commands when a constrained query service can do the job.
Test not only normal requests but also ambiguous language, malicious content inside retrieved documents, unexpected tool responses, and an agent that repeatedly fails to complete a task. Logging should support investigation while respecting privacy and retention policies. Operational safeguards should not depend on the model remembering a warning in its instructions.
What the SI Database demonstration does
The SI Database Text-to-SQL lab displays predefined examples and is not connected to customer records. This separation is intentional. A demonstration can teach what a query looks like without holding a database credential or executing arbitrary instructions.
In a production system, begin by listing the exact operations the user has authorized. Give the agent access to those operations through constrained tools, record what it attempts, and require approval for consequential changes. An apparently minor shortcut in permissions can turn a simple reporting feature into an expensive security incident.