← Blog2 min read

The Connection String You Can Paste Into Anything

The fastest way to give an AI agent database access is also the most dangerous one: paste your production DATABASE_URL into the tool and hope. It works immediately, which is the trap. The agent has whatever that credential has, which is usually everything.

PgBeam gives you a different string to paste. It looks like an ordinary Postgres connection string, because it is one. The difference is that it points at the proxy, carries a scoped credential, and every query that flows through it is checked against a policy before it reaches your database.

A guarded connection string
postgresql://agent_readonly:pbk_xxx@your-project.proxy.pgbeam.app:5432/app

Because it is a standard Postgres string, it works in every tool that already speaks Postgres. No SDK, no adapter, no plugin.

Claude Code and Cursor

Coding agents can run a database query when you let them. Point them at a guarded string and the agent can explore your schema, check a value, or verify a migration against real data, while read-only enforcement blocks every write and masking keeps PII out of the model's context.

If the tool speaks MCP, you can skip the connection string entirely and use the hosted MCP endpoint instead. Same policy, structured tools, one URL.

LangChain and other frameworks

A SQL agent built on LangChain or any framework takes a connection string or a SQLAlchemy URL. Hand it the guarded one. The framework's SQLDatabase toolkit, query chains, and retrievers all keep working, because to them it is just Postgres. The guardrails are not in the framework. They are at the wire, so they apply no matter which abstraction the framework puts on top.

LangChain SQL agent, unchanged
from langchain_community.utilities import SQLDatabase

db = SQLDatabase.from_uri(
    "postgresql://agent_readonly:pbk_xxx@your-project.proxy.pgbeam.app:5432/app"
)
# The agent can introspect and query. Writes are refused at the proxy.

psql, notebooks, and humans

The same string works for people. A data analyst pastes it into psql, a Jupyter notebook, or a BI tool, and gets a session scoped to exactly the tables and columns they are allowed to see, with row-level policies limiting them to their slice and budgets capping a runaway query. The contractor never touches your real credentials. When the engagement ends, you delete theirs.

psql, for a human analyst
psql "postgresql://analyst_eu:pbk_yyy@your-project.proxy.pgbeam.app:5432/app"

Why one string covers all of it

A connection string is the lowest common denominator of database access. Every driver, every ORM, every agent framework, every GUI eventually resolves to one. By putting enforcement at the wire and handing out a normal-looking string, the policy travels with the credential into whatever tool you paste it into. The tool does not need to know PgBeam exists.

That is the property that makes this practical: you scope a credential once, and it is safe everywhere it lands.

Try PgBeam or see the full feature set.

Get started with PgBeam

No credit card required. Start with a 14-day free trial and scale when you need to.