Setting Up
Announce at start: "Using pythia-setup to configure the database access."
Set up in this order: connection first (everything else needs it), the
least-privilege user second (the only protection that cannot be bypassed),
SQLcl MCP last (optional, reads only).
1. Connection
Create
at the project root —
scaffolds it (pip installs:
), or copy
examples/connections.example.json
from a clone. Fill it in. Rules pythia
applies:
- One entry: used as-is. Several entries: the path segment directly under the
project root picks one ( → ), else the entry named by a
top-level . Ambiguity is an error, never a guess.
- and override everything; the
PYTHIA_USER/PYTHIA_PASSWORD/PYTHIA_DSN
variables bypass the file.
- The file holds credentials: it is gitignored — keep it that way, and keep
it out of chat and screenshots.
Verify with
: it prints who you are connected as and object
counts. A failure names the connection and what to check.
2. The agent's database user — the real protection
The policy file is an application-side fence;
Oracle grants are the only
layer an agent cannot walk around. Oracle has no clean per-object form of
"may edit PL/SQL in that schema" — compiling into another schema needs
, which spans every schema on the instance.
The workable pattern is proxy authentication: a logon-only user that
connects through the schema owner. The agent never learns the owner's
password, revocation is one statement, the audit trail shows who really
connected, and the blast radius is the one development schema.
Run
— ONE run, in the project directory. It
prints the three-statement proxy SQL with a generated password and saves
the matching credential as connection
(the new default; the
owner entry stays untouched). The password is regenerated on every run, so
never preview first and save later — the SQL and the saved config must
come from the same run. Relay the SQL to the developer verbatim for a DBA
to execute, then verify with
.
gives the same
result machine-readable. Manual alternative:
examples/agent-user-setup.example.sql
, names adapted.
Oracle's own guidance for LLM access, follow it: grant minimum privileges,
never point an LLM at a production database, audit its activity regularly.
warns on one line when the session holds
privileges or
runs as the schema owner directly. The goal state is: no warning.
3. SQLcl MCP server (optional, reads only)
If SQLcl 25.2+ is installed, agents can read through Oracle's official MCP
server: command
. Example client config:
json
{"mcpServers": {"sqlcl": {"command": "sql", "args": ["-mcp"]}}}
- Keep the default restrict level (, most restrictive): it blocks host
commands and scripts. Note it does NOT block DML/DDL inside —
which is why writes never go through MCP: only has the
snapshot, preview, verify and journal.
- Built-in audit, worth telling the DBA about: every interaction lands in
; shows the MCP client and
the LLM's name; generated SQL carries an
comment.
Done when
- connects, shows the right schema, and prints no
privilege warning.
- prints the write policy and the rollback table.
- The credentials file is untracked ( does not show it).