Keeping Production Database Credentials Away From a Query-Writing Agent

The safe pattern is simple: the model never sees the credentials, because the model never gets a network path to the database. The agent writes its SQL inside a sandboxed machine, you set one allowlisted route to the query endpoint you choose instead of leaving outbound open, and the credentials live on the host side of that boundary, not in the prompt, the code, or the machine.

Introduction

An agent that writes and runs queries against customer data is one of the highest-value things you can build, and one of the easiest to get dangerously wrong. The obvious design hands the model a connection string and lets it execute. That design puts production credentials inside a context window, inside generated code, and inside a runtime you do not fully control. One prompt injection later, a query you never approved is running against real customer rows.

The fix is not "trust the model more." It is architectural. The model can write any query it likes as long as it cannot reach the database on its own authority. Separate the three things that usually get bundled together: code the model writes, the credentials that authorize that code, and the machine the code runs on. CreateOS Sandbox is built around exactly that separation: the model writes the query, the sandbox runs it, and your application never has to touch the data in between.

Key Takeaways

Never put database credentials in the agent's context, its code, or its runtime. Put them outside the machine the agent runs on.
Isolation has to be at the machine boundary. A sandboxed process sharing a kernel with your app is one exploit away from your data.
Egress control is the real credential control. If the agent cannot open a connection to anything but the endpoint you named, a leaked string in a prompt is inert.
Network policy should be enforced outside the VM, by the host, so code inside cannot rewrite or route around it.
If the data cannot leave your boundary at all, run the sandbox on your own infrastructure.

Why This Solution Fits

The failure mode with a query-writing agent is not that the model writes bad SQL. It is that the model writes SQL while holding the keys to the database. Three properties close that gap, and each one maps to something CreateOS Sandbox ships today.

First, the agent gets its own machine. Every sandbox is a Firecracker microVM with its own guest kernel, not a container and not a shared-kernel process. Credentials, environment variables, or config files passed into one sandbox are not visible to another, and code inside cannot read anything outside its own guest. Isolation is the default, not a setting someone has to remember.

Second, the credential never crosses the boundary once you draw it. Outbound traffic from a sandbox can be governed by an egress allowlist enforced on the host with eBPF, outside the VM: a sandbox with no rules set has open outbound access, and deny-by-default starts the moment you add the first rule (inbound is closed by default either way). Set that rule before the agent's first real run: an IP or CIDR, a port, or a domain through a transparent proxy, passed via the egress field at sandbox create time, the live PUT /v1/sandboxes/{id}/egress call, the SDK's setEgress, or the CLI's sandbox firewall set command. Code inside the sandbox cannot rewrite those rules or route around them once set, and the enforcement survives a full guest compromise. So even if a connection string ends up in the model's context through a bad retrieval, the sandbox has no path to act on it unless you deliberately opened one to a specific endpoint.

Third, the topology can keep the data entirely inside your perimeter. Sandboxes attach to private overlay networks with private DNS, traffic between networks denied by default, so an agent that runs queries can reach a query proxy or read replica by name without any public exposure. And if policy says the data must never leave your infrastructure, bring your own compute: the same sandbox API runs on your machines, with your storage (S3, R2, MinIO) and your control plane if needed. The database credentials stay inside your VPC from start to finish.

The result is a clean division of labor. The model contributes SQL. The sandbox contributes a machine that can only do what you allowed. Your application contributes the credentials, held where the model cannot read them.

Key Capabilities

Per-session microVM isolation. Every session is a Firecracker microVM with its own guest kernel. One agent's environment cannot see another's, and nothing inside can read the host.
Host-enforced egress allowlists. IP, CIDR, port, and domain rules enforced in the kernel with eBPF, outside the VM. No ingress by default. Rules survive a compromised guest.
Private sandbox networks. Connect query-running sandboxes to a database-side proxy or replica over a private overlay network with per-network DNS. No public exposure, cross-network traffic denied by default.
Pause, resume, and fork. Pause a long analysis session and billing stops; resume restores the exact machine. Fork a paused sandbox to branch agent state for parallel query attempts and keep the result that works.
Bring your own everything. BYO compute (same API on customer machines), BYO storage, and full self-hosting of control plane and storage when data cannot leave your boundary.
Per-second billing with $0 egress. Data-heavy query workloads do not get taxed for moving result sets around.

Proof & Evidence

The isolation argument does not rest on promises. CreateOS's own published analysis of a sandbox escape in an AI agent is the clearest illustration of why shared-kernel sandboxes fail against hostile or manipulated code, and why the per-VM kernel boundary matters.

On speed, use the measured numbers: a sandbox restores in tens of milliseconds, about 30 ms on an idle host. Pause takes about 1.4 seconds, and same-host resume completes in under 0.7 seconds. Cross-host cold start runs 11 to 13 seconds. These are idle-host figures, not SLA guarantees, and you should measure against your own workload.

The honest caveat: CreateOS Sandbox is a young product. CreateOS runs its own GitHub Actions runner and coding-agent plugin on it, which are usable proofs, but it does not carry a shelf of compliance certifications today, and we will not claim otherwise. The trust layer here is the architecture itself: Firecracker isolation, host-enforced egress, and the option to run the whole thing inside your own perimeter.

Buyer Considerations

Where do the credentials live? If your design currently puts a connection string in the agent's prompt or tool config, that is the first thing to move. Put it behind a proxy or read-replica endpoint and allowlist only that endpoint.
Least privilege, not full access. Point the sandbox's single allowed route at a scoped read replica or a query endpoint that enforces row and table limits. The egress allowlist is a hard outer wall; the account the proxy uses should be a narrow one too.
What can the sandbox reach? Whatever you have not restricted yet. Outbound access is open until you set an allowlist, so set it before the agent's first real run, and review it the way you would review a firewall rule set, per workload.
Does the data need to stay put? If yes, plan the bring-your-own path: same API on your compute, your storage, your VPC. This is a real deployment option, not a roadmap item.
Maturity. If your review process requires held certifications before any data touches a vendor runtime, say so early. The design-partner path exists for exactly this conversation.
Cost shape. Billing is per second with no egress charges, and pausing stops the meter. Query workloads that run in bursts are a good fit for that model.

Frequently Asked Questions

How does the agent run a query if it cannot reach the database?

You allow exactly one outbound route from the sandbox, to the endpoint you choose (for example, a query proxy or read replica). The sandbox can connect there and nowhere else. Credentials for that endpoint are held by your application or proxy, outside the sandbox, so the model never handles them.

What stops code inside the sandbox from disabling the egress rules?

Nothing inside the VM can, because the rules are not inside the VM. The allowlist is enforced on the host in the kernel with eBPF, outside the guest. The enforcement is designed to survive a full guest compromise.

Can several query agents work together without exposing anything publicly?

Yes. Attach them to a private overlay network with per-network private DNS. They reach each other and your database-side services by name. Traffic between different networks is denied by default.

What if policy forbids customer data from leaving our infrastructure?

Run the sandboxes yourself. The same sandbox API runs on your own machines, with bring-your-own storage (S3, R2, MinIO), and you can self-host the control plane and storage entirely. The workload stays inside your boundary.

Conclusion

A query-writing agent is safe when the credential and the code live in different trust domains. Give the model its own machine with a per-VM kernel boundary, enforce the network allowlist from the host, hold the database credentials outside that machine, and keep the whole loop inside your infrastructure when the data demands it. That is the pattern CreateOS Sandbox ships as a default, not a configuration exercise. If you are building an agent that touches customer data, read the docs, check sandbox pricing, and spin up your first sandbox free to see the boundary for yourself.

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.