Is an audit log the same as read-only access?

No. Read-only stops writes. The log tells you what was read — which connection, which tool, when, and whether it succeeded. You need both: one blocks mutation, the other answers 'what did the agent actually do?'

Where do I see logs in Synra?

Dashboard → Usage. Each row is an MCP tool call: tool name, which connection (credential), success or error, duration, and time. Filter to errors when something failed.

Can the log tell me if my endpoint URL leaked?

It can tip you off. Spikes at odd hours, tools you didn't trigger, or traffic after you shared a URL in Slack are the usual signals. Then rotate the endpoint and keep watching.

Does logging mean my data is stored forever in the gateway?

Logs record metadata about the request (tool, connection, status, timing). Result rows still go to the AI client so the model can answer — same as pasting a query result. Don't treat logs as a substitute for staging or least-privilege.

Who should own the log in week one?

One person. Same idea as owning the endpoint URL. If nobody opens Usage the first week, you won't notice a leak or a habit of SELECT * until it hurts.

AI Database Query Audit Logs | What They're For

Staging (or a replica), read-only gateway, endpoint treated like a password — that's the setup. Still not enough when Cursor invents a confident number, or someone asks whether ChatGPT hit customers last night.

You need a trail. The query / usage log is that trail. Open it in week one, not after an incident.

Background: Why read-only matters, Treat your MCP endpoint like a password, Staging first.

What "the log" actually records

On a managed gateway like Synra, every MCP tool call against a connection gets a row. In the dashboard that's Usage:

Tool — list_tables, describe_table, query_table, execute_sql, …
Credential — which connection (staging vs prod replica — if you named them)
Status — success or error
Duration — how long the call took
Time — when it happened

The chat (Cursor / Claude / ChatGPT) still shows the SQL the model sent. The log is the chronological spine: something hit that connection at 2:14am, and it wasn't you staring at Composer.

Self-hosted MCP often has no log at all unless you build one. That's a real reason teams pick managed: self-hosted vs managed.

What it's actually useful for

1. "Where did that number come from?"

Agent says MRR is $48k. Finance says $51k. Open Usage around the time of the chat — which connection, which tools. Then open the chat and read the SQL. Wrong filter? Wrong schema? Staging from last Tuesday? The log says when to look; the chat says what ran.

Without a log you're arguing from memory.

2. Did a leaked endpoint get used?

You pasted a URL into Slack "just for a minute." Or mcp.json landed in a PR. After you rotate, watch Usage:

Calls after the share, before the rotate
Tools you didn't trigger
Odd hours or a volume spike

Read-only limits the blast to reads. The log tells you whether anyone took the opportunity.

3. Catch reckless reads early

Week one on a new connector: look for long durations and bursts of execute_sql / query_table on the biggest tables. Agents love SELECT * and wide date ranges. You won't see every column in the Usage table — you will see that staging just ate a 12-second query you didn't ask for. Tighten table allowlists, fix the prompt, or move off a DB that still has full PII.

4. Prove the write never landed

Ask Cursor to "try an UPDATE" once as a test. Synra should reject it. In Usage you want an error on that call — and no success right after. Pair with read-only: the log is how you check the control actually fired.

5. Know who owns the trail

Three people on one production endpoint → the log is a blur. Separate connections (and endpoints) per environment, and one person who opens Usage in week one. Same ownership rule as the URL.

A week-one checklist

Do this after you connect Cursor, Claude, or ChatGPT — while the setup is still fresh:

Ask three questions you already know the answers to.
Open Usage. Confirm three successful tool calls on the right credential name.
Deliberately ask for something that should fail (a write, or a table that isn't allowed). Confirm an error row.
Note the duration on a normal list_tables vs a heavier question — baseline for "that looks slow."
Put a calendar nudge: reopen Usage in seven days. Look for surprises.

If step 2 is empty, the client isn't actually hitting the gateway (wrong URL, tools not enabled). Fix that before you trust any chat answer.

Limits

Logging prod PII reads doesn't make them a good idea — staging still matters.

A Usage table isn't SIEM or a SOC2 package. It's accountability for AI SQL: who hit which connection, when, and whether it worked.

It also doesn't prove results stayed on your network. Rows still go to the model provider so the assistant can answer — same as paste. When not to connect if that tradeoff is still open.

Where to look in Synra

Sign in at mcpserver.design → open the app dashboard
Usage in the sidebar
Filter Errors when debugging; All when hunting volume or leaks
Match timestamps to the Cursor / Claude / ChatGPT thread that asked the question

Name connections clearly (Railway staging, Neon cursor-ai) so the Credential column is readable at a glance.

Read-only, staging, and a secret endpoint limit damage. The log is how you see what still happened.

Not connected yet? 7-day trial at mcpserver.design — staging DB, then the week-one checklist above.

Related reading:

Treat Your MCP Endpoint Like a Password — rotate when the URL escapes
Why Read-Only AI Database Access Matters — mutation vs read risk
Staging First — where to point before production
When Not to Connect AI to Your Database — when paste or BI wins
MCP Troubleshooting — no tools / no log rows
Self-Hosted vs Managed MCP Server — logging is a managed advantage