You vibe coded the product. Who is looking after the customer data?

2 · Keep your code

The same SQL. Six callers. Six answers.

Your product still speaks SQL, and so does the code your assistant writes next, joins and aggregates included. What changes is the connection, and one word in the projection, which is the authorization decision rather than a formatting choice.

Two lines changed: the connection, and one word in front of the columns.

import psycopg2 connection = psycopg2.connect(host="db.internal", dbname="larkfield",                              user="app", password="...")cursor = connection.cursor()cursor.execute(    "SELECT first_name, last_name, tax_id "    "FROM customers WHERE plan_status = %s",    ["Active"],)for row in cursor.fetchall():    ...

import ascent_aql connection = ascent_aql.connect(    base_url="https://vault.larkfield.example/api",    email="app@larkfield.example", password="...")cursor = connection.cursor()cursor.execute(    "SELECT decrypt(first_name, last_name, tax_id) "    "FROM customers WHERE plan_status = %s",    ["Active"],)for row in cursor.fetchall():    ...

• The code on the left is what an AI coding assistant typically writes against Postgres. The connection changes. The query keeps its shape, its parameters and its loop.
• The word in front of the columns, decrypt or redact or anonymize or nothing, is the authorization decision, checked for every data repository the query touches before a row is read.
• A refusal arrives as an ordinary database error, so the error handling you already wrote catches it.
• An exact match on a protected column still works: the term is hashed and compared as a digest, never stored or compared as plaintext.
• Joins, GROUP BY, HAVING, ORDER BY and aggregates run as they are written. The nightly analytics job below sends one.
• A runnable end-to-end walkthrough ships in the repository: seed an example database, migrate it, then run the same query through the driver.

Now run it as each caller

SELECT decrypt(first_name, last_name, email, phone, support_note)
FROM customers
WHERE plan_status = 'Active'
  AND tag_isset('region:emea')

Accuracy

What this page simplifies.

• The migration is real, the numbers are made up. The command inspects a live database, such as the one behind your prototype, writes a plan you review, imports the rows and verifies both sides. The row count and the tables here are invented.
• The classifier matches column names. It flags names that look sensitive, states its reason for every column, and refuses to guess at a SQL type it cannot map. It is a good first pass to review, not a judgement about your data.
• The “before” code is typical, not quoted. It is the kind of database code an AI coding assistant usually writes for a prototype. Yours will differ in detail; what changes on Ascent is the same two things, the connection and the projection.
• The queries are simulated. The projections, the join with its aggregates, the per-data-repository decision before any row is read, the refusal arriving as a database error and the exact-match lookup on a protected column are all real behaviour; the rows come from this page.
• Two tables, six customers. A real prototype has more tables than it should, a real move brings all of them, and the interesting decisions are usually in the free-text columns.
• Compliance is a programme, not a product. Ascent gives you controls a security questionnaire, a SOC 2 auditor or a GDPR review asks about: encryption at rest, least privilege, an audit trail, and signed evidence reports with coverage statements for SOC 2 CC6 and CC7 and PCI DSS 10 among others. It does not make anyone compliant on its own, and nothing here is legal advice.