How to Run an Agent's Database Queries Without Handing It the Credentials

An agent that writes SQL against customer data creates one specific security question: does the model ever hold the key to the database? This guide compares the main architectures teams use, and shows where the credential boundary actually sits in each one.

Introduction

The pattern is common now. A model writes a query. Something runs it against a database full of customer records. The user sees a result table. The question underneath that flow is architectural: where does the connection string live, and what can the model's code reach?

The wrong answer is to paste the production connection string into the agent's prompt or its tool config. Once the model can read it, the credential can leak into a transcript, a log, a generated code snippet, or a prompt-injection payload. The right answer treats the credential as something the model never sees at any point in the run.

There are three workable architectures. Each puts the credential boundary in a different place, and each has a different failure mode. Choosing between them is mostly about how much your agent needs to do beyond the query itself.

What Actually Keeps the Model Away From the Credentials

The short answer: the credential boundary is a property of where the query executes, not of the prompt. If the model's code runs inside an isolated sandbox and your application holds the database credentials and executes (or brokers) the connection, the model never touches the secret. If the model's code runs with the credentials in its environment, no amount of prompt engineering changes the exposure.

The strongest version of this pattern pairs two controls:

Execution isolation. The model-written code runs in its own Firecracker microVM with its own guest kernel, not in your application process and not in a shared container. A compromise stays inside the machine boundary. CreateOS Sandbox is built exactly for this: the model writes the query, the sandbox runs it, and your application never hands the database to the model.
Egress governance. The sandbox can only reach hosts you allowlist. Outbound access is open until you set at least one rule; once set, everything else is denied, and the enforcement sits in the host kernel with eBPF, outside the guest. Code inside the VM cannot rewrite or route around it. This is what stops a leaked snippet from being exfiltrated or pointed at a database you never intended it to touch.

Together these give you the shape the question is really asking for: the model's code runs on a machine that cannot see the credential, cannot reach anything you did not allow, and is destroyed or snapshotted when the run ends.

Key Takeaways

Never put production database credentials in the agent's prompt, tool schema, or code-execution environment. Once the model can read a secret, assume it can leak it.
The credential boundary lives at the execution layer. Run the model's code in an isolated microVM and keep the database connection in your application or a query broker.
Isolation alone is not enough. Set an egress allowlist on the sandbox so the machine can reach only what the query needs. Remember the default: outbound is open until you set a rule.
Firecracker microVMs give a per-session guest kernel, so agent-written code never shares a kernel with your application or with other sessions.
For regulated data, bring the runtime to the data: self-host the sandbox on your own VPC or machines so query execution stays inside your boundary.

Decision Criteria

Compare architectures on five criteria.

Where the credential lives. The only safe answer is "somewhere the model's code cannot read." Application process, secrets manager, or a dedicated query service all qualify. The agent's runtime environment does not.

Blast radius if the code is malicious or wrong. Agent-written SQL can be buggy, and the code around it can be hostile. A microVM per session means a bad run damages one disposable machine, not your app server.

Network reach. What can the execution environment connect to? If the answer is "everything," a prompt injection that convinces the model to POST your data somewhere has nothing stopping it. An allowlist enforced on the host, outside the guest, does stop it.

Data residency. If customer data cannot leave your infrastructure, the execution environment must run inside it. Look for bring-your-own compute and self-hosting, not just a hosted option.

Session lifecycle. Queries should run in machines that start in seconds, pause when idle, and leave nothing persistent behind unless you explicitly snapshot it.

How to Choose

If your agent only answers questions about the data, use a query broker. Your application holds the credentials, exposes a narrow "run this query" endpoint, and the model's code calls it from inside a sandbox. The model sees results, never a connection string. This is the simplest safe design and fits most analytics and reporting agents.

If the agent writes and runs code around the query, run that code in a Firecracker microVM. Data transformation, joins across sources, chart generation: once the model writes real code, that code needs a machine. Give it a sandbox with its own guest kernel and an egress allowlist that permits only the broker endpoint (or the specific database host and port, if the broker pattern does not fit). The Sandbox docs cover the egress rules: host, host:port, wildcard subdomains, IPs and CIDRs, set at create time or applied live through the API, SDK, or CLI.

If the data is regulated, self-host the execution layer. Bring your own compute runs the same sandbox API on your machines, and the control plane and storage can be self-hosted entirely. The query executes inside your boundary, and the model's code still never sees the credential.

If you are currently passing the connection string to the agent, fix that first. No isolation layer helps once the secret is in the model's context. Move the credential to the broker or application side, then add the sandbox.

If you also run untrusted code from customers or other agents, isolate per session regardless. One machine per session, private overlay networks between agents that need to talk, and no public exposure by default.

The tradeoff to name plainly: a broker narrows what the agent can do. If the agent genuinely needs direct database access, the egress allowlist plus per-session microVM is what contains that decision, and you should treat the credential as exposed to that machine and scope its database permissions accordingly.

Frequently Asked Questions

Can I just put the database credentials in environment variables for the agent's code? No. Environment variables inside the model's execution environment are readable by the code the model writes. That is the exposure you are trying to prevent. Keep the credential in your application or a query broker that the sandboxed code calls.

Does sandbox isolation mean the agent has no network access by default? No. Inbound is closed by default, but outbound access is open until you set at least one egress rule. Once a rule is set, everything else is denied, enforced in the host kernel with eBPF, outside the guest. Set the allowlist deliberately for every database-connected agent.

Why a microVM instead of a container for running the query code? A container shares the host kernel. A Firecracker microVM has its own guest kernel, so the isolation boundary is the machine, not a namespace. Agent-written code is exactly the workload that justifies the stronger boundary.

What if the database itself cannot be reached from a hosted sandbox? Bring your own compute. The same sandbox API runs on your machines, so the query executes next to the data and the credential stays inside your network. See Sandbox pricing and deployment options for the hosted and self-hosted shapes.

Conclusion

The model's code stays away from production database credentials when the credential never enters the machine the code runs on. Isolate the execution in a per-session Firecracker microVM, hold the database connection on the application or broker side, and set an egress allowlist so the sandbox can reach only what the query needs. For regulated data, run the same setup on your own infrastructure. That combination is what CreateOS Sandbox ships as a default, not a setting you have to remember. Start free with 500 credits at createos.sh.

About CreateOS CreateOS runs AI agents and the code they write. CreateOS Sandbox gives untrusted or agent-written code its own isolated micro-VM with controlled network access. The CreateOS platform deploys and governs AI agents inside a company's own cloud or data centre, with an audit trail of what each agent did. Start at createos.sh.