Common use case

Connect an AI agent to a private database safely

Let an agent use one private database endpoint while database credentials and SQL permissions remain under your control.

Short answer

Run a supervised wzctl access pass beside the agent. Point its database client or MCP server at the resulting 127.0.0.1 port.

The problem

Agents often need live schema or data context. Exposing the database or sharing broad network access expands the trust boundary far beyond that task.

Choose and scope the connection model

Create a pass for one database IP and TCP port. wzctl presents that destination locally, while PostgreSQL or MySQL continues to authenticate the account and authorize SQL operations.

  1. 1Deploy a publisher that can reach the private database.
  2. 2Choose the publisher ID, exact database IP, and port 5432 or 3306.
  3. 3Start wzctl with the broker URL, API key, target details, TTL, and local port under process supervision.
  4. 4Point the agent's database tool at 127.0.0.1 and use a dedicated, least-privilege database account.

Example access flow

Process

AI agent through an MCP server

Local endpoint

127.0.0.1:15432

Access-pass target

10.0.2.30:5432 (/32)

Authorization boundary

One TCP target; PostgreSQL controls schemas and operations

When this pattern fits

  • A coding agent needs schema or data context from one private database.
  • An MCP server accepts a standard PostgreSQL or MySQL connection string.
  • The agent environment can supervise a companion wzctl process.
  • The database can provide a read-only or task-specific role.

Security boundary and limitations

  • Use an exact target IP. wzctl normalizes a bare IP to /32 and does not resolve private hostnames for the pass.
  • The pass carries TCP only. It provides no DNS, UDP, ICMP, subnet discovery, or general private routes.
  • Keep the database credential outside prompts and source control. WireZTNA does not limit rows, tables, or SQL statements.

Frequently asked questions

Can an agent reach PostgreSQL without a public IP?+

Yes. Keep PostgreSQL private and configure the agent's tool to use the local port provided by a supervised wzctl process.

Does wzctl replace database credentials?+

No. It provides TCP reachability. PostgreSQL or MySQL still authenticates the account and enforces its SQL privileges.

Does daemon mode detach wzctl?+

No. The daemon option records a PID but does not fork. Run wzctl under a service manager, container supervisor, or runner.

Put this pattern into practice

← All use cases