What agents can and cannot do
Use a read-only identity
The strongest guarantee is an identity that cannot write. Each connector page has the exact role to create:- Postgres: a role with
SELECTonly anddefault_transaction_read_only = on(SQL). - MySQL: a user with
SELECT, SHOW VIEW, PROCESS(SQL). - Redis: an ACL user limited to
+@read(ACL line). - Kafka:
ReadandDescribeACLs, orDeveloperReadon Confluent Cloud (ACLs). - Kubernetes: a ServiceAccount bound to a read-only ClusterRole that excludes Secrets (YAML).
- AWS: an IAM role Danube assumes with an external id, with only
Describe,List,GetandQueryactions (policies).
Choose how Danube reaches the system
Most production systems live in a private network. There are three ways in, and you can mix them per connection.Allowlist Danube’s addresses
For a system with a public endpoint (Supabase, Neon, Confluent Cloud, a managed database with public access), Danube connects directly and requires TLS. Allow Danube’s egress addresses in the firewall or security group:destination_blocked).
Go through an SSH bastion
If you already run a bastion, add it to the connection: its public host, a user, a private key and the host key’s SHA256 fingerprint. Danube verifies the bastion’s key against that fingerprint on every call and never trusts a new key on first use. The database host can then be a private address that the bastion reaches. Available for Postgres, MySQL, ClickHouse, Redis, Kubernetes, Grafana and Prometheus.Run the data-plane agent
For systems that should never be reachable from outside, run the data-plane agent inside the network. It connects outbound only to Danube, so nothing inbound is opened. Store the connection’s secrets as references instead of values (env://PG_PASSWORD or vault://secret/db#password). The agent resolves them locally and runs the call there, so the password never reaches Danube. An admin can also require this path for the whole organization: turn off Direct infrastructure connections under Organization > Settings.
Connect it for your whole team
For a team, connect the database from Organization > Systems > Connect a system > Database or infrastructure rather than from the catalogue. The system gets its own name (“Orders DB”) and tools named after it, one connection shared with the organization, and rules an admin sets: which tables, namespaces or topics agents may use, masked columns, a row cap, whether writes are allowed, and saved defaults. See Databases and infrastructure.Connect in five minutes
1
Create the read-only identity
Use the SQL, ACL or policy from the connector’s page.
2
Add the connection
Open the connector in the dashboard’s tool catalog and click Connect, or have your agent call
store_credential. Leave the mode on Read only.3
Open the network path
Allowlist Danube’s addresses, fill in the SSH bastion fields, or run the data-plane agent with the secrets as references.
4
Run Test Connection
Ask your agent to “test the Postgres connection”. The answer names the identity, the TLS state and any over-privilege warning, or says exactly which of authentication, network or TLS failed.
Example prompts
- “Pull the last 50 errors from the checkout service in CloudWatch and find the matching orders in Postgres.”
- “What’s the consumer lag for payments-worker, and are its pods restarting?”
- “Why is this query slow? Explain it and suggest an index.”
- “Tail the logs of the api pods since ten minutes ago and summarize the errors.”
