H
Here is the situation I kept running into. I want an AI agent to help me with a real schema, look up a table, count some rows, sanity-check a column, find which view a column comes from. None of that is risky on paper, it is just SELECT. But the moment you hand a database connection to an agent, you are one bad prompt away from a disaster. TRUNCATE CASCADE, DROP PURGE, even simple UPDATE can do a lot of damage.
So I built a small command into ADT.ai for exactly this case. It is called "discovery", and the whole point is that an AI (or any muggle) can poke around a schema without being able to break anything.
What it does
You give it a SELECT and an environment, it runs the query, prints the result, and writes a Markdown report. That is it. No DML, no DDL, no PL/SQL, no multi-statement smuggling. If you try anything other than a single SELECT, the validator rejects the statement before it ever reaches the database.
adtai discovery -env DEV -sql "SELECT table_name FROM user_tables ORDER BY 1" -limit 200
That prints the rendered result body to stdout and appends a numbered "Query 1" section to a per-minute report under "config/discovery/". The SQL is not repeated on screen, only in the log, so the terminal stays readable when an agent is firing several queries in a row. Yes, every request and response get logged to a file.
Multiple queries from a file
For real exploration you usually want more than one query. Drop your SELECTs into a file, separate them with semicolons, and pass it in:
adtai discovery -env DEV -file ./explore.sql
Each statement becomes its own numbered section in the report. If one of them fails (typo, missing table, ORA-00942), the error is captured in that section and the run keeps going. Your results will be below each query.
Three security layers
The first layer is a static validator. Each statement has to be a single SELECT, full stop. Anything else (UPDATE, DELETE, ALTER, BEGIN ... END, two statements separated by a semicolon, a SELECT followed by a comment-smuggled DROP) is rejected and recorded as an error. The query never reaches the database.
The second layer is a read-only transaction. Even valid SELECTs run inside SET TRANSACTION READ ONLY isolation, and the session is rolled back when the run ends. So if someone calls a function that mutates state, or a view that fires an INSTEAD OF trigger, nothing commits. The database stays exactly where it was.
So even if you forget the first layer existed, the second one catches you. And if you forget both, the report still shows you what happened.
Sure, it would be better to use a READ ONLY PROXY USER, but that's not always possible.
The third layer makes sure every run writes a log. When an agent is exploring a schema for me, I want a trail I can scroll back through tomorrow morning, not a transient terminal buffer. The files live under "config/discovery/" and ADT.ai automatically adds that folder to your project ".gitignore" on the first run, so transcripts never end up in version control by accident.
But if you really do want a throwaway query (a quick row count, a sanity check), there is the "-nolog" option:
adtai discovery -sql "SELECT SYSDATE FROM DUAL" -nolog
Where this fits
Discovery is not a replacement for SQL Developer or SQLcl. If you are a human debugging something tricky, open a real client. Discovery is for the cases where you want an agent to look something up for you without you having to babysit every query.
Discovery is the runtime part: the agent asks a question, discovery answers, and the schema stays untouched. It pairs well with Describe tables to your AI with APEX_DB_DICTIONARY, which feeds the agent structural metadata.
So if you have been holding back from letting AI near your database because of the obvious risk, this is the shape of guardrails I landed on. Validator + read-only transaction + log, all in one small command, so AI can't accidently forgot important instructions. Try it against a non-production schema first, see what your agent does with it.
If this saved you some worry, pass it on to someone whose agent is still flying without a seatbelt.
Happy exploring!
Comments
Post a Comment