Data Security in AI-Assisted Migration: What Leaves Your Network

The Question That Decides the Shortlist

For any AI feature touching a database, one question often decides the tool before capability comparison even starts: where does my schema go? Schema and query text are not incidental — they describe the business in detail, from table names to the shape of every relationship. Treating them as sensitive is not paranoia; it is the default a serious data team starts from.

So here is a direct account of what leaves your network when you use DBMigrateAIPro, what does not, and the mechanism that enforces the line.

The Default: Nothing Leaves

The default AI provider runs in-process — a local model, no API key, no network call, no telemetry on schema content. When you ask it to explain a package or draft a conversion, the schema text never crosses your network boundary because there is no boundary to cross. The cost we accept for this is honest: the default local model is smaller than a hosted frontier model. We think a private default is worth that trade, and where you disagree, the next section is for you.

Optional: Bring Your Own Key

If you want a larger hosted model, you can supply your own provider key. This is opt-in and explicit — you are choosing to send prompts to that provider under your own account and its terms, and the tool makes that choice visible rather than silent. Nothing is routed through us; the call goes from your machine to the provider you configured.

The rule of thumb: if your data-residency policy forbids sending schema text to a third party, stay on the local default. If it permits a specific vendor under contract, bring-your-own-key lets you use exactly that one and no other.

Where Credentials Live

Database passwords are never written to disk in plaintext. Saved connections keep their non-secret fields — host, port, database, username — in a local config file, while the password is stored in the operating system's native keyring: Windows Credential Manager, macOS Keychain, or libsecret on Linux. On first run after upgrade, any password still sitting in an old plaintext config is migrated into the keyring and blanked on disk.

connections.json   ->  host, port, database, username   (non-secret)
OS keyring         ->  password                          (secret, encrypted at rest)
audit.log          ->  who / what / when                 (never the value)

The Audit Log Records Events, Not Secrets

Every credential operation — read, write, delete, rotate — appends one line to an audit log, so there is a durable record of what happened. Crucially, an audit entry contains only the scope, the kind of secret, and a version — never the credential value itself. A log you would be comfortable handing to a security reviewer is the only kind worth keeping.

Destructive Actions Need a Human

No AI action drops, truncates, or overwrites anything on its own. Destructive operations require explicit human approval, per action, every time. This is a deliberate limit on autonomy: a wrong answer in a chat window costs a minute, but a wrong statement against a production database costs a restore, and the two should not be governed by the same level of trust.

A Short Checklist for Your Security Review

• Default provider: local, in-process, no network egress of schema content
• Hosted models: opt-in bring-your-own-key only, direct to your chosen provider, never proxied through us
• Passwords: OS keyring, never plaintext on disk; legacy secrets auto-migrated
• Audit: append-only, records events and versions, never values
• Destructive actions: human-approved, per action

Security claims are only worth as much as the mechanism behind each one. Every line above names the thing in the tool that makes it true — which is the standard we think any AI feature touching your database should be held to, ours included.