How do I put a policy layer between an agent and a database without changing my application?

The connection string case

If your agent connects to Postgres, MySQL, or a warehouse using a connection string from configuration or an environment variable, you change the string. Queries, schema references, and result handling all stay as they are.

This is the most common configuration in practice and the reason integration is usually measured in minutes. What to check before assuming it applies:

• The connection string is in configuration rather than compiled in.
• The agent uses standard driver behavior rather than engine-specific extensions.
• Nothing in the application depends on writing to the same connection, if the governed endpoint is read-oriented.

The Model Context Protocol server case

If the agent reaches the database through a Model Context Protocol server, the server holds the connection and the agent holds a tool definition. Repointing the server is a configuration change on the server, and the tool definition the agent sees does not move.

This is the cleaner of the two, because the policy boundary and the protocol boundary already coincide.

The case where it is a code change

If data access is written directly into the agent's code with a driver call and a hardcoded target, or spread across tool functions that each open their own connection, there is no single place to repoint. The work here is not the policy layer, it is consolidating data access behind one configurable path, which is worth doing regardless.

Be honest about this one during evaluation. A team that expects a config change and finds a refactor loses confidence in everything else they were told.

What changes for the developer

After repointing, a query that touches a restricted column returns a redacted value rather than an error, so code that expects a string still receives a string. A query that violates a policy is refused with an explanation rather than failing opaquely. The refusal is structured rather than a bare error: it names the action that was refused, the deny rule or guardrail that refused it, whether an approved grant could lift it, and the audit entry recording the refusal. Redacted values keep their type and their shape: a string comes back the same length with its characters replaced, a number comes back as another number of the same magnitude, and a boolean comes back as a boolean. Anonymized values are generated to match the kind of data a field holds where Ascent recognizes the field's name, so an email is replaced by an email.

This matters more than it sounds. A policy layer that returns errors where code expected data breaks applications and gets removed. One that returns transformed data of the right shape does not.

ASCENT=https://ascent.example.com

TOKEN=$(curl -sS -X POST "$ASCENT/api/login" \
  -H 'Content-Type: application/json' \
  -d '{"email": "you@example.com", "password": "..."}' \
  | jq -r .access_token)

RECORD_GUID=aaaaaaaa-ea4e-4e14-9e10-6d74b086af4c

curl -sS "$ASCENT/api/record/$RECORD_GUID/redact" \
  -H "Authorization: Bearer $TOKEN"

curl -sS "$ASCENT/api/record/$RECORD_GUID/anonymize" \
  -H "Authorization: Bearer $TOKEN"

curl -sS "$ASCENT/api/record/$RECORD_GUID/decrypt" \
  -H "Authorization: Bearer $TOKEN"

What this does not do

This pattern governs what the agent reaches through the governed endpoint. It does not govern a second path to the same data. If the agent, or anything else, also holds direct production credentials, those remain outside the policy layer.

That is the question to ask before adopting any layer of this kind, including this one: what else can reach this data, and by what route?