DevOpsPadDownload

Why the AI never sees your credentials

· Engineering

DevOpsPad’s AI assistant can write a query for you. It cannot connect to anything, read your results, or run what it writes. A request to the AI provider contains your prompt, the engine name, and resource names only if you opt in. Credentials and result rows are never part of it. This post explains the reasoning and the smaller rules that hold it together.

The problem

An assistant inside a database client sits next to the most sensitive things on your machine: passwords for production systems and the data they protect. The convenient design is to give the model everything, connection details, schema and sample rows, and let it run queries in a loop. That design sends credentials and customer data to a third party on every prompt, and it lets a hallucinated DELETE or a prompt-injected instruction in a table comment act directly on production.

We wanted the useful part, help writing a query, without either risk.

The design

Send the least context that still helps

Each request contains:

  • the prompt you typed (1 to 16,000 characters),
  • the engine name, such as MySQL or Redis,
  • only if Include resource names is enabled: the visible resource names, such as table names. A name list larger than about 32 KB of JSON is refused rather than truncated.

Include resource names is off by default. Credentials are never included, and neither are query results, so customer data does not leave the machine because you asked for help. Each prompt is sent on its own. The chat history on screen is not resent as context, so something pasted three prompts ago is not quietly sent again.

The settings dialog states the same thing in the product: “Only your prompt is sent by default. Resource names are shared only when you enable context. Credentials and query results are never added automatically.”

Treat schema as data, not instructions

Resource names come from your databases, and anyone who can create a table or key can choose its name. The system prompt tells the model to treat supplied names as untrusted data rather than instructions, to produce read-only queries, never to claim a query was executed, and not to invent tables, fields or results. A system prompt is not a security boundary, but it narrows what the model is asked to do. The real boundary is the next rule.

Suggestions never execute

Generated queries appear in a code block with Insert into editor. Inserting puts the text in the active tab, and nothing more happens. You read it and run it yourself, against an adapter that is read-only anyway: a read-only MySQL transaction, ClickHouse readonly=1, a Redis command allowlist, MongoDB find only. The panel says “Suggestions stay in your editor. You decide what runs.”

Protect the API key in transit

The API key itself is a credential, so it gets the same treatment as a database password:

  • It is stored in the OS keychain (ai-api-key) and never returned to the UI.
  • The base URL must be HTTPS. Plain HTTP is accepted only for loopback (localhost, 127.0.0.1, ::1), which is how local models are typically served.
  • URLs with embedded credentials, query strings or fragments are rejected.
  • Redirects are not followed. Otherwise a provider or proxy answering with a redirect could send the Authorization: Bearer header to a different host.
  • Changing the endpoint without entering a new key deletes the old key, so one provider’s key is never sent to another provider’s URL.
  • The URL and the key are read together under one lock, so a settings change mid-request cannot pair them wrongly.

Requests time out after 60 seconds, and responses are read up to 2 MiB.

Bring your own model

The provider is whatever OpenAI-compatible /chat/completions endpoint you configure, including a model running on your own machine. If the prompt itself must not leave the laptop, point it at a local runtime. The local LLM guide walks through that.

External AI agents

Coding agents such as Claude Code or Codex can also work with DevOpsPad today, but only to report what they did. They call devopspadctl runs record with start, step and finish events for a build or release they performed with their own tools. The CLI writes a local record and links it to artifacts. It does not run Docker, push images or change Kubernetes, and it never hands out the credentials stored in DevOpsPad. Those records are evidence submitted by the agent, labeled as externally executed, not independently verified.

Trade-offs

  • Answers are worse without schema. With context off, the model guesses names. That is the price of the default, and the toggle is one click.
  • Names can still be sensitive. A table called acquisition_target_x says something. Enable context per prompt, not by habit.
  • No multi-turn memory. Follow-up questions must restate what matters.
  • No streaming yet, so long answers appear all at once.

What’s next

The roadmap plans to expose DevOpsPad’s capabilities to agents as MCP tools, starting with read-only tools and output budgets, and to add policy and human approval before any agent-initiated write. The principle stays the same: tools return results, while SSH keys, kubeconfigs and tokens stay in the keychain. These are plans in the repository, not shipped features.

For the details users need, see what the AI sends, configure an AI provider, inserting AI suggestions and AI run records.