Skip to main content
Coding agents get stuck the moment a bug needs something outside the repo: the rows behind a failing request, the logs around an error, the lag on a queue. Danube gives your team’s agents (Claude Code, Cursor, Codex and anything that speaks MCP) one governed connection to those systems. Agents never see a password, can only read unless you say otherwise, and every call lands in your audit log. This page covers the controls that apply to every infrastructure connector: PostgreSQL, MySQL, ClickHouse, Redis, Kafka, Kubernetes, AWS (CloudWatch, DynamoDB, Lambda, SQS, S3, Redshift), Grafana, Prometheus, New Relic, Firebase and Salesforce.

​
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 SELECT only and default_transaction_read_only = on (SQL).
  • MySQL: a user with SELECT, SHOW VIEW, PROCESS (SQL).
  • Redis: an ACL user limited to +@read (ACL line).
  • Kafka: Read and Describe ACLs, or DeveloperRead on 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, Get and Query actions (policies).
Test Connection on every connector reports the identity it connected as and warns when it holds more privileges than it needs.

​
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:
The connection form in the dashboard shows the same list. A direct connection only reaches public addresses: a host that resolves to a private, loopback or cloud-metadata address is refused (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 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.”