Wren AI

Wren runs every query with whatever database credential sits in the active (or project-pinned) connection profile; it does not scope, downscope, or check authorization per request. For BigQuery it requests the broad cloud-platform and Google Drive scopes and falls back to the operator's Application Default Credentials when no key is given. Row- and column-level access rules in the semantic model exist, but in the default non-strict mode a query can name raw database tables outside the model and skip them. A project's own wren_project.yml chooses which stored credential profile is used.

Wren has no approval step of its own: queries, memory writes, context changes and `wren genbi deploy` (which publishes an app with bundled data to Vercel or Cloudflare) all run without confirmation. Worse, the skill stub it ships for Claude Code pre-approves every `wren` command, so the host agent's own permission prompt is skipped for deploys too. The deploy step only runs a structural and secret-pattern preflight. The MCP server mode is better behaved: every tool carries a read-only or write hint, and the single write tool is only registered when the operator passes --allow-write.

Every SQL statement, from the CLI, MCP server and SDKs alike, passes through one policy function that parses it and rejects anything that is not a single read-only SELECT-family query, including hidden writes such as data-modifying CTEs or SELECT INTO. That check is real but not a full boundary: it does not cover every path, and the re-check of the final planned SQL is skipped when it cannot be parsed. The stronger strict mode, which limits queries to tables defined in the semantic model and blocks file/URL/remote-database reader functions, is off by default. Beyond SQL, the CLI exposes everything at once (query, deploy, cloud push, memory writes) with no narrower default tool set.

Wren's core job is to run model-written SQL against live databases, and it does so directly with the operator's database credential; there is no isolation boundary around that execution beyond the database's own permissions. The Cloudflare deploy path also launches the wrangler CLI (or `npx wrangler`) as the same user with the full process environment. DuckDB files are attached read-only, which is a narrow mitigation for that one connector.

Wren returns database rows, project knowledge files, AGENTS.md and business rules to the host agent as plain content with no untrusted marking, and the onboarding and enrichment flows have the agent read raw documents. Nothing in Wren limits what a hijacked agent does next: with the shipped skill pre-approving every wren command, injected content in a database row or document could steer the agent to query sensitive tables and publish them with `wren genbi deploy`, unattended. Plain SQL writes are still blocked by the read-only check.

Several files in the project directory steer Wren without any trust decision. Every run auto-loads `.env` from the current directory and the project root into the process environment, supplying values for credential placeholders and deploy tokens, and the project's wren_project.yml picks which stored credential profile is used. Rule files and AGENTS.md from the project are served to the agent as instructions, and stored question-to-SQL pairs are recalled as proven examples. Memory is plain markdown under knowledge/ that is easy to review in git, and the MCP write tool is off by default, but the CLI store command and Git Sync share it with the whole team.

Wren loads little third-party code, but what it does load is unpinned and unconfined. Cloudflare deploys fall back to `npx wrangler` (latest from npm) when wrangler is not installed and pass it the whole environment, and the optional memory extra downloads a Hugging Face embedding model, chosen by an environment variable, at whatever revision is current. Nothing is verified by hash or signature.

Secret handling is one of Wren's better areas. Connection secrets are typed as masked values, profiles and Wren Cloud keys are stored in owner-only files, profiles can hold ${VAR} placeholders that are filled from the environment only at connection time, `profile debug` masks sensitive keys, tokens are never taken as command-line flags, and deploys refuse to ship `.env` files or obvious inlined credentials. There is no telemetry. Gaps: stored secrets are plaintext on disk, the wrangler subprocess receives the whole environment, and database passwords and service-account keys are long-lived.

Wren keeps no record of the queries it runs or the commands it executes: there are no log statements on the query path, and the MCP server does not log tool calls. The only durable trace of an action is the last-deploy entry written into the project's .wren/apps.yml, which sits inside the workspace and is overwritten on the next deploy. Reconstructing what an agent did through Wren depends entirely on the host agent's own transcript.

Wren does not own the agent loop, so its limits are bounds on its own work. The MCP server caps query results at 1,000 rows by default and 10,000 maximum, deploy subprocesses time out after 10 minutes and Vercel calls after 2 minutes. The README-led CLI path, however, returns unlimited rows when no --limit is given, and there is no default statement timeout or cost cap, so a runaway BigQuery or Snowflake query bills until the warehouse stops it.