Database Security Best Practices

Draft. These are recommendations for customers connecting databases to Helios. The goal is to bound what an agent running in a sandboxed environment can do with the credentials you provide.

Threat model

When you connect a database to Helios, an LLM-driven agent running inside an isolated sandbox is granted enough access to authenticate to that database. The sandbox holds your SSH key (if you use a bastion) and your database credentials for as long as the session lives. While the sandbox is isolated from the public internet on the inbound side, the agent code running inside it is, by design, untrusted: prompt injection, jailbreaks, or hostile tool output could cause it to use those credentials in ways you didn't intend.

The mitigations below are about bounding the blast radius of that access. None of them are required for the connection to work, but each one limits what an agent can do if it goes off-script.

Use a read-only database role

The simplest and highest-leverage mitigation. Create a role on your database that only has SELECT on the tables you want the agent to introspect, and use that role's credentials in the Helios connection.

• The agent cannot write, update, delete, drop, or grant anything.
• SQL injection in the agent's prompt cannot mutate data.
• Schema introspection still works.

For Postgres:

CREATE ROLE helios_readonly LOGIN PASSWORD '...';
GRANT CONNECT ON DATABASE mydb TO helios_readonly;
GRANT USAGE ON SCHEMA public TO helios_readonly;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO helios_readonly;
ALTER DEFAULT PRIVILEGES IN SCHEMA public
  GRANT SELECT ON TABLES TO helios_readonly;

Point Helios at a read replica

Even better than a read-only role on the primary. Most managed Postgres services (RDS, Aurora, Supabase, Neon branches, Cloud SQL) let you create a read replica with a click.

• Production writes are physically impossible from the replica's endpoint.
• Expensive queries from the agent hit the replica, not your primary.
• If the agent ever escalates beyond read-only (e.g. a database CVE), the damage is contained to the replica.

Use the replica's host in the Helios connection string and a read-only role on that replica.

Lock down your SSH bastion's authorized_keys

If you connect via an SSH tunnel, the SSH key you give Helios works for anything the bastion can reach by default: other databases, internal HTTP services, shell access on the bastion itself. To limit that key to forwarding only to the configured database, prepend restriction options to the key's line in ~/.ssh/authorized_keys on your bastion:

no-pty,no-agent-forwarding,permitopen="db.internal:5432" ssh-ed25519 AAAA... helios

Replace db.internal:5432 with your database host and port. Now the bastion refuses any forward request to a different target, so even if an agent had its own SSH client it could not pivot to other hosts.

Additional flags you may want depending on your bastion configuration:

• no-X11-forwarding — disables X11 forwarding.
• no-port-forwarding — too strict for our case; the tunnel relies on local-forward.
• command="/bin/false" — refuses interactive shell commands.

Use a dedicated SSH key

Generate a fresh SSH keypair specifically for Helios, rather than reusing one of your developer keys. This makes auditing and revocation simple: rotate or remove the helios key on the bastion any time without affecting other access.

ssh-keygen -t ed25519 -f ~/.ssh/helios -C helios

Add the public key (~/.ssh/helios.pub) to your bastion's authorized_keys with the permitopen restriction above, and paste the private key into the Helios connection form.

Restrict network reachability

If your bastion sits behind a firewall and you can reach it from the public internet, consider also restricting which source IPs are allowed to dial port 22. Helios connects from a stable egress range; contact support for the current IP list.

Audit logs

All queries the agent runs are visible to you:

• Database side: enable query logging on your database (pg_stat_statements, etc.) to record what was actually executed against your data.
• Helios side: the agent session transcripts capture every tool call, including SQL strings.

We recommend keeping database-side logging on for any production-data connection.

Summary

Layered together, the residual exposure is exactly what you chose to grant: read access to specific tables via a tunnel that can't pivot anywhere else.