Use Case · Cursor

Cursor has access to your database. Guardrails decide what it can do with it.

Cursor agents can read schemas, write queries, and alter tables. Civic makes sure they stay read-only, unless you say otherwise.

Start building See how it works

use case / cursor

Cursor ran ALTER TABLE on production. To fix a slow query.

Just imagine, one day…

You ask the Cursor agent to check why a query is slow. It connects to your Postgres database, reads the schema, and spots a missing index. Reasonable so far.

Then it runs ALTER TABLE on production to add the index. The table locks. Reads queue behind the write lock. The API starts returning 504s. By the time your pager fires, 3 minutes of requests have timed out and your queue is backed up.

The agent found the right fix. It just applied it to the wrong environment.

Without guardrails, Cursor decides what is safe to run.

It does things you did not intend

You asked it to diagnose a slow query. It ran DDL on production. The diagnosis was correct. The action was catastrophic.

You cannot prove what happened

No audit trail of which queries it ran, which connection string it used, or why it chose production over staging. You're reading Postgres logs after the fact.

You cannot stop it fast enough

ALTER TABLE executes in milliseconds. By the time the table lock cascades to API timeouts, the damage is done. There's no undo for a production schema change.

It gets confused and you never know

The connection string in .env pointed to production. The agent didn't ask which environment. It just connected and started fixing things.

Cursor calls Civic. Civic calls your database. You control the access.

Connectivity

One MCP endpoint for databases, APIs, and cloud services. Cursor connects to everything through a single Civic URL. No raw connection strings in your environment.

Guardrails

Read schemas, run SELECT queries, explain plans. But no DDL, no writes to production, no direct connection to the primary, unless you explicitly allow it.

Auditability

Every query logged with the full SQL, target database, and execution time. When something breaks, you see exactly what the agent ran.

Revocation

Revoke any connection and Cursor loses database access instantly. No lingering connection pools, no cached credentials. Resume when you're ready.

Connect Cursor through Civic in three steps

Cursor Agent

Add Postgres (production and staging).

Allow SELECT and EXPLAIN on production.

Block DDL and writes on production.

Allow full access on staging.

Done. 2 connections configured:

✓ Postgres (prod) — read-only

✓ Postgres (stg) — full access

Your MCP URL is ready to copy.

Read the docs

The same scenario. Different outcomes.

Without Civic, Cursor has raw database access. With Civic, DDL on production is blocked before it reaches the server.

$ cursor: check why the orders query is slow

[cursor] connecting to postgres (production)...

[cursor] reading schema for orders table

[cursor] found: missing index on customer_id

[cursor] running ALTER TABLE orders ADD INDEX...

[postgres] ✘ table locked — 3 min downtime

$ # production locked. API down. pager firing.

$ cursor: check why the orders query is slow

[cursor] connecting to postgres via Civic...

[cursor] reading schema for orders table

[cursor] found: missing index on customer_id

[cursor] requesting ALTER TABLE on production...

[nexus] ✘ BLOCKED — DDL denied on production

[nexus] suggestion: run on staging first

$ # production untouched. fix tested on staging.

Cursor is fast. Civic makes sure it does not break production.

Your agent debugs queries all day. Spend 10 minutes making sure it can't alter production tables without you.

Start building Read the docs