# OneQuery Full Site Markdown > Complete Markdown export of OneQuery marketing, connector, comparison, blog, and documentation pages for agent ingestion. --- ## Source: https://onequery.dev/ # OneQuery > OneQuery gives AI agents production context without production keys, using approved sources, centralized credentials, enforced limits, and full audit logs. OneQuery is a governed production context layer for AI agents. It gives agents a controlled path to approved sources while production credentials stay centralized and every request leaves an audit trail. ## Core Positioning OneQuery helps teams give AI agents production context, not production keys. - No prod keys - No prod writes - Full audit ## Install - npm: `npm install -g @onequery/cli` - Homebrew: `brew install wordbricks/tap/onequery` - Bun: `bun add -g @onequery/cli` - Install script: `curl -fsSL https://onequery.dev/install.sh | sh` ## First Workflow 1. Start gateway. 2. Apply grant. 3. Connect sources. ```console $ npm install -g @onequery/cli installed onequery under ~/.onequery $ onequery gateway start gateway listening on http://localhost:5656 $ onequery grant apply prod-debug-readonly.yaml grant ready | credentials hidden ``` ## Agent Source API Examples ```console $ onequery api --source github://demo-prod acme/web/pulls --paginate --max-pages 2 --jq '.[] | {number,title,user,head,base}' --json 200 OK | 2 pages | credentials hidden $ onequery api --source github://demo-prod /repos/acme/web/commits?sha=main --json 200 OK | commits returned | audited $ onequery api --source sentry://demo-org /api/0/projects/acme/web/issues/?query=is:unresolved --json 200 OK | unresolved issues | read-only $ onequery api --source slack://demo-org /api/conversations.history -F channel=C123 -F limit=20 --json 200 OK | 20 messages | audited ``` ## Access Record Shape Each call names an approved source and endpoint. OneQuery sends the request with server-side credentials and records what happened. ```text source github://demo-prod endpoint acme/web/pulls actor agent session token never exposed policy read-only audit source, endpoint, caller, time ``` ## Roadmap ### In production today - Read-only query validation - Audit log for every query - Organization & membership - Claude Code, OpenClaw, Hermes ### Production guardrails - Agent profiles - Policy templates - Custom connectors ### Security operations - 1Password - SSO & SAML - Approvals ## Links - Documentation: https://onequery.dev/docs/ - Connectors: https://onequery.dev/connectors/ - Blog: https://onequery.dev/blog/ - GitHub: https://github.com/wordbricks/onequery - CLI package: https://www.npmjs.com/package/@onequery/cli - Self-host docs: https://onequery.dev/docs/operations/self-host/ --- ## Source: https://onequery.dev/docs/ # OneQuery Docs OneQuery gives developers and agents one governed path to approved data sources. Connect a source once, use an identifier like `postgres://warehouse`, and keep raw credentials out of prompts, scripts, and agent environments. ## Fast Path [Section titled “Fast Path”](#fast-path) 1. [Get started](/docs/getting-started/) with the CLI and choose a shared, hosted, or local server path. 2. Connect one read-only source. 3. Run one query or provider API call. 4. Give agents only the source identifiers they need. [Getting started](/docs/getting-started/)Install the CLI, choose a server path, connect a source, and run the first query. [Guide](/docs/guide/)Step-by-step tasks for installing, choosing a server path, connecting, querying, and preparing agents. [Concepts](/docs/concepts/)Understand governed access, source identifiers, query boundaries, and audit history. [Integrations](/docs/integrations/)Connect databases, warehouses, observability tools, developer systems, and analytics sources. [Examples](/docs/examples/)Apply OneQuery to production debugging, warehouse inspection, release review, and incident work. [Operations](/docs/operations/)Run the gateway, keep credentials scoped, and review the security checklist before rollout. [Security](/docs/security/)Review the architecture, threat model, data handling, and cost-control guidance for agent access. [Support](/docs/support/)Collect the right troubleshooting context without sharing secrets or raw production data. [Reference](/docs/reference/)Look up CLI commands, provider IDs, terminology, and common error guidance. [Edit page](https://github.com/wordbricks/onequery/edit/main/apps/landing/src/content/docs/docs/index.mdx) [Next\ Getting Started](/docs/getting-started/) --- ## Source: https://onequery.dev/docs/getting-started/ # Getting Started This guide gets one source working from the CLI. OneQuery keeps credentials server-side; callers use source identifiers like `postgres://warehouse`. ## Prerequisites [Section titled “Prerequisites”](#prerequisites) Choose one install method. You only need the requirement for that method. | Install method | Requirement | | --- | --- | | npm or npx | Node.js 22+ | | Bun or bunx | Bun; Node.js 22+ if you run a local gateway | | Homebrew | Homebrew | | Install script | `curl` and `tar`; the script manages Node.js runtime | For source setup, have a OneQuery server URL or local gateway, plus a read-only credential or limited provider token. ## Install the CLI [Section titled “Install the CLI”](#install-the-cli) - [npm](#tab-panel-0) - [Homebrew](#tab-panel-1) - [Bun](#tab-panel-2) - [Script](#tab-panel-3) Terminal window ``` npm install -g @onequery/cli ``` Terminal window ``` brew install wordbricks/tap/onequery ``` Terminal window ``` bun add -g @onequery/cli ``` Terminal window ``` curl -fsSL https://onequery.dev/install.sh | sh ``` You can also run the CLI without a global install: Terminal window ``` npx @onequery/cli --help ``` ## Choose a Server [Section titled “Choose a Server”](#choose-a-server) Use a shared server URL if your team provides one: Terminal window ``` onequery config set api.server_url https://onequery.example.com ``` Start a gateway only when you run OneQuery yourself: Terminal window ``` onequery gateway start ``` ## First Run [Section titled “First Run”](#first-run) 1. Verify and log in. Terminal window ``` onequery --version onequery auth login onequery auth whoami ``` 2. Connect a source. Replace the placeholders with read-only PostgreSQL credentials. Terminal window ``` onequery source connect --source postgres \ --input '{"sourceKey":"warehouse","credentials":{"host":"db.example.com","port":5432,"database":"app","username":"onequery_readonly","password":"","sslMode":"require"}}' ``` 3. Run a smoke query. Terminal window ``` onequery query exec --source postgres://warehouse --sql "select 1" ``` 4. Confirm the source. Terminal window ``` onequery source list ``` You are done when: - `onequery auth whoami` shows the expected user and organization. - `onequery source list` shows the source you connected. - The smoke query returns one row. ## What to Read Next [Section titled “What to Read Next”](#what-to-read-next) - [Source identifiers](/docs/concepts/source-identifiers/) explains `postgres://warehouse` and other source URI shapes. - [Run a query](/docs/guide/run-query/) covers read-only query execution. - [Agent workflows](/docs/guide/agent-workflows/) shows how to expose OneQuery to coding agents and automation. [Edit page](https://github.com/wordbricks/onequery/edit/main/apps/landing/src/content/docs/docs/getting-started.mdx) [Previous\ Overview](/docs/)[Next\ Overview](/docs/concepts/) --- ## Source: https://onequery.dev/connectors/ Connectors # Data sources 41 supported sources for governed agent access. ## Filters Showing 41 of 41 Clear all Search Search... ## Use Case \[x] All \[ ] Databases \[ ] Warehouses \[ ] Developer workflow \[ ] Observability \[ ] Product analytics \[ ] Productivity \[ ] Marketing [Query](/connectors/postgresql/) ## [PostgreSQL](/connectors/postgresql/) [Databases](/connectors/postgresql/) [Connect a Postgres database with a direct host, database, and login.](/connectors/postgresql/) [Query](/connectors/supabase/) ## [Supabase](/connectors/supabase/) [Databases](/connectors/supabase/) [Connect Supabase with the session pooler host, database, and login credentials over the Postgres wire protocol.](/connectors/supabase/) [Query](/connectors/mysql/) ## [MySQL](/connectors/mysql/) [Databases](/connectors/mysql/) [Connect a MySQL database with host, schema, and login credentials.](/connectors/mysql/) [Query](/connectors/snowflake/) ## [Snowflake](/connectors/snowflake/) [Warehouses](/connectors/snowflake/) [Connect Snowflake with an account identifier, warehouse, database, and login credentials.](/connectors/snowflake/) [API](/connectors/mongodb/) ## [MongoDB](/connectors/mongodb/) [Databases](/connectors/mongodb/) [Connect MongoDB with one connection string plus database selection.](/connectors/mongodb/) [Query](/connectors/bigquery/) ## [BigQuery](/connectors/bigquery/) [Warehouses](/connectors/bigquery/) [Connect BigQuery with either Google OAuth tokens or a Google Cloud service account JSON key.](/connectors/bigquery/) [API](/connectors/codex-app-server-api/) ## [Codex App Server API](/connectors/codex-app-server-api/) [Developer workflow](/connectors/codex-app-server-api/) [Connect the OpenAI-compatible Codex App Server API without exposing its API key to the caller.](/connectors/codex-app-server-api/) [Query](/connectors/cloudflare-d1/) ## [Cloudflare D1](/connectors/cloudflare-d1/) [Warehouses](/connectors/cloudflare-d1/) [Connect Cloudflare D1 with an account ID, D1 database ID, and account-scoped API token.](/connectors/cloudflare-d1/) [Query](/connectors/cloudflare-r2-sql/) ## [Cloudflare R2 SQL](/connectors/cloudflare-r2-sql/) [Warehouses](/connectors/cloudflare-r2-sql/) [Connect Cloudflare R2 SQL with an account ID, R2 bucket name, and API token for querying R2 Data Catalog Iceberg tables.](/connectors/cloudflare-r2-sql/) [Query](/connectors/laminar/) ## [Laminar](/connectors/laminar/) [Observability](/connectors/laminar/) [Connect Laminar with an API key and optional non-default base URL.](/connectors/laminar/) [Query](/connectors/motherduck/) ## [MotherDuck](/connectors/motherduck/) [Warehouses](/connectors/motherduck/) [Connect MotherDuck through its PostgreSQL wire protocol endpoint with a service token.](/connectors/motherduck/) [ConnectorQuery](/connectors/aws-athena-connector/) ## [AWS Athena Connector](/connectors/aws-athena-connector/) [Warehouses](/connectors/aws-athena-connector/) [Connect an Athena connector already registered with this org in OneQuery.](/connectors/aws-athena-connector/) [API](/connectors/google-analytics/) ## [Google Analytics](/connectors/google-analytics/) [Product analytics](/connectors/google-analytics/) [Connect Google Analytics with either Google OAuth tokens or a Google Cloud service account JSON key.](/connectors/google-analytics/) [API](/connectors/youtube-analytics/) ## [YouTube Analytics](/connectors/youtube-analytics/) [Product analytics](/connectors/youtube-analytics/) [Connect YouTube Analytics with Google OAuth tokens that can read YouTube Analytics reports.](/connectors/youtube-analytics/) [API](/connectors/amplitude/) ## [Amplitude](/connectors/amplitude/) [Product analytics](/connectors/amplitude/) [Connect Amplitude with a project API key, secret key, and region.](/connectors/amplitude/) [API](/connectors/mixpanel/) ## [Mixpanel](/connectors/mixpanel/) [Product analytics](/connectors/mixpanel/) [Connect Mixpanel with an org-level service account, project ID, and region.](/connectors/mixpanel/) [API](/connectors/posthog/) ## [PostHog](/connectors/posthog/) [Product analytics](/connectors/posthog/) [Connect PostHog with the PostHog app host URL, a personal API key, and project ID.](/connectors/posthog/) [API](/connectors/sentry/) ## [Sentry](/connectors/sentry/) [Observability](/connectors/sentry/) [Connect Sentry with a Personal Token, organization slug, optional project slug, and optional self-hosted API base URL.](/connectors/sentry/) [API](/connectors/github/) ## [GitHub](/connectors/github/) [Developer workflow](/connectors/github/) [Connect GitHub with a fine-grained personal access token and optional repository or installation scoping.](/connectors/github/) [API](/connectors/figma/) ## [Figma](/connectors/figma/) [Developer workflow](/connectors/figma/) [Connect Figma with a personal access token for read-only REST API and grouped design-context access.](/connectors/figma/) [API](/connectors/airtable/) ## [Airtable](/connectors/airtable/) [Productivity](/connectors/airtable/) [Connect Airtable with a Personal Access Token and optional default base ID.](/connectors/airtable/) [API](/connectors/discord/) ## [Discord](/connectors/discord/) [Developer workflow](/connectors/discord/) [Connect Discord with a bot token or OAuth bearer token for Discord REST API access.](/connectors/discord/) [API](/connectors/slack/) ## [Slack](/connectors/slack/) [Productivity](/connectors/slack/) [Connect Slack so agents can read channel and thread history and send messages where the installed app has access.](/connectors/slack/) [API](/connectors/cal-com/) ## [Cal.com](/connectors/cal-com/) [Productivity](/connectors/cal-com/) [Connect Cal.com API v2 with an API key or compatible bearer token.](/connectors/cal-com/) [API](/connectors/granola/) ## [Granola](/connectors/granola/) [Productivity](/connectors/granola/) [Connect Granola with an API key that has access to the note scopes you want to query.](/connectors/granola/) [API](/connectors/google-search-console/) ## [Google Search Console](/connectors/google-search-console/) [Marketing](/connectors/google-search-console/) [Connect Google Search Console with Google OAuth or an OAuth access token and optional default site URL.](/connectors/google-search-console/) [API](/connectors/confluence/) ## [Confluence](/connectors/confluence/) [Developer workflow](/connectors/confluence/) [Connect Confluence Cloud with an Atlassian account email and API token.](/connectors/confluence/) [API](/connectors/jam/) ## [Jam](/connectors/jam/) [Developer workflow](/connectors/jam/) [Connect a Jam workspace through Jam MCP with a read-only personal access token.](/connectors/jam/) [API](/connectors/amazon-ads/) ## [Amazon Ads](/connectors/amazon-ads/) [Marketing](/connectors/amazon-ads/) [Connect Amazon Ads with a Login with Amazon access token, client ID, region, and optional profile ID.](/connectors/amazon-ads/) [API](/connectors/linkedin-ads/) ## [LinkedIn Ads](/connectors/linkedin-ads/) [Marketing](/connectors/linkedin-ads/) [Connect LinkedIn Ads with a Marketing API OAuth access token and version header.](/connectors/linkedin-ads/) [API](/connectors/tiktok-marketing/) ## [TikTok Marketing](/connectors/tiktok-marketing/) [Marketing](/connectors/tiktok-marketing/) [Connect TikTok Marketing API with an API for Business access token.](/connectors/tiktok-marketing/) [API](/connectors/sendgrid/) ## [SendGrid](/connectors/sendgrid/) [Marketing](/connectors/sendgrid/) [Connect SendGrid with a v3 Web API key.](/connectors/sendgrid/) [API](/connectors/jira/) ## [Jira](/connectors/jira/) [Developer workflow](/connectors/jira/) [Connect Jira Cloud with an Atlassian account email and API token.](/connectors/jira/) [API](/connectors/vercel/) ## [Vercel](/connectors/vercel/) [Developer workflow](/connectors/vercel/) [Connect Vercel with an API token for deployments, projects, teams, and runtime observability endpoints.](/connectors/vercel/) [API](/connectors/e2b/) ## [E2B](/connectors/e2b/) [Developer workflow](/connectors/e2b/) [Connect E2B with a team API key to inspect sandbox state, logs, metrics, and lifecycle events through read-only Source API calls.](/connectors/e2b/) [API](/connectors/hermes-agent/) ## [Hermes Agent](/connectors/hermes-agent/) [Developer workflow](/connectors/hermes-agent/) [Connect the native Hermes Agent HTTP API without exposing its API key to the caller.](/connectors/hermes-agent/) [API](/connectors/1password/) ## [1Password](/connectors/1password/) [Developer workflow](/connectors/1password/) [Connect 1Password with a Service Account token for read-only vault, item, and secret reference access.](/connectors/1password/) [API](/connectors/microsoft-clarity/) ## [Microsoft Clarity](/connectors/microsoft-clarity/) [Product analytics](/connectors/microsoft-clarity/) [Connect Microsoft Clarity with a project Data Export API token.](/connectors/microsoft-clarity/) [APIWorkflow](/connectors/linear/) ## [Linear](/connectors/linear/) [Developer workflow](/connectors/linear/) [Connect Linear with an API key and choose whether agents can only receive mentions, read issues, or read and create issues.](/connectors/linear/) [API](/connectors/cloudflare-workers-observability/) ## [Cloudflare Workers Observability](/connectors/cloudflare-workers-observability/) [Observability](/connectors/cloudflare-workers-observability/) [Connect Cloudflare Workers Observability with an account-scoped API token and account ID.](/connectors/cloudflare-workers-observability/) [API](/connectors/cloudflare-web-analytics/) ## [Cloudflare Web Analytics](/connectors/cloudflare-web-analytics/) [Product analytics](/connectors/cloudflare-web-analytics/) [Connect Cloudflare Web Analytics with an account-scoped API token, account ID, and optional site tag.](/connectors/cloudflare-web-analytics/) --- ## Source: https://onequery.dev/compare/ Compare OneQuery # Choose the right data access boundary for AI agents. These comparisons separate protocol adapters, BI tools, IDEs, and custom agents from the governed source access layer production workflows still need. - Credential isolation - Read-only query boundaries - Agent audit history [Credential strategy](/compare/onequery-vs-direct-database-credentials/) ## [direct database credentials](/compare/onequery-vs-direct-database-credentials/) [Direct database credentials can be fast for a human, but they make the agent runtime the security boundary. OneQuery moves that boundary into a governed execution layer.](/compare/onequery-vs-direct-database-credentials/) [Read comparison](/compare/onequery-vs-direct-database-credentials/)[Protocol adapter](/compare/onequery-vs-mcp-database-server/) ## [MCP database server](/compare/onequery-vs-mcp-database-server/) [MCP helps an AI application discover and call tools. OneQuery handles the production data boundary those tools still need.](/compare/onequery-vs-mcp-database-server/) [Read comparison](/compare/onequery-vs-mcp-database-server/)[Build versus govern](/compare/onequery-vs-internal-data-agent/) ## [internal data agent](/compare/onequery-vs-internal-data-agent/) [An internal agent can be the right product choice. OneQuery makes sure that agent does not also become the credential store and production query gate.](/compare/onequery-vs-internal-data-agent/) [Read comparison](/compare/onequery-vs-internal-data-agent/)[Analytics versus operations](/compare/onequery-vs-bi-chatbot/) ## [BI chatbot](/compare/onequery-vs-bi-chatbot/) [BI chatbots make analytics more accessible. OneQuery makes production source access safer for agents that do operational work.](/compare/onequery-vs-bi-chatbot/) [Read comparison](/compare/onequery-vs-bi-chatbot/)[BI platform comparison](/compare/onequery-vs-metabase-for-ai-agents/) ## [Metabase for AI agents](/compare/onequery-vs-metabase-for-ai-agents/) [Metabase is the right home for BI-curated analytics. OneQuery is the access boundary for agents that need operational source context outside the BI workspace.](/compare/onequery-vs-metabase-for-ai-agents/) [Read comparison](/compare/onequery-vs-metabase-for-ai-agents/)[IDE versus agent access layer](/compare/onequery-vs-datagrip-for-ai-agents/) ## [DataGrip for AI agents](/compare/onequery-vs-datagrip-for-ai-agents/) [DataGrip is excellent for trusted humans writing SQL. OneQuery is the safer path when the caller is an agent that should not hold database connection details.](/compare/onequery-vs-datagrip-for-ai-agents/) [Read comparison](/compare/onequery-vs-datagrip-for-ai-agents/) Direct answer ## OneQuery is for governed production source access, not dashboards or human SQL editing. Teams can keep BI platforms, MCP clients, database IDEs, and internal agents. OneQuery fits where those systems need a shared access layer that keeps credentials centralized, applies deterministic limits, and records what agents did. [Read governed access docs](/docs/concepts/governed-access/) --- ## Source: https://onequery.dev/blog/ OneQuery # Blog [All](/blog/)[Product](/blog/category/product/)[Engineering](/blog/category/engineering/)[Safety](/blog/category/safety/)[Usecase](/blog/category/usecase/) 11 posts [![OneQuery logo connected to the Jam logo with a heart symbol.](/_astro/hunting-web-bugs-with-jam-and-agents-icon.DKMI9A2V_miwGz.webp)](/blog/hunting-web-bugs-with-jam-and-agents/) [Usecase / Jul 23, 2026](/blog/hunting-web-bugs-with-jam-and-agents/) ## [Hunting web bugs with Jam and agents](/blog/hunting-web-bugs-with-jam-and-agents/) [A reproducible browser QA loop that turns agent findings into verified Jam evidence, bounded diagnostics, and actionable issue handoffs.](/blog/hunting-web-bugs-with-jam-and-agents/) [7 min read →](/blog/hunting-web-bugs-with-jam-and-agents/) [![Safe internal data analysis with Hermes Agent and OneQuery - OneQuery blog cover image.](/_astro/safe-internal-data-analysis-with-hermes-agent-and-onequery-icon.DouhLRVV_Z14LiOb.webp)](/blog/safe-internal-data-analysis-with-hermes-agent-and-onequery/) [Usecase / Jul 9, 2026](/blog/safe-internal-data-analysis-with-hermes-agent-and-onequery/) ## [Safe internal data analysis with Hermes Agent and OneQuery](/blog/safe-internal-data-analysis-with-hermes-agent-and-onequery/) [How to let Hermes Agent answer internal data questions from Slack, Discord, or Telegram without exposing raw credentials, write access, or unbounded query cost.](/blog/safe-internal-data-analysis-with-hermes-agent-and-onequery/) [6 min read →](/blog/safe-internal-data-analysis-with-hermes-agent-and-onequery/) [![OneQuery logo connected to the Vercel logo with a heart symbol.](/_astro/onequery-loves-vercel-icon.HdKMEU7Q_j2VkT.webp)](/blog/onequery-loves-vercel/) [Product / Jun 23, 2026](/blog/onequery-loves-vercel/) ## [OneQuery loves Vercel](/blog/onequery-loves-vercel/) [Connect Vercel to OneQuery so agents can inspect teams, projects, and deployments without carrying raw Vercel tokens.](/blog/onequery-loves-vercel/) [4 min read →](/blog/onequery-loves-vercel/) [![OneQuery logo connected to the E2B logo with a heart symbol.](/_astro/e2b-source-api-connection-icon.DdlVYHtS_1YGOhy.webp)](/blog/e2b-source-api-connection/) [Product / Jun 22, 2026](/blog/e2b-source-api-connection/) ## [Connect E2B to OneQuery](/blog/e2b-source-api-connection/) [OneQuery now supports E2B as a connected Source API for reading sandbox state, lifecycle events, logs, and metrics without exposing raw credentials to agents.](/blog/e2b-source-api-connection/) [3 min read →](/blog/e2b-source-api-connection/) [![Debugging production on Cloudflare with Codex - OneQuery blog cover image.](/_astro/debug-production-agent-runs-with-onequery-icon.DBbsA9qq_1Xzz0m.webp)](/blog/debug-production-agent-runs-with-onequery/) [Engineering / May 6, 2026](/blog/debug-production-agent-runs-with-onequery/) ## [Debugging production on Cloudflare with Codex.](/blog/debug-production-agent-runs-with-onequery/) [How Codex can use OneQuery-connected Cloudflare logs to inspect production failures, separate evidence from guesses, and make targeted code changes.](/blog/debug-production-agent-runs-with-onequery/) [4 min read →](/blog/debug-production-agent-runs-with-onequery/) [![Context Enrichment with OneQuery - OneQuery blog cover image.](/_astro/context-enrichment-with-onequery-icon.DcfL4bZQ_Z2ssnbE.webp)](/blog/context-enrichment-with-onequery/) [Engineering / May 1, 2026](/blog/context-enrichment-with-onequery/) ## [Context Enrichment with OneQuery](/blog/context-enrichment-with-onequery/) [A practical workflow for implementing the context enrichment layer described in OpenAI's in-house data agent writeup with schema facts, bounded SQL evidence, and code references.](/blog/context-enrichment-with-onequery/) [7 min read →](/blog/context-enrichment-with-onequery/) [![A Safe Data Access Layer for LLMs - OneQuery blog cover image.](/_astro/llm-safe-data-access-layer-icon.CW6v_O6e_ZJXAOt.webp)](/blog/llm-safe-data-access-layer/) [Safety / Apr 30, 2026](/blog/llm-safe-data-access-layer/) ## [A Safe Data Access Layer for LLMs](/blog/llm-safe-data-access-layer/) [How OneQuery gives LLMs a safe, auditable data access layer without handing them raw production credentials.](/blog/llm-safe-data-access-layer/) [4 min read →](/blog/llm-safe-data-access-layer/) [![Using LLM telemetry to improve prompts with GEPA - OneQuery blog cover image.](/_astro/using-llm-telemetry-to-improve-prompts-with-gepa-icon.CNdiHKKf_ZAe4U7.webp)](/blog/using-llm-telemetry-to-improve-prompts-with-gepa/) [Usecase / Apr 30, 2026](/blog/using-llm-telemetry-to-improve-prompts-with-gepa/) ## [Using LLM telemetry to improve prompts with GEPA](/blog/using-llm-telemetry-to-improve-prompts-with-gepa/) [A practical workflow for using OneQuery to let a GEPA reflection agent inspect Laminar LLM telemetry while improving prompts.](/blog/using-llm-telemetry-to-improve-prompts-with-gepa/) [7 min read →](/blog/using-llm-telemetry-to-improve-prompts-with-gepa/) [![Do not give agents the keys to production - OneQuery blog cover image.](/_astro/do-not-give-agents-production-keys-icon.DglLmtev_1b13Nm.webp)](/blog/do-not-give-agents-production-keys/) [Safety / Apr 29, 2026](/blog/do-not-give-agents-production-keys/) ## [Do not give agents the keys to production](/blog/do-not-give-agents-production-keys/) [Why autonomous agents should never hold raw production access, and how OneQuery removes that class of risk from data workflows.](/blog/do-not-give-agents-production-keys/) [5 min read →](/blog/do-not-give-agents-production-keys/) [![How startups can build an in-house data agent - OneQuery blog cover image.](/_astro/how-startups-can-build-an-in-house-data-agent-icon.BzrLokOj_1EiYUS.webp)](/blog/how-startups-can-build-an-in-house-data-agent/) [Product / Apr 28, 2026](/blog/how-startups-can-build-an-in-house-data-agent/) ## [How startups can build an in-house data agent](/blog/how-startups-can-build-an-in-house-data-agent/) [A practical startup playbook for turning an AI data agent from a risky demo into a safe, contextual, auditable workflow.](/blog/how-startups-can-build-an-in-house-data-agent/) [6 min read →](/blog/how-startups-can-build-an-in-house-data-agent/) [![Making data source setup boring - OneQuery blog cover image.](/_astro/making-data-source-setup-boring-icon.CRvGqw-C_Z63qPB.webp)](/blog/making-data-source-setup-boring/) [Product / Apr 21, 2026](/blog/making-data-source-setup-boring/) ## [Making data source setup boring](/blog/making-data-source-setup-boring/) [Replacing one-off connector setup with a predictable path for every database and analytics source.](/blog/making-data-source-setup-boring/) [4 min read →](/blog/making-data-source-setup-boring/) --- ## Source: https://onequery.dev/blog/category/engineering/ OneQuery # Blog [All](/blog/)[Product](/blog/category/product/)[Engineering](/blog/category/engineering/)[Safety](/blog/category/safety/)[Usecase](/blog/category/usecase/) 2 posts [![Debugging production on Cloudflare with Codex - OneQuery blog cover image.](/_astro/debug-production-agent-runs-with-onequery-icon.DBbsA9qq_1Xzz0m.webp)](/blog/debug-production-agent-runs-with-onequery/) [Engineering / May 6, 2026](/blog/debug-production-agent-runs-with-onequery/) ## [Debugging production on Cloudflare with Codex.](/blog/debug-production-agent-runs-with-onequery/) [How Codex can use OneQuery-connected Cloudflare logs to inspect production failures, separate evidence from guesses, and make targeted code changes.](/blog/debug-production-agent-runs-with-onequery/) [4 min read →](/blog/debug-production-agent-runs-with-onequery/) [![Context Enrichment with OneQuery - OneQuery blog cover image.](/_astro/context-enrichment-with-onequery-icon.DcfL4bZQ_Z2ssnbE.webp)](/blog/context-enrichment-with-onequery/) [Engineering / May 1, 2026](/blog/context-enrichment-with-onequery/) ## [Context Enrichment with OneQuery](/blog/context-enrichment-with-onequery/) [A practical workflow for implementing the context enrichment layer described in OpenAI's in-house data agent writeup with schema facts, bounded SQL evidence, and code references.](/blog/context-enrichment-with-onequery/) [7 min read →](/blog/context-enrichment-with-onequery/) --- ## Source: https://onequery.dev/blog/category/product/ OneQuery # Blog [All](/blog/)[Product](/blog/category/product/)[Engineering](/blog/category/engineering/)[Safety](/blog/category/safety/)[Usecase](/blog/category/usecase/) 4 posts [![OneQuery logo connected to the Vercel logo with a heart symbol.](/_astro/onequery-loves-vercel-icon.HdKMEU7Q_j2VkT.webp)](/blog/onequery-loves-vercel/) [Product / Jun 23, 2026](/blog/onequery-loves-vercel/) ## [OneQuery loves Vercel](/blog/onequery-loves-vercel/) [Connect Vercel to OneQuery so agents can inspect teams, projects, and deployments without carrying raw Vercel tokens.](/blog/onequery-loves-vercel/) [4 min read →](/blog/onequery-loves-vercel/) [![OneQuery logo connected to the E2B logo with a heart symbol.](/_astro/e2b-source-api-connection-icon.DdlVYHtS_1YGOhy.webp)](/blog/e2b-source-api-connection/) [Product / Jun 22, 2026](/blog/e2b-source-api-connection/) ## [Connect E2B to OneQuery](/blog/e2b-source-api-connection/) [OneQuery now supports E2B as a connected Source API for reading sandbox state, lifecycle events, logs, and metrics without exposing raw credentials to agents.](/blog/e2b-source-api-connection/) [3 min read →](/blog/e2b-source-api-connection/) [![How startups can build an in-house data agent - OneQuery blog cover image.](/_astro/how-startups-can-build-an-in-house-data-agent-icon.BzrLokOj_1EiYUS.webp)](/blog/how-startups-can-build-an-in-house-data-agent/) [Product / Apr 28, 2026](/blog/how-startups-can-build-an-in-house-data-agent/) ## [How startups can build an in-house data agent](/blog/how-startups-can-build-an-in-house-data-agent/) [A practical startup playbook for turning an AI data agent from a risky demo into a safe, contextual, auditable workflow.](/blog/how-startups-can-build-an-in-house-data-agent/) [6 min read →](/blog/how-startups-can-build-an-in-house-data-agent/) [![Making data source setup boring - OneQuery blog cover image.](/_astro/making-data-source-setup-boring-icon.CRvGqw-C_Z63qPB.webp)](/blog/making-data-source-setup-boring/) [Product / Apr 21, 2026](/blog/making-data-source-setup-boring/) ## [Making data source setup boring](/blog/making-data-source-setup-boring/) [Replacing one-off connector setup with a predictable path for every database and analytics source.](/blog/making-data-source-setup-boring/) [4 min read →](/blog/making-data-source-setup-boring/) --- ## Source: https://onequery.dev/blog/category/safety/ OneQuery # Blog [All](/blog/)[Product](/blog/category/product/)[Engineering](/blog/category/engineering/)[Safety](/blog/category/safety/)[Usecase](/blog/category/usecase/) 2 posts [![A Safe Data Access Layer for LLMs - OneQuery blog cover image.](/_astro/llm-safe-data-access-layer-icon.CW6v_O6e_ZJXAOt.webp)](/blog/llm-safe-data-access-layer/) [Safety / Apr 30, 2026](/blog/llm-safe-data-access-layer/) ## [A Safe Data Access Layer for LLMs](/blog/llm-safe-data-access-layer/) [How OneQuery gives LLMs a safe, auditable data access layer without handing them raw production credentials.](/blog/llm-safe-data-access-layer/) [4 min read →](/blog/llm-safe-data-access-layer/) [![Do not give agents the keys to production - OneQuery blog cover image.](/_astro/do-not-give-agents-production-keys-icon.DglLmtev_1b13Nm.webp)](/blog/do-not-give-agents-production-keys/) [Safety / Apr 29, 2026](/blog/do-not-give-agents-production-keys/) ## [Do not give agents the keys to production](/blog/do-not-give-agents-production-keys/) [Why autonomous agents should never hold raw production access, and how OneQuery removes that class of risk from data workflows.](/blog/do-not-give-agents-production-keys/) [5 min read →](/blog/do-not-give-agents-production-keys/) --- ## Source: https://onequery.dev/blog/category/usecase/ OneQuery # Blog [All](/blog/)[Product](/blog/category/product/)[Engineering](/blog/category/engineering/)[Safety](/blog/category/safety/)[Usecase](/blog/category/usecase/) 3 posts [![OneQuery logo connected to the Jam logo with a heart symbol.](/_astro/hunting-web-bugs-with-jam-and-agents-icon.DKMI9A2V_miwGz.webp)](/blog/hunting-web-bugs-with-jam-and-agents/) [Usecase / Jul 23, 2026](/blog/hunting-web-bugs-with-jam-and-agents/) ## [Hunting web bugs with Jam and agents](/blog/hunting-web-bugs-with-jam-and-agents/) [A reproducible browser QA loop that turns agent findings into verified Jam evidence, bounded diagnostics, and actionable issue handoffs.](/blog/hunting-web-bugs-with-jam-and-agents/) [7 min read →](/blog/hunting-web-bugs-with-jam-and-agents/) [![Safe internal data analysis with Hermes Agent and OneQuery - OneQuery blog cover image.](/_astro/safe-internal-data-analysis-with-hermes-agent-and-onequery-icon.DouhLRVV_Z14LiOb.webp)](/blog/safe-internal-data-analysis-with-hermes-agent-and-onequery/) [Usecase / Jul 9, 2026](/blog/safe-internal-data-analysis-with-hermes-agent-and-onequery/) ## [Safe internal data analysis with Hermes Agent and OneQuery](/blog/safe-internal-data-analysis-with-hermes-agent-and-onequery/) [How to let Hermes Agent answer internal data questions from Slack, Discord, or Telegram without exposing raw credentials, write access, or unbounded query cost.](/blog/safe-internal-data-analysis-with-hermes-agent-and-onequery/) [6 min read →](/blog/safe-internal-data-analysis-with-hermes-agent-and-onequery/) [![Using LLM telemetry to improve prompts with GEPA - OneQuery blog cover image.](/_astro/using-llm-telemetry-to-improve-prompts-with-gepa-icon.CNdiHKKf_ZAe4U7.webp)](/blog/using-llm-telemetry-to-improve-prompts-with-gepa/) [Usecase / Apr 30, 2026](/blog/using-llm-telemetry-to-improve-prompts-with-gepa/) ## [Using LLM telemetry to improve prompts with GEPA](/blog/using-llm-telemetry-to-improve-prompts-with-gepa/) [A practical workflow for using OneQuery to let a GEPA reflection agent inspect Laminar LLM telemetry while improving prompts.](/blog/using-llm-telemetry-to-improve-prompts-with-gepa/) [7 min read →](/blog/using-llm-telemetry-to-improve-prompts-with-gepa/) --- ## Source: https://onequery.dev/blog/context-enrichment-with-onequery/ --- category: Engineering title: Context Enrichment with OneQuery description: A practical workflow for implementing the context enrichment layer described in OpenAI's in-house data agent writeup with schema facts, bounded SQL evidence, and code references. coverImage: src: ../../assets/blog/context-enrichment-with-onequery-icon.png alt: Context Enrichment with OneQuery - OneQuery blog cover image. publishedAt: 2026-05-01 readTime: 7 min read --- ## From Context Enrichment to Implementation OpenAI's writeup on its in-house data agent describes context enrichment as a layer that derives code-level definitions of tables, captures usage context from systems beyond SQL, and helps an agent distinguish between tables that look similar but differ in critical ways: https://openai.com/index/inside-our-in-house-data-agent/ This post covers how to implement that Context Enrichment idea with OneQuery. The goal is to turn raw source metadata into operational memory an agent can actually use: which tables exist, what columns mean, how freshness and soft deletes work, where application code proves those assumptions, and which claims should stay uncertain. The example implementation repo is available here: https://github.com/wordbricks/onequery-context-enrichment OneQuery is a good boundary for this workflow because the agent can inspect real data through scoped, audited, read-only access without receiving database credentials or bypassing source permissions. ## Why Context Enrichment Matters ![Diagram showing an agent making a wrong SQL guess from a JSONB settings column, then improving the query after code context reveals canonical connection records.](../../assets/blog/context-enrichment-jsonb-code-context.png) Context enrichment matters because table and column names are often plausible but incomplete. JSONB columns make this especially obvious. A column named metadata, properties, payload, settings, or attributes may contain dozens of nested fields whose meaning depends on application code, event producers, serializers, feature flags, and migration history. For example, suppose an analyst asks which integrations are most often configured by active teams and the agent finds a teams table with a jsonb column named settings. A bounded sample might show keys like integrations, sync, enabled, provider, and lastSeenAt. From the column name and raw values alone, the agent may assume settings->'integrations' is the current source of truth, count every provider with enabled = true, and group by lastSeenAt as if it were the last successful sync time. That analysis can be confidently wrong. The codebase might reveal that settings->'integrations' is a legacy UI cache, that the real enabled state is derived from connection records, that lastSeenAt is only updated when the settings panel is opened, and that provider names are normalized by a serializer before they appear in product analytics. In that case, the JSON shape is real, but the analysis based on it answers the wrong operational question. Code base context enrichment changes the result. By searching type definitions, zod schemas, serializers, route handlers, analytics producers, and query builders, the runner can discover which JSONB keys are persisted inputs, which are denormalized cache, which are deprecated, and which require a join to a canonical table. With that context, the agent can count active integrations from the connection lifecycle table, use settings only as supporting evidence, normalize provider names the same way the product does, and explain why the JSONB column should not be treated as authoritative on its own. ## What Context Enrichment Produces The output of context enrichment should be more specific than a schema dump. A useful run produces table memos, column memos, code evidence, and context documents that can be reviewed, indexed, or handed to downstream agents. A table memo describes the role of a table, important lifecycle rules, confidence, row counts, freshness, and caveats. A column memo explains business meaning, joins, nullability behavior, redaction expectations, and the evidence behind the explanation. The key requirement is provenance. Every high-confidence claim should be traceable to a schema query, a bounded data sample, or a code reference. Claims without evidence should stay low confidence or remain explicitly unknown. | Artifact | Purpose | | ----------------------- | -------------------------------------------------------------------------------------------- | | tables.json | Normalized table and column inventory from the selected OneQuery source. | | table_memos.json | Human-readable table descriptions, lifecycle notes, confidence, caveats, and evidence links. | | column_memos.json | Column-level semantics, joins, privacy notes, usage patterns, and uncertainty. | | code_evidence.jsonl | File and line references showing how application code reads or names the database objects. | | context_documents.jsonl | Chunked documents suitable for retrieval, review, or agent context injection. | ## Use OneQuery as the Boundary The first design choice is to put OneQuery between the agent and the database. The agent should resolve its organization, source, and permissions through OneQuery, then use OneQuery execution for every database read. A practical run starts by checking the active identity with onequery auth whoami, resolving the organization and source, and recording those identifiers in the run metadata. From there, all SQL goes through the selected OneQuery source. This keeps credentials out of the agent runtime. It also gives operators a single place to enforce read-only validation, single-statement execution, row limits, timeouts, source permissions, and audit trails. ## Collect Database Evidence First ![Diagram showing a source database flowing through schema inspection and bounded SQL checks into a table memo.](../../assets/blog/context-enrichment-database-evidence.png) Start with the database, not the application code. Query information_schema for the requested tables, columns, data types, nullability, defaults, and primary key hints. If the table is missing, record that as a finding instead of inventing a nearby table. Then run small, bounded aggregate queries for facts that help agents reason correctly: approximate row counts, soft-delete counts, freshness timestamps, status distributions, visibility flags, and nullable foreign keys. The point is not to dump rows. The point is to gather enough facts to describe behavior. Every query should be narrow and reviewable. In the demo runner, ad hoc exploration used small limits, aggregate-only probes where possible, and explicit validation before execution. That makes the enrichment repeatable and easier to audit. ## Add Code Evidence ![Diagram showing table facts enriched by code search across types, queries, routes, and serializers before producing a column memo.](../../assets/blog/context-enrichment-code-evidence.png) Schema facts explain what exists. Code evidence explains how the product treats it. After resolving the relevant GitHub source through OneQuery, the enrichment run can search the repository for table names, generated types, query builders, routes, serializers, and domain-specific aliases. The runner should store concrete file paths and line numbers, not vague summaries. A memo that says a column is a public identifier is much stronger when it links to the route or projection that uses that column as the public lookup key. Code evidence is also where enrichment catches product vocabulary. In the demo, application behavior for public apps was represented through project projections and types, even though the requested public.apps table did not exist in the selected database source. ## Preserve Uncertainty ![Diagram showing requested objects verified as found or absent, then written into context documents as confirmed facts, caveats, and unknowns.](../../assets/blog/context-enrichment-preserve-uncertainty.png) The most important rule is to preserve uncertainty. If a table is absent from the selected source, the output should say that directly. If a column appears sensitive but the code does not prove redaction behavior, the memo should flag the risk instead of claiming safety. This matters because context enrichment becomes a dependency for later agents. A confident but false memo can steer future SQL, product analysis, or support answers in the wrong direction. A precise caveat is more useful than an invented explanation. A good output can still be helpful when something is missing. For example, it can record the absent table, list the evidence checked, and point to the closest verified table or code path as an alternative. ## Demo Run Shape The context-enrichment demo used OneQuery to enrich three requested objects in the public schema: users, projects, and apps. The run resolved the organization and source, inspected schema metadata, ran bounded evidence queries, searched the linked codebase, and emitted JSON artifacts. The repository for the demo runner is here: https://github.com/wordbricks/onequery-context-enrichment The result found public.users and public.projects in the selected source and generated memos for their table and column behavior. It also reported that public.apps was absent from information_schema for that source, then connected the application-level app behavior to verified public.projects usage instead. That result is the workflow working as intended. The agent did not need raw database credentials, did not assume a missing table existed, and still produced reviewable context that connects database facts to product code. ## Make It Repeatable For production use, treat enrichment as a run with state rather than a one-off chat. Create a run directory, persist request metadata, append events, write intermediate artifacts, validate final JSON, and make repair steps explicit. That shape gives teams a review surface. They can diff table memos across schema changes, inspect the exact queries and code references behind a claim, and decide which context documents should be published to a retrieval system. OneQuery supplies the controlled data path. The enrichment runner supplies the repeatable artifact pipeline. Together they give agents enough context to reason about real systems without turning the agent runtime into a credential vault. --- ## Source: https://onequery.dev/blog/debug-production-agent-runs-with-onequery/ --- category: Engineering title: Debugging production on Cloudflare with Codex. description: How Codex can use OneQuery-connected Cloudflare logs to inspect production failures, separate evidence from guesses, and make targeted code changes. coverImage: src: ../../assets/blog/debug-production-agent-runs-with-onequery-icon.png alt: Debugging production on Cloudflare with Codex - OneQuery blog cover image. publishedAt: 2026-05-06 readTime: 4 min read --- ## The Concept: Connect Cloudflare Logs to Codex ![Diagram showing Codex querying Cloudflare Worker logs through OneQuery and turning evidence into a pull request.](../../assets/blog/debug-production-agent-runs-with-onequery-access-path.png) The concept is not to give Codex raw production credentials. The concept is to connect a production telemetry source to OneQuery, then let Codex ask bounded questions through that source while OneQuery handles auth, source scope, and auditability. For a Cloudflare-deployed app, that source can be Cloudflare Workers Observability. Codex can discover which fields exist, filter by service, inspect failure messages, and correlate request IDs or run IDs without opening a Cloudflare dashboard session. This gives the agent a production debugging loop: observe the failure, query logs, narrow the evidence, inspect the relevant code, make a small patch, and verify it. The agent is not guessing from the UI state alone. ## The Loop: Discover, Filter, Summarize ![Diagram showing the production log investigation narrowing from discovered fields to filters and a summarized failure pattern.](../../assets/blog/debug-production-agent-runs-with-onequery-evidence-loop.png) A useful debugging agent starts with discovery. It asks what the source can expose before it assumes the schema: fields, services, log levels, messages, workflow names, request IDs, and application-specific IDs. Then it narrows the window. Instead of reading every log line, Codex can filter to one Cloudflare service, one recent timeframe, one failure message, or one run ID. Each query becomes a smaller question. Only after that does it summarize. The output should be evidence, not vibes: which trigger failed, which provider emitted the error, whether manual runs and scheduled runs behave differently, and which code path should be inspected next. ## Example: Fireworks Rate Limits ![Diagram showing scheduled failures and provider limits becoming a default model change and pull request.](../../assets/blog/debug-production-agent-runs-with-onequery-root-cause.png) The Fireworks AI incident is one example of this pattern, not the only use case. In that run, Codex was asked to use the cloudflare-wordbricks source to investigate why recent agent runs failed on the velen-web-production Cloudflare service. ![Codex investigating a production agent run failure with the onequery-cli skill and cloudflare-wordbricks source.](../../assets/blog/debug-production-agent-runs-with-onequery-codex-screen.png) The agent first found a plausible code issue in a separate path: provider secrets were available on the Worker env binding but not necessarily in process.env, while the AI SDK provider constructors read process.env. That was worth fixing, but it was not enough to explain the fresh failures. The production logs told a sharper story. In the sampled window, manual runs had no matching failures, while scheduled runs repeatedly failed with Fireworks rate limit errors. That changed the fix from a generic runtime suspicion into an operationally targeted change. ![Codex reporting the production investigation result with a Fireworks API rate limit cause and recent failure summary.](../../assets/blog/debug-production-agent-runs-with-onequery-codex-result.png) ## What the Agent Changed Once the example root cause was clear, the code change was small. Codex moved the shared default model away from the Fireworks-backed default and onto google/gemini-3-flash-preview, added the UI label, and kept the model-specific truncation policy exhaustive. The important part is not that every team should make the same model choice. The important part is that the agent used production evidence to choose the right class of fix before touching code. | Change | Why it mattered | | --------------------------------------- | --------------------------------------------------------------------------------------------- | | DEFAULT_AGENT_LLM_MODEL -> Gemini Flash | New runs without an override avoid the Fireworks quota path. | | Model option added to the UI | Operators can choose the same model explicitly instead of relying only on the shared default. | | Truncation policy updated | The type union stays exhaustive when a new model is introduced. | | PR created with auto-merge | The debugging session ended as a reviewable production change, not a loose diagnosis. | ## The Debugging Loop We Want The reusable pattern is simple: connect production evidence through OneQuery, let the agent inspect only the source and operations it is allowed to use, then require the final output to be a narrow code change with tests and review. That gives the agent a better debugging loop without giving it raw production authority. It can see enough to be useful, but the source boundary, audit trail, and execution controls stay outside the model. The Fireworks example happened to end in a default-model change. Another incident might end in a retry policy, a workflow timeout fix, a webhook handler patch, or a better UI error state. The concept stays the same: Codex reads bounded production telemetry, then changes code based on evidence. --- ## Source: https://onequery.dev/blog/do-not-give-agents-production-keys/ --- category: Safety title: Do not give agents the keys to production description: Why autonomous agents should never hold raw production access, and how OneQuery removes that class of risk from data workflows. coverImage: src: ../../assets/blog/do-not-give-agents-production-keys-icon.png alt: Do not give agents the keys to production - OneQuery blog cover image. publishedAt: 2026-04-29 readTime: 5 min read --- ## Agents are not operators A human operator usually understands the difference between a staging task, a production database, a backup volume, and an irreversible infrastructure mutation. An agent does not have that operational judgment by default. It has a goal, a context window, tools, and whatever credentials the environment exposes. That distinction matters because modern agents are not passive autocomplete. They inspect files, retry failed commands, search for credentials, call APIs, and chain small steps into larger actions. When the surrounding environment gives the agent broad authority, the model's mistake becomes the system's mistake. A recent public incident report described exactly this pattern: an agent working on a deployment problem allegedly found an infrastructure token and called a destructive API against production storage. Whether every detail of that report is later confirmed is less important than the architecture lesson. If the agent can reach production destruction paths, you are trusting the model as an operator. The incident report is here: https://x.com/lifeof_jer/article/2048103471019434248. In short, the author says an AI coding agent found an infrastructure token while debugging a staging issue, used it against production, deleted a database volume and its nearby backups, and left the team reconstructing recent customer data from secondary systems. The lesson is not vendor-specific: if an agent can see a powerful credential, it can turn a flawed plan into an irreversible production action. ## Prompting cannot be the boundary Teams often respond to agent risk by adding rules: never touch production, ask before deleting data, use staging only, avoid destructive commands. Those rules are worth writing because they guide normal behavior. They are not a security boundary. A prompt can be ignored, misunderstood, bypassed by tool output, or defeated by an unexpected recovery path. It also cannot change the permission model of a token that already exists in the runtime. If an API credential can delete a production volume, the model has the ability to ask the API to delete a production volume. The real boundary has to live below the agent. Tokens must be scoped. Operations must be policy-checked. Dangerous actions must require an external approval path. Backups must sit outside the blast radius of the resource they protect. Failures must become lifecycle states the workflow can handle, not exceptions the agent tries to work around with more authority. ![Illustration of an AGENTS.md markdown file with rules like never touch production, pointing to a policy gate and an enforced real boundary.](../../assets/blog/prompting-cannot-be-the-boundary.png) ## The direct-access failure mode The dangerous architecture is simple. The agent runtime can read secrets. The secrets can reach production. The production API can perform destructive mutations. The backups sit close enough to the primary resource that the same action, token, or account can destroy both. In that setup, every safety property depends on the agent choosing correctly at every step. That is not operational control. It is hope wrapped in automation. ![Diagram showing an AI agent with direct access to an unbounded runtime, raw secrets, API tokens, production databases, and backups in the same blast radius.](../../assets/blog/agent-production-direct-access-risk.png) ## What companies actually need Companies need agents to be capable, but capability has to be narrowed into explicit workflows. For data work, the agent should be able to ask questions, plan queries, inspect schema context, explain assumptions, and repair safe failures. It should not hold raw database passwords, warehouse admin tokens, or SaaS credentials with write access. The execution layer should enforce read-only behavior, single-statement constraints, source and role permissions, timeouts, row limits, budget limits where providers support them, and complete audit trails. A denied query should be a normal result that the agent can explain. A missing permission should trigger a request path. A destructive operation should not be available to the model at all. This is also how teams keep responsibility legible. When something goes wrong, operators need to know who asked, which source was used, what query ran, what policy allowed it, what data came back, and which step failed. Agent transcripts are useful context, but they are not a control plane. ## Where OneQuery fits OneQuery removes the direct-access path for data agents. The model does not need raw source credentials. It asks OneQuery to execute a bounded data operation, and OneQuery applies the source configuration, organization permissions, validation rules, execution limits, and audit logging before the request reaches a connected system. That separation changes the risk profile. The agent can still be useful: it can translate intent, choose the relevant source, draft SQL, interpret results, and explain caveats. But the dangerous authority moves out of the model runtime and into deterministic product behavior. For teams building internal agents, this means they can integrate real company data without handing the agent the keys to every database and SaaS account. The agent gets a tool. OneQuery keeps the keys, the policies, and the record of what happened. ![Diagram showing an agent sending requests through OneQuery, where RBAC, safe execution, audit logging, and write denials sit between the agent and scoped read-only data sources.](../../assets/blog/onequery-bounded-agent-access.png) ## Trust the workflow, not the agent The right goal is not to fully trust agents. The right goal is to trust the workflow around them. Agents should be good at language, planning, retrieval, and repair. Systems should be good at permissions, validation, state transitions, and irreversible decisions. When those responsibilities are mixed together, the model becomes an untrained operator with production access. When they are separated, the agent can move quickly inside a narrow, auditable path. That is the difference between useful autonomy and a failure mode no one can unwind. OneQuery exists for that separation. It lets teams adopt data agents without turning every prompt into a production access decision. --- ## Source: https://onequery.dev/blog/e2b-source-api-connection/ --- category: Product title: Connect E2B to OneQuery description: OneQuery now supports E2B as a connected Source API for reading sandbox state, lifecycle events, logs, and metrics without exposing raw credentials to agents. coverImage: src: ../../assets/blog/e2b-source-api-connection-icon.png alt: OneQuery logo connected to the E2B logo with a heart symbol. publishedAt: 2026-06-22 readTime: 3 min read --- ## E2B is now a connectable source OneQuery now supports [E2B](http://e2b.dev/) as a connected data source. Teams that run agent workloads in E2B sandboxes can add an E2B API key once, name the source, and let approved tools inspect sandbox operations through OneQuery's Source API boundary. The point is not to give every agent an E2B token. The point is to make sandbox visibility available through the same controlled access path used for databases, analytics tools, observability systems, and developer platforms. ## What agents can inspect The E2B integration is read-only. It exposes sandbox context that is useful for operations, debugging, and cost awareness: | Endpoint | What it shows | | -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | | `/sandboxes` | Running sandboxes visible to the connected E2B team, including state, start time, end time, template ID, CPU, memory, disk, and metadata. | | `/events/sandboxes` | Recent sandbox lifecycle events for the team. | | `/events/sandboxes/{sandboxId}` | Lifecycle history for one sandbox, including create and update events. | | `/v2/sandboxes/{sandboxId}/logs` | Sandbox logs, process starts and exits, file reads and writes, command traces, and envd/orchestration messages. | | `/sandboxes/{sandboxId}/metrics` | CPU, memory, and disk metrics over time for one sandbox. | That makes it possible to ask concrete operational questions: how many sandboxes are running, which agent run created a sandbox, when a timeout was extended, what commands executed, whether memory usage spiked, or whether a sandbox is still active after a chat or workflow finishes. ## Keep lifecycle control separate The integration intentionally supports GET requests only. Sandbox lifecycle mutations such as create, kill, pause, resume, refresh, and network updates are not exposed through this Source API adapter. That boundary matters. Reading sandbox evidence is useful for debugging and operations. Changing sandbox state is a control-plane action that should stay behind explicit product workflows, permissions, and audit decisions. In practice, an agent can inspect E2B state through OneQuery, summarize what is happening, and point to the specific sandbox, run ID, organization metadata, or log event that needs attention. It does not need raw E2B credentials in its prompt or runtime environment. ## A better debugging loop for sandboxed agents Agent systems often need to answer questions that cross product state and sandbox state. A chat session may reuse a sandbox. A scheduled agent run may leave one running until timeout. A source query may write evidence files into the sandbox. Without a connected sandbox source, the debugging loop usually requires someone to jump into a vendor dashboard or search logs by hand. With E2B connected to OneQuery, the loop becomes simpler: 1. List running sandboxes. 2. Map sandbox metadata back to an agent run, chat session, organization, or persona. 3. Pull lifecycle events to see when the sandbox was created or extended. 4. Inspect logs to understand what executed. 5. Review metrics to spot CPU, memory, or disk pressure. This keeps agent debugging evidence-based. The agent can report what it found from bounded source calls instead of guessing from application symptoms alone. ## How it fits the OneQuery model E2B joins the growing set of sources that are not SQL databases but still matter to agent workflows. For these sources, OneQuery uses Source API operations instead of SQL. The same source catalog, credential handling, access checks, and audit expectations still apply. Connect E2B once, expose it as a named source such as `e2b://E2B`, and let approved workflows call read-only endpoints when they need sandbox context. --- ## Source: https://onequery.dev/blog/how-startups-can-build-an-in-house-data-agent/ --- category: Product title: How startups can build an in-house data agent description: A practical startup playbook for turning an AI data agent from a risky demo into a safe, contextual, auditable workflow. coverImage: src: ../../assets/blog/how-startups-can-build-an-in-house-data-agent-icon.png alt: How startups can build an in-house data agent - OneQuery blog cover image. publishedAt: 2026-04-28 readTime: 6 min read --- ## What OpenAI actually built OpenAI's internal data agent helps employees move from a natural-language question to a working analysis. It can inspect available data, draft SQL, execute queries, look at intermediate results, revise its approach, and summarize the answer in the same places employees already work. The important detail is that it is not just a text-to-SQL box. It behaves more like an analytical teammate inside an internal data system. If a query returns no rows, a join looks suspicious, or a filter is ambiguous, the workflow can recover instead of stopping at the first generated query. That is the practical bar for startups. A useful data agent should not only produce plausible SQL. It should help the team reason through data with enough context, guardrails, and traceability to trust the result. ## The hard part is context, not chat The hardest part is not generating syntactically valid SQL. The hard part is knowing what the data means. A table named users might include deleted users, internal test accounts, anonymous visitors, or only fully onboarded customers. A revenue metric might mean invoices, payments, bookings, recognized revenue, or net revenue after refunds. Those definitions rarely live in one clean place. They are spread across schemas, prior queries, dashboard logic, transformation code, product docs, support investigations, Slack threads, and the memory of domain experts. Startups do not need a perfect catalog on day one. They need the top tables, the top metrics, common joins, known caveats, and a small set of canonical queries. The best seed set is usually the last month of questions people repeatedly asked in Slack, dashboards, notebooks, and customer investigations. ## The hidden risk of direct source access A data agent becomes useful when it can access real systems. It also becomes dangerous at exactly the same moment. To answer meaningful business questions, the agent often needs access to production databases, warehouses, product analytics, billing tools, observability systems, CRMs, support platforms, and internal APIs. Without a safety layer, direct access creates obvious failure modes. A model can generate destructive SQL against a write-capable connection. It can expose customer emails, billing records, employee data, support conversations, or security logs through an overprivileged shared credential. It can leak API keys, OAuth tokens, database passwords, or warehouse credentials if secrets are visible inside the agent runtime. It can also create operational and financial risk. A bad BigQuery, Athena, or Snowflake query can scan too much data. A repeated retry loop can overload a production database. If the system does not record who asked the question, which source was used, what SQL ran, and what result came back, the team cannot investigate incidents or improve the workflow. ## A startup-friendly blueprint The startup version should start with secure access. Use read-only credentials by default, separate permissions by source and role, and avoid exposing raw secrets to the model. The agent should ask a controlled execution layer to run a query; it should not freely connect to databases from its own runtime. Next, make query execution safe. Enforce single-statement queries, block destructive SQL, apply row limits, set timeouts, cap query cost where the provider supports it, and return structured failures that the agent can reason about. Permission denials, budget limits, empty results, stale data, and syntax errors should be normal lifecycle states. Then keep the agent loop small. The workflow should classify the question, retrieve table and metric context, draft SQL, validate it, execute it through a safe layer, inspect the result, retry only when the failure is understood, and return the answer with the SQL, assumptions, source, and caveats attached. ## Where OneQuery fits OneQuery gives teams the layer an in-house data agent needs before it becomes useful: safe connections, controlled execution, permissions, and an audit trail. Instead of wiring an agent directly into every database and SaaS API, teams can put OneQuery between the agent and their external data sources. The agent handles intent, planning, SQL generation, summarization, and repair. OneQuery handles the dangerous middle: centralized credential management, read-only validation, single-statement enforcement, query cost limits for supported providers, organization and role-based access control, and audit logs. This division makes the product easier to trust. Teams can improve the agent's prompts, retrieval, memory, and evaluations without giving the model unchecked access to the data stack. When an answer is wrong, they can review the exact query path instead of guessing what happened inside an agent transcript. ## Reference architecture In this architecture, the agent does not hold credentials to every external data source. The user interacts through Slack, web, an IDE, or another agent interface. The agent orchestrator interprets the request and plans the analysis. When it needs data, it goes through OneQuery. OneQuery becomes the trusted query layer. It applies permissions, audit logging, safety checks, execution limits, and source-specific controls before any query reaches a connected database, warehouse, or SaaS API. The result flows back to the agent, which summarizes the answer with the SQL, assumptions, caveats, and result context. ![Diagram showing a user interface, agent orchestrator, OneQuery trusted query layer, connectors, external data sources, risks, and result assumptions.](../../assets/blog/how-startups-can-build-an-in-house-data-agent-diagram.png) ## What not to do first Do not give an agent production database write credentials. Do not connect every data source on day one. Do not expose every internal API and tool just because it is technically possible. Do not use one shared admin credential for all users. Do not run warehouse queries without cost limits, row limits, or timeouts. Do not let the model see raw tokens, passwords, or API keys. Do not ship an agent without audit logs. Do not assume that a fluent answer is a correct answer. The fastest way to lose trust in a data agent is to let it produce confident answers that nobody can inspect, reproduce, or constrain. ## Better grounded and better guarded OpenAI's in-house data agent shows where data work is going. People should be able to ask complex questions in natural language and get useful, contextual, trustworthy answers without waiting days for manual analysis. The lesson for startups is not to copy OpenAI's entire internal system. The lesson is to build the right foundation first. A reliable in-house data agent needs access to real company data, but that access must be controlled. It needs context, but that context must be maintained. It needs autonomy, but that autonomy must run inside clear safety boundaries. With a trusted query layer in place, teams can build data agents that are not only more powerful, but safer, more transparent, and easier to trust. --- ## Source: https://onequery.dev/blog/hunting-web-bugs-with-jam-and-agents/ --- category: Usecase title: Hunting web bugs with Jam and agents description: A reproducible browser QA loop that turns agent findings into verified Jam evidence, bounded diagnostics, and actionable issue handoffs. coverImage: src: ../../assets/blog/hunting-web-bugs-with-jam-and-agents-icon.png alt: OneQuery logo connected to the Jam logo with a heart symbol. publishedAt: 2026-07-23 readTime: 7 min read --- ## A bug hunt is an evidence pipeline Browser agents can cover a surprising amount of product surface. They can move through onboarding, CRUD flows, search, sharing, settings, empty states, responsive layouts, keyboard navigation, console errors, and failed network requests without waiting for a manual test script. The hard part is not finding something that looks wrong. The hard part is proving that it is a real, reproducible bug and leaving enough evidence for the next person or agent to act on it. That is where [Jam](https://jam.dev/) fits. A Jam can keep the page URL, screenshot or video, console output, network activity, user events, and reproduction context together. Instead of handing engineering a sentence like "the form sometimes breaks," the hunting agent can hand off one inspectable record of what happened. The workflow we use follows one rule: publish fewer findings, but make every published finding reproducible. ![Diagram showing a verified Jam bug hunt moving from agent-browser exploration through twice-reproduced verification and duplicate checks to Jam evidence, OneQuery read-only diagnostics, and Linear Triage.](../../assets/blog/hunting-web-bugs-with-jam-and-agents-workflow.png) ## The loop The complete loop is: ```text Explore -> observe -> reproduce twice -> check for an existing Jam -> capture evidence -> publish and verify the Jam -> hand off to the correct triage queue -> verify the handoff ``` Each step removes a different source of noise. Exploration finds candidate problems. Reproduction filters out transient glitches. Duplicate checks keep the evidence system usable. Jam preserves the browser state. Verification catches failed or malformed publications. The tracker handoff gives the issue an owner without losing the original diagnostics. ## Start as a black-box tester The hunting agent should behave like a user, not like a developer reading the implementation. It maps visible navigation, exercises realistic goals, and judges only observable behavior. A useful default scope includes: - Authentication entry and session expiry, with authentication completed before recording. - Primary creation and editing flows using disposable test data. - Onboarding, search, sharing, settings, and empty or error states. - Desktop first, then a mobile viewport such as `390x844`. - Keyboard focus, labels, contrast, clipped content, loading feedback, unclear errors, broken controls, console errors, and failed requests. At each meaningful state, the agent takes a fresh browser snapshot and inspects browser errors, console output, and network requests. Fresh snapshots matter because references to interactive elements can become stale after navigation or dynamic UI changes. Local or staging environments are the safest default. Production exploration should stay read-only unless someone has explicitly authorized state-changing actions. Dedicated test accounts and seeded data also keep customer information out of screenshots and recordings. ## Reproduce before recording An observation becomes a candidate bug only after the agent can return to a known state and reproduce it at least twice. For each candidate, record: | Evidence | Why it matters | | ---------------------------- | --------------------------------------------------------------- | | Exact URL | Identifies the affected route and state. | | Viewport | Separates responsive defects from general defects. | | Account role | Makes permission and role-specific behavior visible. | | Expected behavior | Defines the product contract being violated. | | Actual behavior | Describes the observable failure without guessing at the cause. | | Minimal steps | Gives another tester the shortest path back to the failure. | | Console and network evidence | Connects the visible symptom to browser diagnostics. | Subjective preferences are not automatically bugs. A UX finding should point to observable friction: a blocked goal, misleading label, missing feedback, inaccessible interaction, inconsistent control, or violated interface pattern. Before creating anything, search existing Jams for the same route and symptom. If the same root issue already exists, record a sanitized recurrence instead of creating another report. If the environment or reproduction is materially different, create a new Jam and cross-link it. ## Match the capture to the failure Static UI, content, and accessibility bugs usually need a clean screenshot for Jam plus an annotated copy for the local report. Timing, state, and interaction bugs need a short video that starts from a clean precondition and stops when the failure is visible. The capture should show the bug, not the tester getting ready to show the bug. Authenticate before recording. Move at a human-readable pace. Avoid unrelated tabs and notifications. Never upload credentials, cookies, customer PII, payment data, private prompts, or tokens. Create the Jam while the reproduction state is still available, then add the structured details as a comment: ```text Title: [Agent QA][app][severity][category] observable symptom URL and viewport Account role and environment Expected behavior Actual behavior Minimal reproduction Sanitized console and network observations Local evidence paths ``` Finally, read the Jam back and verify its ID, URL, title, and evidence. If publishing fails, keep the local artifacts. A failed upload should not erase the work that proved the bug. ## Keep Jam diagnostics bounded with OneQuery Publishing and reading are separate responsibilities in this workflow. The hunting agent uses Jam's own CLI to create the evidence record. A Jam source connected to OneQuery gives later agents a controlled, read-only path to inspect that record through Jam's official MCP endpoint. OneQuery stores the workspace connection and exposes only an approved set of diagnostic operations: | Operation | What an agent can learn | | --------------------------------------- | -------------------------------------------------------------- | | `listJams` | Find existing reports and check for likely duplicates. | | `getDetails` and `getMetadata` | Read the report context and capture metadata. | | `getConsoleLogs` | Inspect browser errors and relevant console output. | | `getNetworkRequests` | Review failed or suspicious requests around the reproduction. | | `getUserEvents` | Reconstruct the recorded interaction sequence. | | `getVideoTranscript` and `analyzeVideo` | Understand longer reproductions without scrubbing manually. | | `listFolders` and `listMembers` | Resolve visible workspace organization and membership context. | Comment creation, Jam updates, and screenshot binary retrieval are not exposed through the OneQuery Jam adapter. That boundary is deliberate: an analysis or triage agent can inspect the evidence it needs without silently editing the source report. This also keeps the Jam token out of the agent prompt and runtime. The agent calls a named OneQuery source, OneQuery applies the source permissions and approved operation list, and the result remains attributable to that access path. ## Hand verified evidence to triage A Jam is the reproduction record. A tracker issue is the unit of planning and ownership. The handoff should link the two instead of copying fragments of browser evidence into an untraceable summary. For a Linear handoff, the agent should: 1. Resolve the product's exact owning team from verified workspace information. 2. Require that team's real `Triage` state instead of guessing at a similar queue. 3. Search for an issue carrying the Jam's stable identity marker. 4. Reuse one verified match, block on multiple matches, and create only when none exist. 5. Include the clickable Jam URL, route, viewport, severity, expected behavior, actual behavior, and minimal reproduction. 6. Read the issue back and verify the team, state, title, Jam URL, and identity marker. The duplicate checks happen on both sides. Jam deduplication keeps evidence coherent. Tracker deduplication prevents two planning records from competing for the same verified report. ## Failure should preserve evidence Automation becomes trustworthy when partial failure has an explicit state. | Failure | Safe behavior | | --------------------------------------- | ---------------------------------------------------------------------- | | The observation cannot be reproduced | Keep it local as `needs_review`; do not publish. | | Jam publishing fails | Preserve screenshots, videos, notes, and the exact error. | | Jam succeeds but tracker creation fails | Keep the verified Jam and mark the handoff as blocked. | | Team ownership is ambiguous | Create no tracker issue until ownership is resolved. | | A tracker response is ambiguous | Read back the result; never create a second issue as a repair attempt. | | Sensitive data cannot be excluded | Keep evidence local and report the upload blocker. | This is more useful than an all-or-nothing script. A verified Jam still has value when the tracker is unavailable. Local evidence still has value when publication is blocked. Nothing needs to be invented or duplicated to make the run look successful. ## A practical request for an agent A good bug-hunt request defines the target, environment, scope, and stopping condition: ```text Dogfood the staging web app as a black-box user. Cover the primary creation flow, settings, and one mobile viewport. Reproduce every candidate issue twice. Publish one Jam per verified issue and avoid duplicates. Use OneQuery for read-only Jam diagnostics and the approved Linear handoff. Stop after five verified issues or when the core scope is exhausted. Do not fix code during the hunt. ``` Separating hunting from fixing is important. The hunt optimizes for broad exploration and high-confidence evidence. A later engineering agent can take one verified issue, inspect the relevant implementation, make a narrow change, and use the Jam reproduction as its acceptance test. ## What this changes Jam makes browser evidence portable. OneQuery makes that evidence available to agents through a bounded read path. A verified tracker handoff makes the result operational. Together, they turn autonomous QA from a stream of screenshots into a repeatable system: explore like a user, prove the failure, preserve the browser context, expose diagnostics without exposing raw credentials, and hand one verified issue to the team that can act on it. --- ## Source: https://onequery.dev/blog/llm-safe-data-access-layer/ --- category: Safety title: A Safe Data Access Layer for LLMs description: How OneQuery gives LLMs a safe, auditable data access layer without handing them raw production credentials. coverImage: src: ../../assets/blog/llm-safe-data-access-layer-icon.png alt: A Safe Data Access Layer for LLMs - OneQuery blog cover image. publishedAt: 2026-04-30 readTime: 4 min read --- ## LLM Risk Is Authority Risk ![Diagram contrasting direct LLM access to raw keys and production data with bounded access through OneQuery.](../../assets/blog/llm-safe-data-access-direct-vs-bounded.png) Using an LLM for data work is not dangerous by itself. The danger appears when the model gets too much authority. If database passwords, SaaS tokens, or warehouse admin credentials are available inside the agent runtime, the model's mistake can become the system's mistake. Adding a prompt rule like "never touch production" can guide normal behavior, but it is not a security boundary. A model can be influenced by tool output, try an unexpected recovery path after a failure, or simply use the permissions already attached to a token. The safer pattern is not to make the model promise to be careful. The safer pattern is to narrow the execution path around the model. The LLM can understand the question and draft SQL. OneQuery decides which source the request can use, which organization permissions apply, and which execution limits must be enforced. ## OneQuery Creates the Execution Boundary ![Diagram showing OneQuery query safety pipeline with source scope, read-only check, single statement enforcement, result window, and audit event.](../../assets/blog/llm-safe-data-access-query-pipeline.png) OneQuery's first job is to separate credentials from the model runtime. The agent does not need the original database password or API token. OneQuery manages the data source connection, and the agent sends bounded requests against sources it is allowed to use. The second job is to reduce what can execute. Before running a query, OneQuery applies read-only validation and single-statement enforcement. If the model accidentally drafts destructive SQL, the execution layer rejects it before it reaches the backing system. The third job is to bound the response. LLMs often ask for more data than they need. OneQuery uses timeouts, row limits, payload limits, and provider-specific cost limits where available so one query does not turn into excessive spend or unnecessary data exposure. ## Denials and Failures Are Normal Flow In a safe system, denial is not an incident. It is a normal lifecycle transition. A query that is not read-only becomes denied. A result that is too large becomes truncated. A missing permission becomes a permission failure. That distinction matters for LLM agents. Instead of throwing an exception that encourages the model to improvise a workaround, the system returns a clear state and reason. The agent can explain the result to the user or write a narrower query. This is also why OneQuery keeps an audit log. The question after a data action is not only "did it succeed?" Operators need to know who asked, which source was used, which SQL ran, which limits applied, and where the workflow failed if it failed. ## Connectors Keep Credentials Local ![Diagram showing OneQuery connector polling over outbound HTTPS while credentials remain inside customer infrastructure.](../../assets/blog/llm-safe-data-access-connector.png) For sensitive infrastructure, where credentials live matters. A OneQuery connector runs inside customer infrastructure, polls for work over outbound HTTPS, executes the query locally, and returns the result. For example, an Athena connector can use EC2 IAM Role credentials to run Athena queries inside the customer's environment. The OneQuery control plane coordinates the job and receives the result, but the original credential does not need to move into the hosted control plane. This is the practical compromise teams need for LLM adoption. The agent can answer from real operational data, but it does not directly hold the source credential. Operators manage source access, roles, validation, limits, and audit behavior at the product boundary. ## Trust the Workflow, Not the Model The goal of safe LLM usage is not to fully trust the model. The thing to trust is the workflow around the model. LLMs are good at language, planning, SQL drafting, and result interpretation. Deterministic systems are better at permission checks, credential management, write prevention, audit records, timeouts, and retries. OneQuery separates those responsibilities. The model asks the question. OneQuery keeps the boundary. That difference is what turns data agents from risky production access into useful automation. --- ## Source: https://onequery.dev/blog/making-data-source-setup-boring/ --- category: Product title: Making data source setup boring description: Replacing one-off connector setup with a predictable path for every database and analytics source. coverImage: src: ../../assets/blog/making-data-source-setup-boring-icon.png alt: Making data source setup boring - OneQuery blog cover image. publishedAt: 2026-04-21 readTime: 4 min read --- ## Why source setup stays messy Most teams do not set out to make data source setup complicated. It happens gradually. A warehouse connection starts in a notebook, a product analytics token lives in one person's password manager, a support integration is configured for a customer investigation, and a second version of the same source appears when a different team needs slightly different access. The problem is not only the number of sources. The problem is that each source gets its own setup path, credential habit, permission model, validation checklist, and failure mode. When the team later asks an agent or analyst to use that data, nobody can quickly tell which connection is current, who owns it, what it can access, or whether it is safe to query. Making setup boring means turning that scattered work into a predictable lifecycle. A source should move through the same visible states every time: requested, configured, validated, permissioned, used, monitored, rotated, and retired. ## Make configuration a product surface A data source is not connected when a credential works once. It is connected when the team can understand and operate it later. That requires a durable configuration record: source type, source identifier, credential location, allowed interfaces, owner, environment, budget limits, timeout behavior, and the validation checks that proved the connection is usable. This is where a shared control plane matters. Instead of treating every connector as a custom script, OneQuery gives the team one place to manage the source definition and one path for CLI, web, and agent workflows to use it. The operational details are still visible, but they stop being tribal knowledge. A boring setup path should also be reviewable. If a credential changes, a source is renamed, or a new interface is enabled, the team should be able to see that transition as part of the source lifecycle rather than reconstruct it from chat messages and application logs. ## Validate before anyone depends on it The cheapest time to find a broken source is before a dashboard, agent workflow, or customer investigation depends on it. Validation should be explicit: can the service authenticate, can it list the expected schema or resource, can it execute a minimal read, does it respect read-only policy, and does it fail clearly when access is missing? For databases and warehouses, validation should include query safety constraints such as single-statement execution, read-only enforcement, timeout behavior, and cost boundaries where the provider supports them. For APIs and analytics tools, validation should confirm the workspace, project, account, or organization that the credential actually reaches. This turns source setup into a deterministic workflow instead of a best-effort checklist. Success and failure are normal states. Retry is a transition. The team can see what failed, fix the specific input, and run the same validation path again. ## Centralize credentials without hiding risk Central credential management is useful only if it improves both safety and operability. It should remove secrets from laptops, scripts, notebooks, and agent prompts. It should also make it clear which workflows can use a credential, which people can trigger those workflows, and which actions require additional approval. OneQuery's role is to let teams connect sources once and expose them through controlled interfaces. Agents should not need raw database passwords or SaaS tokens. They should call a bounded tool that enforces the same rules a human operator would expect: source-level permissions, safe execution, audit logging, and budget checks. The goal is not to make access invisible. It is to make access legible. A team should be able to answer: who can use this source, what can they do with it, how expensive can a run become, and where do we look when something unexpected happens? ## Make the next source easier A good connector platform compounds. Every new source should make the next source easier by reusing the same concepts: configuration shape, validation states, permission checks, audit entries, query limits, and troubleshooting output. That is the difference between a connector collection and an operating surface. This is especially important for agent-assisted data work. Agents need broad context, but they also need narrow capabilities. A predictable source setup path gives the agent a stable catalog of tools and gives the team a stable place to review what happened. The practical measure of success is simple: adding a source should stop feeling like a small implementation project. It should feel like filling in a known form, running known validation, assigning known access, and giving the team one more reliable place to ask questions from. --- ## Source: https://onequery.dev/blog/onequery-loves-vercel/ --- category: Product title: OneQuery loves Vercel description: Connect Vercel to OneQuery so agents can inspect teams, projects, and deployments without carrying raw Vercel tokens. coverImage: src: ../../assets/blog/onequery-loves-vercel-icon.png alt: OneQuery logo connected to the Vercel logo with a heart symbol. publishedAt: 2026-06-23 readTime: 4 min read --- ## Vercel is now a useful source for agents Vercel is often where the operational truth of a web product shows up first. A project was redeployed, a production alias moved, a cron job changed, a preview branch became active, or a build started failing after a specific commit. Those facts are useful to agents, but the raw Vercel token should not live in an agent prompt, notebook, or local script. OneQuery lets a team connect Vercel once, name it as a source such as `vercel://Vercel`, and expose bounded Source API reads through the same control plane used for databases, analytics tools, repositories, and observability systems. That makes Vercel less like a dashboard someone has to open by hand and more like a readable part of the agent's evidence graph. ## What OneQuery can read from Vercel The Vercel Source API connection can call Vercel REST endpoints using the connected token. The most immediately useful reads are: | Endpoint | What it helps answer | | ----------------- | ------------------------------------------------------------------------------------- | | `/v2/teams` | Which Vercel teams the connected token can see, including the team ID needed later. | | `/v9/projects` | Which projects exist, how they are configured, and which deployments are current. | | `/v6/deployments` | Which deployments were created recently, what commit produced them, and their status. | That is enough for many operational questions. An approved agent can check whether the Vercel source is active, inspect the projects visible to the token, and connect deployment metadata back to GitHub commits, branches, aliases, environments, and project settings. The important part is the access path. The agent asks OneQuery. OneQuery uses the stored credential server-side, applies the source boundary, and leaves an auditable path for the team to review later. ## Example: a deployment change investigator Imagine a support channel reports that a production workflow started failing after lunch. There are several possible causes: a code change, a changed environment variable, a scheduled job, a preview deployment promoted by mistake, or an unrelated upstream outage. With Vercel connected to OneQuery, the agent can start with read-only evidence: 1. List the Vercel team and confirm the team ID the token reaches. 2. List projects and find the production project by name. 3. Inspect the latest production deployment for that project. 4. Read the deployment metadata: commit SHA, branch, creator, ready state, alias assignment, region, framework, build command, cron definitions, and environment targets. 5. Compare that deployment timestamp to the user-reported failure window. The result is not a magical diagnosis. It is a sharper first answer: "The production alias moved to deployment `dpl_...` at 13:12, from commit `abc123` on `main`. The deployment reached `READY`, but the project cron definitions changed in the same deployment. Check the scheduled route first." That is the kind of answer an agent can produce quickly when Vercel is a connected source instead of a separate dashboard tab. ## Keep deployment visibility separate from deployment control Vercel can do much more than list teams, projects, and deployments. It can manage domains, deployments, environment variables, and project settings. Those are powerful control-plane actions, and they should not become casual agent capabilities. The most useful default is read-first: let the agent inspect deployment evidence, summarize what changed, and point to the next human or product workflow action. If a team later wants controlled mutation workflows, those should be explicit, permissioned, and reviewed separately. This is the same boundary OneQuery uses across other Source API providers. The useful thing is not "the model has a token." The useful thing is "the model can ask a narrow, auditable question through a source the team already approved." ## Why this is interesting Vercel data is unusually good context for agentic debugging because it sits between code and production behavior. A database can show what users did. An analytics tool can show where a metric moved. A repository can show what code changed. Vercel can show when that code became a running deployment. That bridge makes a lot of workflows better: - Customer support can ask which deployment introduced a visible behavior change. - Engineering can ask whether the failing environment is production or preview. - Growth can ask which landing page deployment was live during a campaign window. - Finance and operations can inspect team-level plan and usage metadata without opening a vendor dashboard. - Agents can correlate Vercel deployment IDs with GitHub commits, logs, incidents, and product metrics. OneQuery does not replace Vercel. It makes Vercel easier for agents to read safely. Connect Vercel once, keep the token out of agent runtimes, and let the agent use deployment evidence when it needs to explain what changed. --- ## Source: https://onequery.dev/blog/safe-internal-data-analysis-with-hermes-agent-and-onequery/ --- category: Usecase title: Safe internal data analysis with Hermes Agent and OneQuery description: How to let Hermes Agent answer internal data questions from Slack, Discord, or Telegram without exposing raw credentials, write access, or unbounded query cost. coverImage: src: ../../assets/blog/safe-internal-data-analysis-with-hermes-agent-and-onequery-icon.png alt: Safe internal data analysis with Hermes Agent and OneQuery - OneQuery blog cover image. publishedAt: 2026-07-09 readTime: 6 min read --- ## Internal data agents need a boundary [Hermes Agent](https://hermes-agent.nousresearch.com/) is compelling because it can live where people already ask for help: Slack, Discord, Telegram, CLI, and other personal or team surfaces. That makes it a natural place to ask internal data questions. It also changes the risk model. When an agent can answer questions from a messaging channel, the data path is no longer just a developer at a terminal. It is a model, a chat interface, a skill system, source credentials, query execution, and whatever team permissions sit around that channel. [Jaeyoun Nam's DEV walkthrough](https://dev.to/siisee11/analysis-internal-data-safely-with-hermes-agent-and-onequery-18fg) shows the useful version of this pattern: connect OneQuery, install the OneQuery skill in Hermes, then ask Hermes to analyze internal data from Slack. The important product lesson is not only that the workflow works. The important lesson is that a personal agent needs a real data boundary before it becomes a shared company tool. ## What can go wrong with direct access A direct database tool feels simple at first. Give Hermes a connection string, add a prompt that says "only run safe queries," and let the model do the rest. That shortcut creates several failure modes: | Risk | What happens without a boundary | | ---------------- | --------------------------------------------------------------------------------------------------------------- | | Secrets exposure | Raw database passwords, SaaS tokens, or API keys can leak into prompts, logs, screenshots, or chat transcripts. | | Write access | A model can generate an update, delete, migration, or API mutation if the credential allows it. | | Query cost | Warehouse and analytics queries can scan too much data or retry in loops. | | Production load | A broad query can hurt a production database even when it is read-only. | | Shared channels | A teammate, compromised account, or copied prompt can ask the agent for data they should not see. | | No audit trail | The team cannot easily answer who asked, which source ran, what SQL executed, and what data returned. | Prompt rules are still useful. They help the agent behave well in normal cases. They are not a security boundary because they do not change what the credential can do. ## Where OneQuery fits OneQuery gives Hermes a narrower way to reach company data. Hermes does not need raw provider credentials in its runtime. It calls a OneQuery skill or CLI command against a named source, and OneQuery resolves the source configuration, applies the configured controls, executes the bounded operation, and returns a result the agent can explain. That split matters: | Hermes Agent should handle | OneQuery should handle | | --------------------------------- | ----------------------------------- | | Understanding the user's question | Source configuration | | Choosing an analytical path | Credential ownership | | Drafting SQL or API requests | Read-only execution boundaries | | Explaining results and caveats | Role and source permissions | | Asking follow-up questions | Timeouts, limits, and audit records | The model stays useful because it can reason over the question and the result. The dangerous authority moves into a deterministic data layer that can be configured, reviewed, and operated by the team. ![Diagram showing Slack, Discord, and Telegram sending questions to Hermes Agent, Hermes routing data requests through OneQuery guardrails, and bounded answers returning with caveats.](../../assets/blog/safe-internal-data-analysis-with-hermes-agent-and-onequery-architecture.png) ## A practical setup Install OneQuery and authenticate the CLI: ```sh curl -fsSL https://onequery.dev/install.sh | sh onequery auth login onequery source list ``` Install Hermes Agent from the current Hermes installer: ```sh curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash hermes setup ``` Then install the standalone OneQuery skill for Hermes: ```sh hermes skills install skills-sh/wordbricks/skills/onequery-cli --yes --force ``` Start Hermes with the skill preloaded: ```sh hermes chat --skills onequery-cli ``` For a channel-based workflow, connect Hermes to the team surface you want to use, such as Slack or Discord. In OneQuery, connect the sources Hermes is allowed to use, such as a read-only Postgres replica, Supabase project, warehouse, Amplitude workspace, or product analytics source. The key is to expose named sources, not provider credentials. A Hermes instruction should look like this: ```text Use OneQuery for internal data analysis. Do not ask for raw database credentials, SaaS tokens, or cloud keys. Allowed sources: - postgres://warehouse_prod - amplitude://product_main Use aggregate queries first, explicit time windows, and small limits. Return the source, query shape, assumptions, and caveats with the answer. ``` ## The safe request loop A healthy Hermes plus OneQuery loop is small and inspectable: 1. A user asks a question in Slack, Discord, Telegram, or the Hermes CLI. 2. Hermes identifies the likely source and drafts a bounded query or API request. 3. OneQuery checks the named source, credential, permission, and execution boundary. 4. The source returns a small, task-specific result. 5. Hermes summarizes the result with assumptions, caveats, and the source path. 6. Operators can review the request later through the OneQuery audit trail. This loop makes denials normal. If a user asks for a source they cannot use, Hermes should say that the source is not available. If a query is too broad, Hermes should narrow the time window or ask for approval. If the question needs raw exports, Hermes should explain why that is outside the default workflow. ## Guardrails worth making explicit The most important guardrail is read-only access. For SQL sources, use credentials that cannot mutate data. For provider APIs, expose endpoints and scopes that match the analytical job. Do not depend on the model to remember which operations are dangerous. The second guardrail is source-level permission. A founder may be able to inspect billing and product analytics. A support teammate may need account health data but not payroll, security events, or raw user emails. If Hermes is used in team channels, the OneQuery source list should match the role and the channel. The third guardrail is cost. Agents are good at retries. That is useful when a query has a syntax error, but risky when a warehouse query scans too much data. Use explicit time windows, row limits, aggregate-first queries, and provider-side budgets where available. The fourth guardrail is auditability. A useful answer should not be a mystery. The team should be able to review which source was used, what query or provider operation ran, who requested it, when it happened, and what result shape came back. ## A good first use case Start with one narrow workflow: ```text Report daily active users and seven-day retention for the onboarding flow over the last 30 days. Use amplitude://product_main. Prefer aggregate queries and include caveats about incomplete events or attribution gaps. ``` That question is useful, bounded, and easy to review. It does not require raw event exports. It has a clear time window. It can return a compact table and a short explanation. Once that works, add one source at a time. Product analytics first. Then a read-only warehouse. Then support or billing data if the team has a permission model for it. Resist the urge to connect every internal API on day one. ## What this unlocks Hermes gives teams a fast, conversational surface for asking internal questions. OneQuery gives that surface the data boundary it needs to be useful in production-like environments. Together, they let a team ask real questions without turning every chat message into a raw credential decision. Hermes can plan, query, summarize, and follow up. OneQuery can keep credentials out of the agent runtime, enforce bounded execution, and preserve the record of what happened. That is the difference between a neat demo and an internal data agent a team can actually operate. --- ## Source: https://onequery.dev/blog/using-llm-telemetry-to-improve-prompts-with-gepa/ --- category: Usecase title: Using LLM telemetry to improve prompts with GEPA description: A practical workflow for using OneQuery to let a GEPA reflection agent inspect Laminar LLM telemetry while improving prompts. coverImage: src: ../../assets/blog/using-llm-telemetry-to-improve-prompts-with-gepa-icon.png alt: Using LLM telemetry to improve prompts with GEPA - OneQuery blog cover image. publishedAt: 2026-04-30 readTime: 7 min read --- ## What is GEPA? GEPA, short for Genetic-Pareto, is a text evolution engine for optimizing prompts, code, agent architectures, configurations, policies, and other artifacts that can be represented as text. The core idea is to use LLM-based reflection over execution traces, then keep candidates through a Pareto-efficient search process instead of collapsing everything into one aggregate score. That makes GEPA especially useful when failures come with diagnostic context. A reflection model can inspect why a candidate failed, propose a targeted change, and preserve candidates that solve different subsets of the task. The official GEPA guides are here: https://gepa-ai.github.io/gepa/guides/ In practice, the loop has three roles. The executor runs a candidate on tasks and records full traces. The reflector reads those traces to diagnose failure modes and causal patterns. The curator turns those diagnostic insights into an improved candidate, then sends it back through the loop for the next evaluation round. ![GEPA pipeline diagram showing executor, reflector, and curator stages with a feedback loop to the next candidate.](../../assets/blog/gepa-pipeline-diagram.png) ## Why telemetry matters for GEPA Prompt optimization often starts with a simple loop: run a program on examples, score the outputs, collect failures, and ask an LLM to rewrite the instruction. That works better than manual prompt editing, but it leaves useful evidence on the table. A wrong answer is rarely just a wrong final token. The useful signal is in the trajectory: which prompt was used, what reasoning the model wrote, whether the first solve call was already wrong, whether the review call caught the mistake, which examples were similar, and whether failures came from arithmetic, counting, formatting, or an unsupported shortcut. LLM telemetry systems such as Laminar (https://laminar.sh/) capture that evidence. The question is how to let an optimization agent use it without handing the agent raw credentials, direct database access, or an unbounded query surface. That is where OneQuery fits. ## The experiment shape ![Diagram showing an AIME run split into solve and review prompts, Laminar trace spans, OneQuery trace lookup, and GEPA reflection.](../../assets/blog/gepa-aime-experiment-shape.png) The original GEPA AIME experiment solved each problem with a single LLM step. This experiment intentionally split the same AIME-style task into two LLM calls to show a different point: when a workflow has multiple LLM steps, connecting LLM telemetry to the reflection loop is enough to make the GEPA methodology easy to apply. The first call solved the problem and produced an initial answer. The second call reviewed the initial answer and produced the final answer. Both calls ran under the same Laminar trace so a single problem trajectory could be inspected as a parent span plus solve and review child spans. The GEPA loop optimized two DSPy predictors: solve.predict and review.predict. That means both the solver prompt and the review prompt were improved through LLM telemetry-backed reflection, rather than treating the workflow as one opaque prompt. For each candidate prompt, GEPA evaluated examples, built a reflective dataset from successes and failures, and asked a reflection agent to propose an improved instruction. The important difference from a plain GEPA run was that the reflection agent had a OneQuery tool. Before proposing an instruction, it queried Laminar spans through OneQuery using the problem hash from the feedback. That let it inspect the exact solve and review telemetry for the examples GEPA was reflecting on. ## What the agent saw ![Laminar trace view showing AIME GEPA spans, timeline, transcript, input, model output, and problem solver span details.](../../assets/blog/laminar-aime-gepa-trace-screenshot.png) The Laminar spans made the failure mode visible. For a given problem, the agent could see whether the solve stage produced a plausible but unsupported answer, whether the review stage merely rubber-stamped it, or whether the review correctly identified an inconsistency. That distinction matters because the remedy is different. If solve is hallucinating a counting formula, the solve instruction needs stronger casework and verification. If solve is mostly right but review fails to catch arithmetic mistakes, the review instruction needs to behave more like an independent verifier. In one run, the reflection agent used OneQuery to inspect spans for a failed or partially successful trajectory, then proposed a review instruction that explicitly told the model not to restate the answer, to verify invariants and arithmetic, and to replace unsupported answers with a corrected conclusion. ## A sample setup | Setting | Value | | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | | Task | AIME-style math problems with solve and review LLM calls | | Dataset split | 24 train examples, 12 validation examples, 15 test examples | | Optimization budget | max-metric-calls set to 72 | | Telemetry | DSPy cache disabled so Laminar received fresh solve and review traces | | OneQuery access | Reflection agent enabled for the onequery-demo org and laminar-aime-gepa source | | Artifacts | Experiment repo, result JSON, markdown report, progress plot, and reflection transcripts: https://github.com/wordbricks/onequery-gepa | ## Results The experiment repo is available at https://github.com/wordbricks/onequery-gepa. Its report shows a small but clear validation improvement. The base program solved 3 out of 12 validation examples. After OneQuery-backed telemetry reflection, the first accepted candidate reached 4 out of 12, and a later candidate reached 5 out of 12. ![Diagram showing the actual initial and accepted GEPA prompt text for solve.predict and review.predict.](../../assets/blog/gepa-actual-prompt-changes.png) The prompt changes were not generic rewrites. The base solve prompt simply asked the model to derive an initial answer, while the accepted reflected solve prompt pushed it to reduce problems into clean cases, verify invariants, and avoid unsupported symmetry assumptions. Review prompt candidates were generated during reflection, but the saved accepted candidate kept the review prompt unchanged. The final test result was 5 out of 15, or 33.33 percent. That is still modest, but it is the useful signal for this use case: telemetry did not make AIME easy, but it gave GEPA better evidence for diagnosing failures and producing targeted prompt candidates. | Checkpoint | Result | | ------------------------ | ----------------------- | | Base validation | 3/12 correct, 25% | | First accepted candidate | 4/12 correct, 33% | | Later accepted candidate | 5/12 correct, about 42% | | Final test report | 5/15 correct, 33.33% | ![Graph showing best validation score rising from 25.00 to 33.33 to 41.67 percent across metric calls, with selected test score at 33.33 percent.](../../assets/blog/gepa-result-summary.png) ## Lessons learned Optimization needs auditability. The reflection transcripts showed the exact SQL the agent requested, whether OneQuery returned rows, which prompt candidate was proposed, and whether the candidate improved subsample and validation scores. ## What comes next There are better examples where telemetry and the GEPA methodology should have even more room to improve prompts. Browser automation is one of them. A single task can involve many LLM decisions, repeated tool calls, page observations, retries, and partial failures, so pass/fail labels alone are a thin signal. For those workflows, LLM telemetry is what makes self-reflection practical. The agent needs to inspect which page state it saw, which tool call it chose, what failed, and how the later steps recovered or compounded the mistake. Once those traces are available, GEPA can optimize prompts against the actual trajectory instead of only the final outcome. We wanted to run those experiments too, but did not have enough time and budget for this pass. When Codex App Server supports LLM telemetry, we plan to revisit the experiment with richer multi-step agent workflows. ## Why this is a good OneQuery use case This is a natural OneQuery use case because the agent needs real operational data, but it should not hold direct access to the telemetry system. OneQuery turns telemetry lookup into a controlled tool call with org-scoped access, bounded reads, and a record of what was queried. That pattern generalizes beyond Laminar and GEPA. Any prompt optimization, eval debugging, support triage, or agent repair loop can benefit from inspecting traces, product events, support tickets, warehouse rows, or observability data. The model should reason over the evidence, while OneQuery controls access to the evidence. The practical architecture is simple: instrument the LLM app, expose the telemetry source through OneQuery, give the optimizer a narrow query tool, and make every reflection step save its transcript. The result is a prompt improvement workflow that is more grounded, more auditable, and safer than giving an agent direct access to the telemetry backend. --- ## Source: https://onequery.dev/compare/onequery-vs-bi-chatbot/ --- order: 4 title: OneQuery vs BI Chatbot | Operational Agent Access metaDescription: Compare OneQuery with BI chatbots for AI agent data access. Use dashboards for business answers and governed sources for operational agents. alternativeName: BI chatbot category: Analytics versus operations eyebrow: OneQuery vs BI chatbot summary: BI chatbots make analytics more accessible. OneQuery makes production source access safer for agents that do operational work. answer: Use OneQuery instead of a BI chatbot when the agent needs operational production context, not just dashboard-backed analytics answers. BI chatbots are best for business metrics; OneQuery is built for governed source access by coding, incident, and internal automation agents. heroSignals: - BI for metrics - OneQuery for source context - Separate analytics from agent access keywords: - OneQuery vs BI chatbot - AI agent data access vs BI chatbot - operational data access for agents - business intelligence chatbot - production context for coding agents criteria: - factor: Primary context oneQuery: Agents can query approved databases and provider APIs for task-specific production context. alternative: Answers usually come from dashboards, saved questions, models, or a BI semantic layer. - factor: Primary user oneQuery: Designed for agent workflows running through CLI, gateway, and source commands. alternative: Designed for humans asking business questions in a BI workspace or embedded analytics surface. - factor: Governance model oneQuery: Governance is tied to source credentials, query validation, limits, and audit history. alternative: Governance is tied to BI permissions, curated datasets, and metric definitions. - factor: Best answer shape oneQuery: Best for retrieving narrow operational evidence that an agent can use to debug, triage, or automate. alternative: Great for explaining trends, charts, cohorts, and reports. - factor: Operational fit oneQuery: Can connect production databases, warehouses, observability tools, product analytics, and developer systems. alternative: May not expose the low-level source, incident, or developer-tool context an engineering agent needs. oneQueryBestFor: - Coding agents investigating errors, logs, database state, or customer-impacting incidents. - Internal automations that need source-specific evidence, not only chart summaries. - Teams that need source execution audit history outside a BI workspace. alternativeBestFor: - Business users asking metric, dashboard, and report questions. - A governed semantic layer where terms like revenue, churn, and active user already have company-approved definitions. - Recurring executive or go-to-market workflows that belong in dashboards and scheduled reports. migrationSteps: - Keep dashboard and metric questions routed to the BI chatbot. - Identify operational agent workflows that need raw source context or developer-tool data. - Connect those sources to OneQuery with read-only or least-privilege credentials. - Document when agents should use BI answers versus OneQuery source execution. faqs: - question: Does OneQuery replace a BI chatbot? answer: Usually no. A BI chatbot and OneQuery solve different layers. Use the BI chatbot for business analytics questions and OneQuery for governed source access in engineering and automation workflows. - question: How do I choose between the two? answer: Choose a BI chatbot when the answer should come from approved metrics, dashboards, reports, or a semantic model. Choose OneQuery when an agent needs bounded access to production sources during an operational task. - question: Can BI and OneQuery coexist? answer: Yes. Teams can keep BI as the business analytics interface and use OneQuery as the access layer for coding agents, incident agents, and internal tools that need broader source context. references: - label: OneQuery connectors href: /connectors/ description: OneQuery docs on supported databases, warehouses, analytics systems, and developer tools. - label: Query boundaries href: /docs/concepts/query-boundaries/ description: OneQuery docs on what source requests are allowed to do. readTime: 1 min read --- ## Analytics answers and operational context are different jobs BI chatbots are strongest when the company has already curated the data shape: metrics, dashboards, models, reports, and common business definitions. That is the right interface for many business questions. Operational agents often need a different kind of evidence. They may need a narrow production query, a recent error from an observability tool, a linked issue, or a support-system record. OneQuery gives those workflows a source boundary without turning the BI layer into the agent runtime. ## Recommended rollout Write down which questions should stay in BI. Route the remaining operational workflows through OneQuery sources, starting with incident or debugging tasks where audit history and small result windows matter. --- ## Source: https://onequery.dev/compare/onequery-vs-datagrip-for-ai-agents/ --- order: 6 title: OneQuery vs DataGrip for AI Agents | Safe Database Access metaDescription: Compare OneQuery with DataGrip for AI agents. Keep DataGrip for human SQL work and OneQuery for bounded agent source access. alternativeName: DataGrip for AI agents category: IDE versus agent access layer eyebrow: OneQuery vs DataGrip for agents summary: DataGrip is excellent for trusted humans writing SQL. OneQuery is the safer path when the caller is an agent that should not hold database connection details. answer: Use OneQuery instead of DataGrip for AI agents when the user is an autonomous agent rather than a human SQL operator. DataGrip is a database IDE for people; OneQuery is a governed source access layer that lets agents query approved data without receiving database connection details. heroSignals: - DataGrip for humans - OneQuery for agents - No IDE credentials in runtime keywords: - OneQuery vs DataGrip for AI agents - DataGrip AI agent alternative - AI agent SQL access - database IDE versus agent access layer - safe agent database queries criteria: - factor: Primary user oneQuery: OneQuery is built around agent and CLI workflows that need controlled source access. alternative: "DataGrip is built around human database work: data sources, query consoles, SQL files, schema browsing, and editor assistance." - factor: Connection details oneQuery: The agent receives a source identifier while OneQuery stores and uses the source credential server-side. alternative: The IDE needs connection details such as host, port, password, and related settings for each data source. - factor: Execution judgment oneQuery: OneQuery applies deterministic boundaries before agent-generated SQL reaches the source. alternative: A human chooses which SQL to run and can inspect the database state through the IDE. - factor: Audit model oneQuery: Source requests are recorded as agent access events with actor, source, operation, outcome, and time. alternative: IDE history and database logs may help, but they are not an agent access control plane. - factor: Best fit oneQuery: Best for giving coding agents narrow, repeatable, auditable access to production context. alternative: Excellent for interactive development, schema exploration, and SQL authoring by trusted users. oneQueryBestFor: - AI coding agents that need database evidence during production debugging. - Teams that want humans to keep powerful IDEs while agents get narrower source interfaces. - Workflows where query validation and audit history matter more than IDE ergonomics. alternativeBestFor: - Human developers writing, debugging, and organizing SQL in a full database IDE. - Schema browsing, query consoles, data editor workflows, and database object inspection. - A trusted operator session where the person using the tool should hold the database connection details. migrationSteps: - Keep human SQL authoring and schema exploration in DataGrip. - Create a scoped OneQuery source for the production data the agent can inspect. - Remove DataGrip connection details, passwords, and DSNs from the agent environment. - Use OneQuery audit history to review the agent's production source activity. faqs: - question: Does OneQuery replace DataGrip? answer: No. Keep DataGrip for human database work. Use OneQuery for agent workflows where the database credential should stay outside the agent runtime. - question: Why not give an agent a DataGrip connection? answer: Giving an agent an IDE connection profile recreates the direct-credential problem. OneQuery lets the agent request data through a bounded interface without owning the connection details. - question: How can developers use DataGrip and OneQuery together? answer: A developer can use DataGrip to design or verify a query, then give the agent a OneQuery source and a narrow command pattern for repeatable production-safe runs. references: - label: DataGrip data sources href: https://www.jetbrains.com/help/datagrip/managing-data-sources.html description: JetBrains documentation on DataGrip data sources and supported databases. - label: DataGrip database connections href: https://www.jetbrains.com/help/datagrip/connecting-to-a-database.html description: JetBrains documentation on DataGrip database connection details and sessions. - label: DataGrip code editor href: https://www.jetbrains.com/help/datagrip/code-editor.html description: JetBrains documentation on DataGrip SQL query editing and consoles. readTime: 1 min read --- ## Keep the IDE for humans DataGrip is a strong human database IDE. It helps trusted operators manage data sources, write SQL, inspect schemas, and work interactively with query consoles. That is a different job from giving an autonomous agent production context. An agent does not need the full IDE connection profile. It needs a narrow way to ask a source-specific question and receive a bounded answer. ## Recommended rollout Keep DataGrip in the human workflow for query design and review. Give the agent a OneQuery source identifier and remove IDE connection details from the agent runtime. --- ## Source: https://onequery.dev/compare/onequery-vs-direct-database-credentials/ --- order: 1 title: OneQuery vs Direct Database Credentials | Safe AI Agent Access metaDescription: Compare OneQuery with direct database credentials for AI agents. See when governed source access beats handing agents raw passwords or DSNs. alternativeName: direct database credentials category: Credential strategy eyebrow: OneQuery vs raw database access summary: Direct database credentials can be fast for a human, but they make the agent runtime the security boundary. OneQuery moves that boundary into a governed execution layer. answer: Use OneQuery instead of direct database credentials when an AI agent needs production context. Direct credentials put the password, DSN, or cloud token inside the agent runtime; OneQuery keeps the credential server-side and gives the agent a bounded source interface. heroSignals: - Credential stays centralized - Read-only query boundary - Auditable agent access keywords: - OneQuery vs direct database credentials - AI agent database credentials - safe production database access for agents - centralized credentials - read-only query validation criteria: - factor: Credential exposure oneQuery: Credentials stay in OneQuery source configuration and the agent receives only a source identifier and command surface. alternative: The agent receives a password, DSN, IAM credential, or environment variable that can reach the database. - factor: Query boundary oneQuery: SQL requests pass through read-only validation, single-statement enforcement, limits, and source-specific execution controls. alternative: Read-only behavior depends on the database role and on the agent choosing safe SQL. - factor: Audit trail oneQuery: Each request records actor, source, operation, outcome, and time in a purpose-built access history. alternative: Teams often reconstruct agent activity from shell history, database logs, or model transcripts. - factor: Rotation oneQuery: Rotate the source credential centrally while keeping the agent workflow pointed at the same approved source. alternative: Credential rotation requires updating every place where the agent or tool runtime received the secret. - factor: Failure mode oneQuery: Denied writes, oversized responses, missing permissions, and broad queries become explicit blocked states. alternative: A prompt rule can tell the agent to be careful, but it cannot reduce the authority attached to the credential. oneQueryBestFor: - Production debugging where agents need real database context but should not hold secrets. - Teams that need an audit trail for agent data access. - Workflows where prompt rules are not enough to enforce read-only behavior. alternativeBestFor: - A local development database that contains no production data. - A one-off human DBA session where the operator already owns the credential. - A throwaway read-only role that can be revoked immediately after testing. migrationSteps: - Create a read-only upstream database role for the data the agent is allowed to inspect. - Connect that role as a named OneQuery source. - Replace the agent's DSN or password with the OneQuery source identifier and command pattern. - Run a small production debugging workflow and review the resulting audit history. faqs: - question: When are direct database credentials acceptable for an AI agent? answer: Use a direct credential only for low-risk human workflows or isolated test data. For production data, the safer pattern is to give the agent a controlled source interface while the credential stays outside the model runtime. - question: Does OneQuery replace database-level permissions? answer: OneQuery is not a replacement for scoped database roles. It works best with read-only upstream roles, then adds source resolution, validation, limits, and audit records around the agent workflow. - question: How do I move from direct credentials to OneQuery? answer: Point the agent at a OneQuery source identifier, remove the database secret from the agent environment, and review the first runs in audit history before adding more sources. references: - label: Governed access href: /docs/concepts/governed-access/ description: OneQuery docs on keeping raw provider credentials outside the agent runtime. - label: Query boundaries href: /docs/concepts/query-boundaries/ description: OneQuery docs on read-only validation, single-statement execution, limits, and blocked requests. readTime: 1 min read --- ## The practical difference A direct credential turns the agent environment into the control plane. If the credential can reach production, the agent can try to use that authority whenever its plan points there. OneQuery keeps the useful part of the workflow: the agent can still ask focused database questions. The difference is that the source, credential, validation, limits, and audit record stay outside the prompt and outside the shell environment. ## Recommended rollout Start with the smallest read-only source that answers a real debugging question. Remove the raw DSN from the agent setup, give the agent the OneQuery source identifier, and treat denied or truncated requests as normal feedback instead of reasons to broaden the credential. --- ## Source: https://onequery.dev/compare/onequery-vs-internal-data-agent/ --- order: 3 title: OneQuery vs Internal Data Agent | Build vs Govern metaDescription: Compare OneQuery with building an internal data agent. Keep custom agent logic while outsourcing source credentials, limits, and audit trails. alternativeName: internal data agent category: Build versus govern eyebrow: OneQuery vs building the whole agent stack summary: An internal agent can be the right product choice. OneQuery makes sure that agent does not also become the credential store and production query gate. answer: Use OneQuery with an internal data agent when you want to build custom agent behavior without rebuilding the production access layer. The internal agent can own planning and UX while OneQuery owns source credentials, query boundaries, limits, and audit logs. heroSignals: - Keep custom agent logic - Outsource access controls - Ship sources faster keywords: - OneQuery vs internal data agent - build internal data agent - AI data agent infrastructure - agent access control plane - governed production data access criteria: - factor: Infrastructure scope oneQuery: OneQuery provides the source access layer so the internal agent can focus on task logic and user experience. alternative: The internal team must design and maintain credential storage, source mapping, query safety, limits, and audit behavior. - factor: Secret handling oneQuery: Credentials stay centralized behind named sources and do not need to appear in agent prompts or runtime env vars. alternative: Credentials often spread across service configs, worker environments, and prototype scripts. - factor: New source rollout oneQuery: Teams add approved sources through a consistent connection, command, and audit model. alternative: Each source needs custom policy and logging code before it is safe for production use. - factor: Operational review oneQuery: Access history is part of the governed data layer from the start. alternative: Audit review is usually a bespoke feature that competes with agent product work. - factor: Responsibility split oneQuery: The agent asks and interprets; OneQuery resolves sources, validates requests, executes, and records outcomes. alternative: The internal agent becomes responsible for both reasoning and security-sensitive execution. oneQueryBestFor: - Teams that want custom agent UX without owning every production access control. - Engineering agents that need real operational context from several sources. - Organizations that need source-by-source rollout, review, and audit behavior. alternativeBestFor: - A differentiated product experience where the agent workflow itself is the core product. - Custom reasoning, planning, or UI behavior that cannot be bought as infrastructure. - A narrow internal prototype that uses one data source and a small trusted user group. migrationSteps: - Identify where the internal agent currently stores or receives source credentials. - Move one production source into OneQuery with a read-only upstream credential. - Change the agent tool call to use a OneQuery source identifier instead of direct source metadata. - Keep custom planning and response logic in the agent while reviewing source execution in OneQuery. faqs: - question: Does OneQuery replace our internal data agent? answer: No. OneQuery is the data access boundary, not the reasoning layer. Internal teams can still build custom agents, prompts, UIs, and workflows while delegating governed source access to OneQuery. - question: What should we build ourselves? answer: Build the agent behavior that is specific to your company. Use OneQuery for the repeated infrastructure work around credentials, source identifiers, safe execution, result limits, and audit history. - question: How should an internal agent adopt OneQuery? answer: Connect one low-risk read-only source first, give the internal agent only the source identifier and command surface, and review audit history after the first automated runs. references: - label: Governed access href: /docs/concepts/governed-access/ description: OneQuery docs on the split between what stays outside the agent and what the agent receives. - label: Security architecture href: /docs/security/security-architecture/ description: OneQuery docs on credential boundaries and reviewable request flow. readTime: 1 min read --- ## Build the agent, not the whole access layer Internal data agents are often worth building when the workflow is specific to the company. The risky part is letting that project quietly expand into credential management, query validation, source authorization, rate limits, and audit review. OneQuery gives the internal agent a smaller contract. The agent decides what to ask and how to explain the result. OneQuery decides which source can be used, how the request executes, and what record operators can review later. ## Recommended rollout Keep the custom agent UI and planning loop. Replace direct source calls one at a time with OneQuery-backed source commands, starting with a read-only source that supports a real operational workflow. --- ## Source: https://onequery.dev/compare/onequery-vs-mcp-database-server/ --- order: 2 title: OneQuery vs MCP Database Server | Governed Agent Data Access metaDescription: Compare OneQuery with a database MCP server for AI agent data access, credential isolation, query boundaries, and audit history. alternativeName: MCP database server category: Protocol adapter eyebrow: OneQuery vs MCP database server summary: MCP helps an AI application discover and call tools. OneQuery handles the production data boundary those tools still need. answer: Use OneQuery instead of a generic MCP database server when the main problem is governed production access, not only tool exposure. MCP standardizes how AI applications call tools and resources; OneQuery focuses on credential isolation, query boundaries, source limits, and audit history for those data operations. heroSignals: - Protocol-compatible workflows - Governed execution layer - Central source audit history keywords: - OneQuery vs MCP database server - MCP database server alternative - AI agent database MCP - governed MCP data access - agent query audit logs criteria: - factor: Primary job oneQuery: OneQuery is the execution boundary for source credentials, read-only SQL, result limits, and audit records. alternative: The MCP server defines the tool surface, and governance depends on the server implementation. - factor: Credential placement oneQuery: Source credentials are centralized in OneQuery configuration and can be hidden from the AI client. alternative: Credentials usually live wherever the database MCP server is deployed or configured. - factor: Policy depth oneQuery: OneQuery applies deterministic query validation and source controls before the request reaches the database. alternative: The protocol can expose tools and resources, but database safety is not automatic. - factor: Review path oneQuery: Operators review source activity through a product-level audit history tied to approved sources. alternative: Tool logs may exist in the AI client, MCP host, or custom server logs. - factor: Scaling sources oneQuery: Multiple databases and APIs use a consistent source identifier model and governed access path. alternative: Each database server may need its own credential, logging, and policy behavior. oneQueryBestFor: - Production database access where MCP tool exposure needs a stronger execution boundary. - Teams standardizing agent access across databases, warehouses, and provider APIs. - Operators who need query-level audit history outside the AI client transcript. alternativeBestFor: - A prototype where the database is local, read-only, and not production-sensitive. - A team that already has a hardened MCP database server with strong policy, logging, and credential handling. - An AI application that only needs a protocol adapter and not a broader access control plane. migrationSteps: - List the database tools your MCP server currently exposes. - Move the underlying database credential into a OneQuery source. - Route agent SQL execution through OneQuery and keep MCP as the optional client adapter. - Compare MCP tool logs with OneQuery audit history during the first production runs. faqs: - question: Does OneQuery replace MCP? answer: No. MCP is a useful protocol for connecting AI applications to tools. OneQuery can complement MCP by acting as the governed data execution layer behind the tool surface. - question: When is an MCP database server enough? answer: A database MCP server is enough when the data is low-risk and the server already enforces the policy you need. Use OneQuery when production credentials, query validation, source limits, and audit review are first-class requirements. - question: How do teams use OneQuery with MCP clients? answer: Expose a OneQuery command or service through the MCP host, or keep OneQuery as the CLI/gateway path for agents that do not need MCP. The important part is that the database credential does not move into the AI client. references: - label: Model Context Protocol server concepts href: https://modelcontextprotocol.io/docs/learn/server-concepts description: The MCP docs describe servers as programs that expose capabilities, including database servers for data queries. - label: OneQuery query boundaries href: /docs/concepts/query-boundaries/ description: OneQuery docs on the deterministic boundary around SQL and source API requests. readTime: 1 min read --- ## MCP is an interface, not the whole boundary MCP gives AI applications a standard way to discover and invoke tools. That is useful, but it does not decide where production credentials live, which SQL shapes are allowed, how broad results may be, or how operators review source activity. OneQuery fits below or beside an MCP host. The MCP layer can remain the client adapter while OneQuery handles the part that has to be deterministic: source resolution, credential use, validation, limits, and audit records. ## Recommended rollout Keep the MCP tool surface narrow. Move the database credential behind OneQuery first, then expose only the OneQuery-backed operation to the MCP host. That gives the agent a familiar tool while moving the production risk out of the client. --- ## Source: https://onequery.dev/compare/onequery-vs-metabase-for-ai-agents/ --- order: 5 title: OneQuery vs Metabase for AI Agents | Governed Data Access metaDescription: Compare OneQuery with Metabase for AI agents. See when to use BI-curated analytics versus governed production source access. alternativeName: Metabase for AI agents category: BI platform comparison eyebrow: OneQuery vs Metabase for agents summary: Metabase is the right home for BI-curated analytics. OneQuery is the access boundary for agents that need operational source context outside the BI workspace. answer: Use OneQuery instead of Metabase for AI agents when the agent needs governed production source access across databases, APIs, and developer tools. Use Metabase when the agent should stay inside BI-curated dashboards, questions, models, and Metabot or Metabase MCP workflows. heroSignals: - Metabase for BI context - OneQuery for source execution - Clear agent access boundary keywords: - OneQuery vs Metabase for AI agents - Metabase AI agent alternative - Metabase MCP server alternative - BI chatbot vs agent data access - governed production data access criteria: - factor: Product center oneQuery: OneQuery centers governed source access for agents, CLI workflows, and self-hosted gateways. alternative: Metabase centers analytics content such as dashboards, questions, models, collections, and the Metabot AI experience. - factor: Data path oneQuery: Best when an agent needs bounded execution against approved production sources and provider APIs. alternative: Best when the answer should come from existing BI assets and user-scoped Metabase permissions. - factor: Agent job oneQuery: Strong fit for production debugging, incident triage, release review, and operational evidence gathering. alternative: Strong fit for analytics exploration, report follow-up, and embedded BI chat. - factor: AI integration oneQuery: OneQuery gives the agent a governed command and source interface independent of a BI workspace. alternative: Metabase MCP connects third-party AI tools to Metabase data, with responses scoped to Metabase permissions. - factor: Control surface oneQuery: Governance follows source credentials, query boundaries, result limits, and audit history for agent execution. alternative: Governance follows Metabase content, permissions, and available AI controls. oneQueryBestFor: - Coding agents that need production context from databases, logs, issue trackers, and APIs. - Teams that do not want BI permissions to become the only control plane for operational agents. - Agent workflows where each source request needs a bounded execution record. alternativeBestFor: - Teams already using Metabase as the source of truth for dashboards, questions, models, and analytics content. - Business users who need a BI-native assistant inside Metabase or an embedded analytics experience. - Agents that should answer from Metabase-curated analytics rather than querying operational systems directly. migrationSteps: - Keep business metric and dashboard questions in Metabase. - Identify agent workflows that need production databases, logs, support tools, or developer APIs outside BI. - Connect those operational sources to OneQuery with scoped credentials. - Teach agents which questions belong in Metabase and which source operations go through OneQuery. faqs: - question: Does OneQuery replace Metabase? answer: No. Metabase is a BI platform, and OneQuery is a governed access layer for agents. Many teams can use Metabase for analytics and OneQuery for operational source access. - question: When should an AI agent use OneQuery instead of Metabase? answer: Use Metabase when the agent should answer from curated BI content. Use OneQuery when the agent needs to inspect approved production sources or developer systems through a bounded execution path. - question: Can OneQuery and Metabase be used together? answer: Yes. Keep Metabase permissions and dashboards for analytics, then use OneQuery for the production sources and operational APIs that should not be exposed as raw credentials to coding agents. references: - label: Metabase AI overview href: https://www.metabase.com/docs/latest/ai/overview description: Metabase documentation for Metabot, embedded AI chat, and the Metabase MCP server. - label: Metabase basic exploration href: https://www.metabase.com/docs/latest/exploration-and-organization/exploration description: Metabase documentation for dashboards, questions, models, collections, databases, and tables. - label: OneQuery governed access href: /docs/concepts/governed-access/ description: OneQuery docs on keeping credentials outside the agent while exposing a controlled source interface. readTime: 1 min read --- ## Keep BI context in BI Metabase is strongest when the agent should work through analytics assets the business already understands: dashboards, saved questions, models, collections, and user-scoped BI permissions. That is a useful boundary for analytics answers. OneQuery fits the workflows that should not be reduced to a dashboard question. A coding or incident agent may need operational source context from databases, observability systems, issue trackers, and provider APIs. Those requests need credential isolation and execution records even when the team already has a BI platform. ## Recommended rollout Keep Metabase as the analytics home. Add OneQuery for operational sources that are useful to agents but should not appear as raw credentials in a coding-agent runtime. --- ## Source: https://onequery.dev/connectors/1password/ [Connectors](/connectors/) / 1Password Developer workflow connector # 1Password connector for governed AI agent access Connect 1Password with a Service Account token for read-only vault, item, and secret reference access. API [Setup docs](/docs/guide/connect-source/)[All connectors](/connectors/) - Source 1Password - Access model API - Setup surface Dashboard and CLI - Provider key `onepassword` Direct answer ## OneQuery supports 1Password for governed agent access. Teams use the 1Password connector to give AI agents bounded source API calls for endpoint-specific context while OneQuery keeps credentials centralized, limits access to approved sources, and preserves audit logs for review. Agent workflow ## What this connector enables 1Password becomes an approved OneQuery source instead of a secret copied into an agent prompt, shell session, or model tool. The agent receives a governed access path, and the source credentials stay behind OneQuery. - Use bounded source API calls for endpoint-specific context for developer workflow context. - Keep 1Password credentials centralized and out of agent runtimes. - Review agent access through OneQuery audit history instead of reconstructing direct service usage. Setup checklist ## Prepare the 1Password connection Use onepassword credentials and connect the source through the Dashboard and CLI. Keep credentials scoped to the data the agent is allowed to read. 1. Create a 1Password Service Account and grant it read-only access to the target vaults. 2. Copy the Service Account token into \`credentials.serviceAccountToken\`. 3. Set \`credentials.authMethod\` to \`service\_account\`. 4. Source API calls are read-only; use operations such as \`list\_vaults\`, \`list\_items\`, \`get\_item\`, and \`resolve\_secret\`. 5. Existing Connect Server credentials remain supported with \`authMethod: "connect"\`, \`apiBaseUrl\`, and \`accessToken\`. FAQ ## 1Password connector questions ### What is the OneQuery 1Password connector? The OneQuery 1Password connector makes developer workflow context from 1Password available to AI agents through bounded source API calls for endpoint-specific context. Connect 1Password with a Service Account token for read-only vault, item, and secret reference access. ### How do AI agents access 1Password through OneQuery? Agents call OneQuery instead of receiving raw 1Password credentials. OneQuery keeps credentials centralized, applies source boundaries, and records access in audit logs while exposing bounded source API calls for endpoint-specific context. ### How do I set up the 1Password connector? Prepare onepassword credentials and connect 1Password from the OneQuery dashboard or CLI. Start with this setup step: Create a 1Password Service Account and grant it read-only access to the target vaults. Related connectors ## More developer workflow sources [**Codex App Server API** Connect the OpenAI-compatible Codex App Server API without exposing its API key to the caller.](/connectors/codex-app-server-api/)[**GitHub** Connect GitHub with a fine-grained personal access token and optional repository or installation scoping.](/connectors/github/)[**Figma** Connect Figma with a personal access token for read-only REST API and grouped design-context access.](/connectors/figma/) --- ## Source: https://onequery.dev/connectors/airtable/ [Connectors](/connectors/) / Airtable Productivity connector # Airtable connector for governed AI agent access Connect Airtable with a Personal Access Token and optional default base ID. API [Setup docs](/docs/guide/connect-source/)[All connectors](/connectors/) - Source Airtable - Access model API - Setup surface Dashboard and CLI - Provider key `airtable` Direct answer ## OneQuery supports Airtable for governed agent access. Teams use the Airtable connector to give AI agents bounded source API calls for endpoint-specific context while OneQuery keeps credentials centralized, limits access to approved sources, and preserves audit logs for review. Agent workflow ## What this connector enables Airtable becomes an approved OneQuery source instead of a secret copied into an agent prompt, shell session, or model tool. The agent receives a governed access path, and the source credentials stay behind OneQuery. - Use bounded source API calls for endpoint-specific context for productivity context. - Keep Airtable credentials centralized and out of agent runtimes. - Review agent access through OneQuery audit history instead of reconstructing direct service usage. Setup checklist ## Prepare the Airtable connection Use airtable credentials and connect the source through the Dashboard and CLI. Keep credentials scoped to the data the agent is allowed to read. 1. Create an Airtable Personal Access Token with scopes and base access for the records or metadata endpoints OneQuery should call. 2. Copy the token into \`credentials.personalAccessToken\`. 3. Optionally include \`baseId\` so source API selectors like \`/TableName\` expand to \`/v0/\/TableName\`. FAQ ## Airtable connector questions ### What is the OneQuery Airtable connector? The OneQuery Airtable connector makes productivity context from Airtable available to AI agents through bounded source API calls for endpoint-specific context. Connect Airtable with a Personal Access Token and optional default base ID. ### How do AI agents access Airtable through OneQuery? Agents call OneQuery instead of receiving raw Airtable credentials. OneQuery keeps credentials centralized, applies source boundaries, and records access in audit logs while exposing bounded source API calls for endpoint-specific context. ### How do I set up the Airtable connector? Prepare airtable credentials and connect Airtable from the OneQuery dashboard or CLI. Start with this setup step: Create an Airtable Personal Access Token with scopes and base access for the records or metadata endpoints OneQuery should call. Related connectors ## More productivity sources [**Slack** Connect Slack so agents can read channel and thread history and send messages where the installed app has access.](/connectors/slack/)[**Cal.com** Connect Cal.com API v2 with an API key or compatible bearer token.](/connectors/cal-com/)[**Granola** Connect Granola with an API key that has access to the note scopes you want to query.](/connectors/granola/) --- ## Source: https://onequery.dev/connectors/amazon-ads/ [Connectors](/connectors/) / Amazon Ads Marketing connector # Amazon Ads connector for governed AI agent access Connect Amazon Ads with a Login with Amazon access token, client ID, region, and optional profile ID. API [Setup docs](/docs/guide/connect-source/)[All connectors](/connectors/) - Source Amazon Ads - Access model API - Setup surface Dashboard and CLI - Provider key `amazon_ads` Direct answer ## OneQuery supports Amazon Ads for governed agent access. Teams use the Amazon Ads connector to give AI agents bounded source API calls for endpoint-specific context while OneQuery keeps credentials centralized, limits access to approved sources, and preserves audit logs for review. Agent workflow ## What this connector enables Amazon Ads becomes an approved OneQuery source instead of a secret copied into an agent prompt, shell session, or model tool. The agent receives a governed access path, and the source credentials stay behind OneQuery. - Use bounded source API calls for endpoint-specific context for marketing context. - Keep Amazon Ads credentials centralized and out of agent runtimes. - Review agent access through OneQuery audit history instead of reconstructing direct service usage. Setup checklist ## Prepare the Amazon Ads connection Use amazon ads credentials and connect the source through the Dashboard and CLI. Keep credentials scoped to the data the agent is allowed to read. 1. Create or refresh a Login with Amazon access token authorized for the Amazon Ads account. 2. Copy the Amazon Ads API client ID into \`credentials.clientId\` and the access token into \`credentials.accessToken\`. 3. Set \`region\` to \`na\`, \`eu\`, or \`fe\`; optionally include \`profileId\` so OneQuery sends the \`Amazon-Advertising-API-Scope\` header. FAQ ## Amazon Ads connector questions ### What is the OneQuery Amazon Ads connector? The OneQuery Amazon Ads connector makes marketing context from Amazon Ads available to AI agents through bounded source API calls for endpoint-specific context. Connect Amazon Ads with a Login with Amazon access token, client ID, region, and optional profile ID. ### How do AI agents access Amazon Ads through OneQuery? Agents call OneQuery instead of receiving raw Amazon Ads credentials. OneQuery keeps credentials centralized, applies source boundaries, and records access in audit logs while exposing bounded source API calls for endpoint-specific context. ### How do I set up the Amazon Ads connector? Prepare amazon ads credentials and connect Amazon Ads from the OneQuery dashboard or CLI. Start with this setup step: Create or refresh a Login with Amazon access token authorized for the Amazon Ads account. Related connectors ## More marketing sources [**Google Search Console** Connect Google Search Console with Google OAuth or an OAuth access token and optional default site URL.](/connectors/google-search-console/)[**LinkedIn Ads** Connect LinkedIn Ads with a Marketing API OAuth access token and version header.](/connectors/linkedin-ads/)[**TikTok Marketing** Connect TikTok Marketing API with an API for Business access token.](/connectors/tiktok-marketing/) --- ## Source: https://onequery.dev/connectors/amplitude/ [Connectors](/connectors/) / Amplitude Product analytics connector # Amplitude connector for governed AI agent access Connect Amplitude with a project API key, secret key, and region. API [Setup docs](/docs/guide/connect-source/)[All connectors](/connectors/) - Source Amplitude - Access model API - Setup surface Dashboard and CLI - Provider key `amplitude` Direct answer ## OneQuery supports Amplitude for governed agent access. Teams use the Amplitude connector to give AI agents bounded source API calls for endpoint-specific context while OneQuery keeps credentials centralized, limits access to approved sources, and preserves audit logs for review. Agent workflow ## What this connector enables Amplitude becomes an approved OneQuery source instead of a secret copied into an agent prompt, shell session, or model tool. The agent receives a governed access path, and the source credentials stay behind OneQuery. - Use bounded source API calls for endpoint-specific context for product analytics context. - Keep Amplitude credentials centralized and out of agent runtimes. - Review agent access through OneQuery audit history instead of reconstructing direct service usage. Setup checklist ## Prepare the Amplitude connection Use amplitude credentials and connect the source through the Dashboard and CLI. Keep credentials scoped to the data the agent is allowed to read. 1. In Amplitude Settings, open \`Projects\`, choose the target project, and go to its \`General\` page. 2. Copy an active API key and the project Secret Key. 3. Set \`region\` to \`eu\` only for Amplitude EU projects; otherwise use \`us\`. FAQ ## Amplitude connector questions ### What is the OneQuery Amplitude connector? The OneQuery Amplitude connector makes product analytics context from Amplitude available to AI agents through bounded source API calls for endpoint-specific context. Connect Amplitude with a project API key, secret key, and region. ### How do AI agents access Amplitude through OneQuery? Agents call OneQuery instead of receiving raw Amplitude credentials. OneQuery keeps credentials centralized, applies source boundaries, and records access in audit logs while exposing bounded source API calls for endpoint-specific context. ### How do I set up the Amplitude connector? Prepare amplitude credentials and connect Amplitude from the OneQuery dashboard or CLI. Start with this setup step: In Amplitude Settings, open \`Projects\`, choose the target project, and go to its \`General\` page. Related connectors ## More product analytics sources [**Google Analytics** Connect Google Analytics with either Google OAuth tokens or a Google Cloud service account JSON key.](/connectors/google-analytics/)[**YouTube Analytics** Connect YouTube Analytics with Google OAuth tokens that can read YouTube Analytics reports.](/connectors/youtube-analytics/)[**Mixpanel** Connect Mixpanel with an org-level service account, project ID, and region.](/connectors/mixpanel/) --- ## Source: https://onequery.dev/connectors/aws-athena-connector/ [Connectors](/connectors/) / AWS Athena Connector Warehouses connector # AWS Athena Connector connector for governed AI agent access Connect an Athena connector already registered with this org in OneQuery. ConnectorQuery [Setup docs](/docs/guide/connect-source/)[All connectors](/connectors/) - Source AWS Athena Connector - Access model Query - Setup surface Dashboard and CLI - Provider key `aws_athena_connector` Direct answer ## OneQuery supports AWS Athena Connector for governed agent access. Teams use the AWS Athena Connector connector to give AI agents SQL-style query workflows for structured data access while OneQuery keeps credentials centralized, limits access to approved sources, and preserves audit logs for review. Agent workflow ## What this connector enables AWS Athena Connector becomes an approved OneQuery source instead of a secret copied into an agent prompt, shell session, or model tool. The agent receives a governed access path, and the source credentials stay behind OneQuery. - Use SQL-style query workflows for structured data access for warehouses context. - Keep AWS Athena Connector credentials centralized and out of agent runtimes. - Review agent access through OneQuery audit history instead of reconstructing direct service usage. Setup checklist ## Prepare the AWS Athena Connector connection Use aws athena connector credentials and connect the source through the Dashboard and CLI. Keep credentials scoped to the data the agent is allowed to read. 1. Retrieve the OneQuery connector ID for the Athena connector already linked to this org. 2. Retrieve the Athena database name and optional workgroup override for the queries you want to run. FAQ ## AWS Athena Connector connector questions ### What is the OneQuery AWS Athena Connector connector? The OneQuery AWS Athena Connector connector makes warehouses context from AWS Athena Connector available to AI agents through SQL-style query workflows for structured data access. Connect an Athena connector already registered with this org in OneQuery. ### How do AI agents access AWS Athena Connector through OneQuery? Agents call OneQuery instead of receiving raw AWS Athena Connector credentials. OneQuery keeps credentials centralized, applies source boundaries, and records access in audit logs while exposing SQL-style query workflows for structured data access. ### How do I set up the AWS Athena Connector connector? Prepare aws athena connector credentials and connect AWS Athena Connector from the OneQuery dashboard or CLI. Start with this setup step: Retrieve the OneQuery connector ID for the Athena connector already linked to this org. Related connectors ## More warehouses sources [**Snowflake** Connect Snowflake with an account identifier, warehouse, database, and login credentials.](/connectors/snowflake/)[**BigQuery** Connect BigQuery with either Google OAuth tokens or a Google Cloud service account JSON key.](/connectors/bigquery/)[**Cloudflare D1** Connect Cloudflare D1 with an account ID, D1 database ID, and account-scoped API token.](/connectors/cloudflare-d1/) --- ## Source: https://onequery.dev/connectors/bigquery/ [Connectors](/connectors/) / BigQuery Warehouses connector # BigQuery connector for governed AI agent access Connect BigQuery with either Google OAuth tokens or a Google Cloud service account JSON key. Query [Setup docs](/docs/guide/connect-source/)[All connectors](/connectors/) - Source BigQuery - Access model Query - Setup surface Dashboard and CLI - Provider key `bigquery` Direct answer ## OneQuery supports BigQuery for governed agent access. Teams use the BigQuery connector to give AI agents SQL-style query workflows for structured data access while OneQuery keeps credentials centralized, limits access to approved sources, and preserves audit logs for review. Agent workflow ## What this connector enables BigQuery becomes an approved OneQuery source instead of a secret copied into an agent prompt, shell session, or model tool. The agent receives a governed access path, and the source credentials stay behind OneQuery. - Use SQL-style query workflows for structured data access for warehouses context. - Keep BigQuery credentials centralized and out of agent runtimes. - Review agent access through OneQuery audit history instead of reconstructing direct service usage. Setup checklist ## Prepare the BigQuery connection Use bigquery credentials and connect the source through the Dashboard and CLI. Keep credentials scoped to the data the agent is allowed to read. 1. Retrieve the Google Cloud \`projectId\` that owns the datasets OneQuery should query. 2. For the live service-account flow, create a Google Cloud service account in that project, grant \`BigQuery Data Viewer\` and \`BigQuery Job User\`, then create a JSON key. 3. The CLI does not accept raw Google service-account JSON. Map the downloaded key into \`serviceAccount.projectId\`, \`clientEmail\`, \`privateKey\`, and optional \`privateKeyId\`. 4. If you use OAuth instead, provide \`accessToken\`, \`refreshToken\`, and \`expiresAt\` with the BigQuery readonly scope. FAQ ## BigQuery connector questions ### What is the OneQuery BigQuery connector? The OneQuery BigQuery connector makes warehouses context from BigQuery available to AI agents through SQL-style query workflows for structured data access. Connect BigQuery with either Google OAuth tokens or a Google Cloud service account JSON key. ### How do AI agents access BigQuery through OneQuery? Agents call OneQuery instead of receiving raw BigQuery credentials. OneQuery keeps credentials centralized, applies source boundaries, and records access in audit logs while exposing SQL-style query workflows for structured data access. ### How do I set up the BigQuery connector? Prepare bigquery credentials and connect BigQuery from the OneQuery dashboard or CLI. Start with this setup step: Retrieve the Google Cloud \`projectId\` that owns the datasets OneQuery should query. Related connectors ## More warehouses sources [**Snowflake** Connect Snowflake with an account identifier, warehouse, database, and login credentials.](/connectors/snowflake/)[**Cloudflare D1** Connect Cloudflare D1 with an account ID, D1 database ID, and account-scoped API token.](/connectors/cloudflare-d1/)[**Cloudflare R2 SQL** Connect Cloudflare R2 SQL with an account ID, R2 bucket name, and API token for querying R2 Data Catalog Iceberg tables.](/connectors/cloudflare-r2-sql/) --- ## Source: https://onequery.dev/connectors/cal-com/ [Connectors](/connectors/) / Cal.com Productivity connector # Cal.com connector for governed AI agent access Connect Cal.com API v2 with an API key or compatible bearer token. API [Setup docs](/docs/guide/connect-source/)[All connectors](/connectors/) - Source Cal.com - Access model API - Setup surface Dashboard and CLI - Provider key `cal` Direct answer ## OneQuery supports Cal.com for governed agent access. Teams use the Cal.com connector to give AI agents bounded source API calls for endpoint-specific context while OneQuery keeps credentials centralized, limits access to approved sources, and preserves audit logs for review. Agent workflow ## What this connector enables Cal.com becomes an approved OneQuery source instead of a secret copied into an agent prompt, shell session, or model tool. The agent receives a governed access path, and the source credentials stay behind OneQuery. - Use bounded source API calls for endpoint-specific context for productivity context. - Keep Cal.com credentials centralized and out of agent runtimes. - Review agent access through OneQuery audit history instead of reconstructing direct service usage. Setup checklist ## Prepare the Cal.com connection Use cal credentials and connect the source through the Dashboard and CLI. Keep credentials scoped to the data the agent is allowed to read. 1. Create a Cal.com API key from Settings > Security, or use a managed-user/OAuth access token for endpoints that require it. 2. Copy the token into \`credentials.apiKey\`. 3. Keep \`apiVersion\` at \`2026-05-01\` unless Cal.com documents a newer required \`cal-api-version\` value for the endpoint. FAQ ## Cal.com connector questions ### What is the OneQuery Cal.com connector? The OneQuery Cal.com connector makes productivity context from Cal.com available to AI agents through bounded source API calls for endpoint-specific context. Connect Cal.com API v2 with an API key or compatible bearer token. ### How do AI agents access Cal.com through OneQuery? Agents call OneQuery instead of receiving raw Cal.com credentials. OneQuery keeps credentials centralized, applies source boundaries, and records access in audit logs while exposing bounded source API calls for endpoint-specific context. ### How do I set up the Cal.com connector? Prepare cal credentials and connect Cal.com from the OneQuery dashboard or CLI. Start with this setup step: Create a Cal.com API key from Settings > Security, or use a managed-user/OAuth access token for endpoints that require it. Related connectors ## More productivity sources [**Airtable** Connect Airtable with a Personal Access Token and optional default base ID.](/connectors/airtable/)[**Slack** Connect Slack so agents can read channel and thread history and send messages where the installed app has access.](/connectors/slack/)[**Granola** Connect Granola with an API key that has access to the note scopes you want to query.](/connectors/granola/) --- ## Source: https://onequery.dev/connectors/cloudflare-d1/ [Connectors](/connectors/) / Cloudflare D1 Warehouses connector # Cloudflare D1 connector for governed AI agent access Connect Cloudflare D1 with an account ID, D1 database ID, and account-scoped API token. Query [Setup docs](/docs/guide/connect-source/)[All connectors](/connectors/) - Source Cloudflare D1 - Access model Query - Setup surface Dashboard and CLI - Provider key `cloudflare_d1` Direct answer ## OneQuery supports Cloudflare D1 for governed agent access. Teams use the Cloudflare D1 connector to give AI agents SQL-style query workflows for structured data access while OneQuery keeps credentials centralized, limits access to approved sources, and preserves audit logs for review. Agent workflow ## What this connector enables Cloudflare D1 becomes an approved OneQuery source instead of a secret copied into an agent prompt, shell session, or model tool. The agent receives a governed access path, and the source credentials stay behind OneQuery. - Use SQL-style query workflows for structured data access for warehouses context. - Keep Cloudflare D1 credentials centralized and out of agent runtimes. - Review agent access through OneQuery audit history instead of reconstructing direct service usage. Setup checklist ## Prepare the Cloudflare D1 connection Use cloudflare d1 credentials and connect the source through the Dashboard and CLI. Keep credentials scoped to the data the agent is allowed to read. 1. Copy the Cloudflare Account ID from the dashboard. 2. Copy the D1 database ID from the target database settings. 3. Create a Cloudflare API token that can query the target D1 database. 4. Only include \`apiBaseUrl\` when you need a non-default Cloudflare API origin. FAQ ## Cloudflare D1 connector questions ### What is the OneQuery Cloudflare D1 connector? The OneQuery Cloudflare D1 connector makes warehouses context from Cloudflare D1 available to AI agents through SQL-style query workflows for structured data access. Connect Cloudflare D1 with an account ID, D1 database ID, and account-scoped API token. ### How do AI agents access Cloudflare D1 through OneQuery? Agents call OneQuery instead of receiving raw Cloudflare D1 credentials. OneQuery keeps credentials centralized, applies source boundaries, and records access in audit logs while exposing SQL-style query workflows for structured data access. ### How do I set up the Cloudflare D1 connector? Prepare cloudflare d1 credentials and connect Cloudflare D1 from the OneQuery dashboard or CLI. Start with this setup step: Copy the Cloudflare Account ID from the dashboard. Related connectors ## More warehouses sources [**Snowflake** Connect Snowflake with an account identifier, warehouse, database, and login credentials.](/connectors/snowflake/)[**BigQuery** Connect BigQuery with either Google OAuth tokens or a Google Cloud service account JSON key.](/connectors/bigquery/)[**Cloudflare R2 SQL** Connect Cloudflare R2 SQL with an account ID, R2 bucket name, and API token for querying R2 Data Catalog Iceberg tables.](/connectors/cloudflare-r2-sql/) --- ## Source: https://onequery.dev/connectors/cloudflare-r2-sql/ [Connectors](/connectors/) / Cloudflare R2 SQL Warehouses connector # Cloudflare R2 SQL connector for governed AI agent access Connect Cloudflare R2 SQL with an account ID, R2 bucket name, and API token for querying R2 Data Catalog Iceberg tables. Query [Setup docs](/docs/guide/connect-source/)[All connectors](/connectors/) - Source Cloudflare R2 SQL - Access model Query - Setup surface Dashboard and CLI - Provider key `cloudflare_r2_sql` Direct answer ## OneQuery supports Cloudflare R2 SQL for governed agent access. Teams use the Cloudflare R2 SQL connector to give AI agents SQL-style query workflows for structured data access while OneQuery keeps credentials centralized, limits access to approved sources, and preserves audit logs for review. Agent workflow ## What this connector enables Cloudflare R2 SQL becomes an approved OneQuery source instead of a secret copied into an agent prompt, shell session, or model tool. The agent receives a governed access path, and the source credentials stay behind OneQuery. - Use SQL-style query workflows for structured data access for warehouses context. - Keep Cloudflare R2 SQL credentials centralized and out of agent runtimes. - Review agent access through OneQuery audit history instead of reconstructing direct service usage. Setup checklist ## Prepare the Cloudflare R2 SQL connection Use cloudflare r2 sql credentials and connect the source through the Dashboard and CLI. Keep credentials scoped to the data the agent is allowed to read. 1. Enable R2 Data Catalog for the bucket that owns the Iceberg tables OneQuery should query. 2. Copy the Cloudflare Account ID and the R2 bucket name from the Cloudflare dashboard or Wrangler. 3. Create a Cloudflare API token with R2 SQL read access plus R2 Data Catalog and R2 storage permissions for the target bucket. 4. Only include \`apiBaseUrl\` when you need a non-default R2 SQL API origin. FAQ ## Cloudflare R2 SQL connector questions ### What is the OneQuery Cloudflare R2 SQL connector? The OneQuery Cloudflare R2 SQL connector makes warehouses context from Cloudflare R2 SQL available to AI agents through SQL-style query workflows for structured data access. Connect Cloudflare R2 SQL with an account ID, R2 bucket name, and API token for querying R2 Data Catalog Iceberg tables. ### How do AI agents access Cloudflare R2 SQL through OneQuery? Agents call OneQuery instead of receiving raw Cloudflare R2 SQL credentials. OneQuery keeps credentials centralized, applies source boundaries, and records access in audit logs while exposing SQL-style query workflows for structured data access. ### How do I set up the Cloudflare R2 SQL connector? Prepare cloudflare r2 sql credentials and connect Cloudflare R2 SQL from the OneQuery dashboard or CLI. Start with this setup step: Enable R2 Data Catalog for the bucket that owns the Iceberg tables OneQuery should query. Related connectors ## More warehouses sources [**Snowflake** Connect Snowflake with an account identifier, warehouse, database, and login credentials.](/connectors/snowflake/)[**BigQuery** Connect BigQuery with either Google OAuth tokens or a Google Cloud service account JSON key.](/connectors/bigquery/)[**Cloudflare D1** Connect Cloudflare D1 with an account ID, D1 database ID, and account-scoped API token.](/connectors/cloudflare-d1/) --- ## Source: https://onequery.dev/connectors/cloudflare-web-analytics/ [Connectors](/connectors/) / Cloudflare Web Analytics Product analytics connector # Cloudflare Web Analytics connector for governed AI agent access Connect Cloudflare Web Analytics with an account-scoped API token, account ID, and optional site tag. API [Setup docs](/docs/guide/connect-source/)[All connectors](/connectors/) - Source Cloudflare Web Analytics - Access model API - Setup surface Dashboard and CLI - Provider key `cloudflare_web_analytics` Direct answer ## OneQuery supports Cloudflare Web Analytics for governed agent access. Teams use the Cloudflare Web Analytics connector to give AI agents bounded source API calls for endpoint-specific context while OneQuery keeps credentials centralized, limits access to approved sources, and preserves audit logs for review. Agent workflow ## What this connector enables Cloudflare Web Analytics becomes an approved OneQuery source instead of a secret copied into an agent prompt, shell session, or model tool. The agent receives a governed access path, and the source credentials stay behind OneQuery. - Use bounded source API calls for endpoint-specific context for product analytics context. - Keep Cloudflare Web Analytics credentials centralized and out of agent runtimes. - Review agent access through OneQuery audit history instead of reconstructing direct service usage. Setup checklist ## Prepare the Cloudflare Web Analytics connection Use cloudflare web analytics credentials and connect the source through the Dashboard and CLI. Keep credentials scoped to the data the agent is allowed to read. 1. Copy the Cloudflare Account ID from the dashboard. 2. Create a Cloudflare API token that can read Analytics GraphQL data and Web Analytics RUM site configuration for the account. 3. Optionally copy the Web Analytics site tag from the Web Analytics site details; Source API examples use it as the default GraphQL filter. 4. Use Cloudflare Workers Observability as a separate source when you need Worker telemetry logs. It uses a different API surface even when it shares the same account and token. FAQ ## Cloudflare Web Analytics connector questions ### What is the OneQuery Cloudflare Web Analytics connector? The OneQuery Cloudflare Web Analytics connector makes product analytics context from Cloudflare Web Analytics available to AI agents through bounded source API calls for endpoint-specific context. Connect Cloudflare Web Analytics with an account-scoped API token, account ID, and optional site tag. ### How do AI agents access Cloudflare Web Analytics through OneQuery? Agents call OneQuery instead of receiving raw Cloudflare Web Analytics credentials. OneQuery keeps credentials centralized, applies source boundaries, and records access in audit logs while exposing bounded source API calls for endpoint-specific context. ### How do I set up the Cloudflare Web Analytics connector? Prepare cloudflare web analytics credentials and connect Cloudflare Web Analytics from the OneQuery dashboard or CLI. Start with this setup step: Copy the Cloudflare Account ID from the dashboard. Related connectors ## More product analytics sources [**Google Analytics** Connect Google Analytics with either Google OAuth tokens or a Google Cloud service account JSON key.](/connectors/google-analytics/)[**YouTube Analytics** Connect YouTube Analytics with Google OAuth tokens that can read YouTube Analytics reports.](/connectors/youtube-analytics/)[**Amplitude** Connect Amplitude with a project API key, secret key, and region.](/connectors/amplitude/) --- ## Source: https://onequery.dev/connectors/cloudflare-workers-observability/ [Connectors](/connectors/) / Cloudflare Workers Observability Observability connector # Cloudflare Workers Observability connector for governed AI agent access Connect Cloudflare Workers Observability with an account-scoped API token and account ID. API [Setup docs](/docs/guide/connect-source/)[All connectors](/connectors/) - Source Cloudflare Workers Observability - Access model API - Setup surface Dashboard and CLI - Provider key `cloudflare_workers_observability` Direct answer ## OneQuery supports Cloudflare Workers Observability for governed agent access. Teams use the Cloudflare Workers Observability connector to give AI agents bounded source API calls for endpoint-specific context while OneQuery keeps credentials centralized, limits access to approved sources, and preserves audit logs for review. Agent workflow ## What this connector enables Cloudflare Workers Observability becomes an approved OneQuery source instead of a secret copied into an agent prompt, shell session, or model tool. The agent receives a governed access path, and the source credentials stay behind OneQuery. - Use bounded source API calls for endpoint-specific context for observability context. - Keep Cloudflare Workers Observability credentials centralized and out of agent runtimes. - Review agent access through OneQuery audit history instead of reconstructing direct service usage. Setup checklist ## Prepare the Cloudflare Workers Observability connection Use cloudflare workers observability credentials and connect the source through the Dashboard and CLI. Keep credentials scoped to the data the agent is allowed to read. 1. Enable Workers Logs in the target Worker's Wrangler configuration and redeploy so Cloudflare stores telemetry for the account. 2. Create a Cloudflare API token with the Workers Observability permission required by the telemetry API. 3. Copy the Cloudflare Account ID from the dashboard and pass it as \`credentials.accountId\`. 4. Optionally include \`scriptName\` to document the default Worker service this source usually queries. FAQ ## Cloudflare Workers Observability connector questions ### What is the OneQuery Cloudflare Workers Observability connector? The OneQuery Cloudflare Workers Observability connector makes observability context from Cloudflare Workers Observability available to AI agents through bounded source API calls for endpoint-specific context. Connect Cloudflare Workers Observability with an account-scoped API token and account ID. ### How do AI agents access Cloudflare Workers Observability through OneQuery? Agents call OneQuery instead of receiving raw Cloudflare Workers Observability credentials. OneQuery keeps credentials centralized, applies source boundaries, and records access in audit logs while exposing bounded source API calls for endpoint-specific context. ### How do I set up the Cloudflare Workers Observability connector? Prepare cloudflare workers observability credentials and connect Cloudflare Workers Observability from the OneQuery dashboard or CLI. Start with this setup step: Enable Workers Logs in the target Worker's Wrangler configuration and redeploy so Cloudflare stores telemetry for the account. Related connectors ## More observability sources [**Laminar** Connect Laminar with an API key and optional non-default base URL.](/connectors/laminar/)[**Sentry** Connect Sentry with a Personal Token, organization slug, optional project slug, and optional self-hosted API base URL.](/connectors/sentry/)[**MongoDB** Connect MongoDB with one connection string plus database selection.](/connectors/mongodb/) --- ## Source: https://onequery.dev/connectors/codex-app-server-api/ [Connectors](/connectors/) / Codex App Server API Developer workflow connector # Codex App Server API connector for governed AI agent access Connect the OpenAI-compatible Codex App Server API without exposing its API key to the caller. API [Setup docs](/docs/guide/connect-source/)[All connectors](/connectors/) - Source Codex App Server API - Access model API - Setup surface Dashboard and CLI - Provider key `codex_app_server_api` Direct answer ## OneQuery supports Codex App Server API for governed agent access. Teams use the Codex App Server API connector to give AI agents bounded source API calls for endpoint-specific context while OneQuery keeps credentials centralized, limits access to approved sources, and preserves audit logs for review. Agent workflow ## What this connector enables Codex App Server API becomes an approved OneQuery source instead of a secret copied into an agent prompt, shell session, or model tool. The agent receives a governed access path, and the source credentials stay behind OneQuery. - Use bounded source API calls for endpoint-specific context for developer workflow context. - Keep Codex App Server API credentials centralized and out of agent runtimes. - Review agent access through OneQuery audit history instead of reconstructing direct service usage. Setup checklist ## Prepare the Codex App Server API connection Use codex app server api credentials and connect the source through the Dashboard and CLI. Keep credentials scoped to the data the agent is allowed to read. 1. Run the local codex-app-server-api origin and expose it through a secure HTTPS tunnel or private network endpoint reachable from OneQuery. 2. Set \`apiBaseUrl\` to the API origin, for example \`https\://codex-app-server-api.example.com\`. 3. Create or copy a codex-app-server-api key and store it in \`apiKey\`. 4. Call native paths such as \`/v1/models\`, \`/v1/responses\`, and \`/v1/chat/completions\` through the Source API. FAQ ## Codex App Server API connector questions ### What is the OneQuery Codex App Server API connector? The OneQuery Codex App Server API connector makes developer workflow context from Codex App Server API available to AI agents through bounded source API calls for endpoint-specific context. Connect the OpenAI-compatible Codex App Server API without exposing its API key to the caller. ### How do AI agents access Codex App Server API through OneQuery? Agents call OneQuery instead of receiving raw Codex App Server API credentials. OneQuery keeps credentials centralized, applies source boundaries, and records access in audit logs while exposing bounded source API calls for endpoint-specific context. ### How do I set up the Codex App Server API connector? Prepare codex app server api credentials and connect Codex App Server API from the OneQuery dashboard or CLI. Start with this setup step: Run the local codex-app-server-api origin and expose it through a secure HTTPS tunnel or private network endpoint reachable from OneQuery. Related connectors ## More developer workflow sources [**GitHub** Connect GitHub with a fine-grained personal access token and optional repository or installation scoping.](/connectors/github/)[**Figma** Connect Figma with a personal access token for read-only REST API and grouped design-context access.](/connectors/figma/)[**Discord** Connect Discord with a bot token or OAuth bearer token for Discord REST API access.](/connectors/discord/) --- ## Source: https://onequery.dev/connectors/confluence/ [Connectors](/connectors/) / Confluence Developer workflow connector # Confluence connector for governed AI agent access Connect Confluence Cloud with an Atlassian account email and API token. API [Setup docs](/docs/guide/connect-source/)[All connectors](/connectors/) - Source Confluence - Access model API - Setup surface Dashboard and CLI - Provider key `confluence` Direct answer ## OneQuery supports Confluence for governed agent access. Teams use the Confluence connector to give AI agents bounded source API calls for endpoint-specific context while OneQuery keeps credentials centralized, limits access to approved sources, and preserves audit logs for review. Agent workflow ## What this connector enables Confluence becomes an approved OneQuery source instead of a secret copied into an agent prompt, shell session, or model tool. The agent receives a governed access path, and the source credentials stay behind OneQuery. - Use bounded source API calls for endpoint-specific context for developer workflow context. - Keep Confluence credentials centralized and out of agent runtimes. - Review agent access through OneQuery audit history instead of reconstructing direct service usage. Setup checklist ## Prepare the Confluence connection Use confluence credentials and connect the source through the Dashboard and CLI. Keep credentials scoped to the data the agent is allowed to read. 1. Create an Atlassian API token for the account that can read the Confluence site. 2. Copy the Atlassian account email into \`credentials.email\` and the token into \`credentials.apiToken\`. 3. Set \`siteUrl\` to the Atlassian Cloud site origin, for example \`https\://example.atlassian.net\`. FAQ ## Confluence connector questions ### What is the OneQuery Confluence connector? The OneQuery Confluence connector makes developer workflow context from Confluence available to AI agents through bounded source API calls for endpoint-specific context. Connect Confluence Cloud with an Atlassian account email and API token. ### How do AI agents access Confluence through OneQuery? Agents call OneQuery instead of receiving raw Confluence credentials. OneQuery keeps credentials centralized, applies source boundaries, and records access in audit logs while exposing bounded source API calls for endpoint-specific context. ### How do I set up the Confluence connector? Prepare confluence credentials and connect Confluence from the OneQuery dashboard or CLI. Start with this setup step: Create an Atlassian API token for the account that can read the Confluence site. Related connectors ## More developer workflow sources [**Codex App Server API** Connect the OpenAI-compatible Codex App Server API without exposing its API key to the caller.](/connectors/codex-app-server-api/)[**GitHub** Connect GitHub with a fine-grained personal access token and optional repository or installation scoping.](/connectors/github/)[**Figma** Connect Figma with a personal access token for read-only REST API and grouped design-context access.](/connectors/figma/) --- ## Source: https://onequery.dev/connectors/discord/ [Connectors](/connectors/) / Discord Developer workflow connector # Discord connector for governed AI agent access Connect Discord with a bot token or OAuth bearer token for Discord REST API access. API [Setup docs](/docs/guide/connect-source/)[All connectors](/connectors/) - Source Discord - Access model API - Setup surface Dashboard and CLI - Provider key `discord` Direct answer ## OneQuery supports Discord for governed agent access. Teams use the Discord connector to give AI agents bounded source API calls for endpoint-specific context while OneQuery keeps credentials centralized, limits access to approved sources, and preserves audit logs for review. Agent workflow ## What this connector enables Discord becomes an approved OneQuery source instead of a secret copied into an agent prompt, shell session, or model tool. The agent receives a governed access path, and the source credentials stay behind OneQuery. - Use bounded source API calls for endpoint-specific context for developer workflow context. - Keep Discord credentials centralized and out of agent runtimes. - Review agent access through OneQuery audit history instead of reconstructing direct service usage. Setup checklist ## Prepare the Discord connection Use discord credentials and connect the source through the Dashboard and CLI. Keep credentials scoped to the data the agent is allowed to read. 1. Create a Discord application and bot in the Developer Portal, or provide an OAuth token with the scopes required by the endpoints you will call. 2. Copy the token into \`credentials.token\`; leave \`authScheme\` as \`bot\` for bot tokens or set it to \`bearer\` for OAuth access tokens. 3. Optionally include \`guildId\` so selectors like \`/channels\` expand to \`/guilds/\/channels\`. FAQ ## Discord connector questions ### What is the OneQuery Discord connector? The OneQuery Discord connector makes developer workflow context from Discord available to AI agents through bounded source API calls for endpoint-specific context. Connect Discord with a bot token or OAuth bearer token for Discord REST API access. ### How do AI agents access Discord through OneQuery? Agents call OneQuery instead of receiving raw Discord credentials. OneQuery keeps credentials centralized, applies source boundaries, and records access in audit logs while exposing bounded source API calls for endpoint-specific context. ### How do I set up the Discord connector? Prepare discord credentials and connect Discord from the OneQuery dashboard or CLI. Start with this setup step: Create a Discord application and bot in the Developer Portal, or provide an OAuth token with the scopes required by the endpoints you will call. Related connectors ## More developer workflow sources [**Codex App Server API** Connect the OpenAI-compatible Codex App Server API without exposing its API key to the caller.](/connectors/codex-app-server-api/)[**GitHub** Connect GitHub with a fine-grained personal access token and optional repository or installation scoping.](/connectors/github/)[**Figma** Connect Figma with a personal access token for read-only REST API and grouped design-context access.](/connectors/figma/) --- ## Source: https://onequery.dev/connectors/e2b/ [Connectors](/connectors/) / E2B Developer workflow connector # E2B connector for governed AI agent access Connect E2B with a team API key to inspect sandbox state, logs, metrics, and lifecycle events through read-only Source API calls. API [Setup docs](/docs/guide/connect-source/)[All connectors](/connectors/) - Source E2B - Access model API - Setup surface Dashboard and CLI - Provider key `e2b` Direct answer ## OneQuery supports E2B for governed agent access. Teams use the E2B connector to give AI agents bounded source API calls for endpoint-specific context while OneQuery keeps credentials centralized, limits access to approved sources, and preserves audit logs for review. Agent workflow ## What this connector enables E2B becomes an approved OneQuery source instead of a secret copied into an agent prompt, shell session, or model tool. The agent receives a governed access path, and the source credentials stay behind OneQuery. - Use bounded source API calls for endpoint-specific context for developer workflow context. - Keep E2B credentials centralized and out of agent runtimes. - Review agent access through OneQuery audit history instead of reconstructing direct service usage. Setup checklist ## Prepare the E2B connection Use e2b credentials and connect the source through the Dashboard and CLI. Keep credentials scoped to the data the agent is allowed to read. 1. Create or copy an E2B team API key from the E2B dashboard. 2. Copy the key into \`credentials.apiKey\`. 3. Use the default API base URL unless you need a non-default E2B-compatible API origin. 4. Keep this source read-only for debugging; sandbox lifecycle mutations are intentionally out of scope. FAQ ## E2B connector questions ### What is the OneQuery E2B connector? The OneQuery E2B connector makes developer workflow context from E2B available to AI agents through bounded source API calls for endpoint-specific context. Connect E2B with a team API key to inspect sandbox state, logs, metrics, and lifecycle events through read-only Source API calls. ### How do AI agents access E2B through OneQuery? Agents call OneQuery instead of receiving raw E2B credentials. OneQuery keeps credentials centralized, applies source boundaries, and records access in audit logs while exposing bounded source API calls for endpoint-specific context. ### How do I set up the E2B connector? Prepare e2b credentials and connect E2B from the OneQuery dashboard or CLI. Start with this setup step: Create or copy an E2B team API key from the E2B dashboard. Related connectors ## More developer workflow sources [**Codex App Server API** Connect the OpenAI-compatible Codex App Server API without exposing its API key to the caller.](/connectors/codex-app-server-api/)[**GitHub** Connect GitHub with a fine-grained personal access token and optional repository or installation scoping.](/connectors/github/)[**Figma** Connect Figma with a personal access token for read-only REST API and grouped design-context access.](/connectors/figma/) --- ## Source: https://onequery.dev/connectors/figma/ [Connectors](/connectors/) / Figma Developer workflow connector # Figma connector for governed AI agent access Connect Figma with a personal access token for read-only REST API and grouped design-context access. API [Setup docs](/docs/guide/connect-source/)[All connectors](/connectors/) - Source Figma - Access model API - Setup surface Dashboard and CLI - Provider key `figma` Direct answer ## OneQuery supports Figma for governed agent access. Teams use the Figma connector to give AI agents bounded source API calls for endpoint-specific context while OneQuery keeps credentials centralized, limits access to approved sources, and preserves audit logs for review. Agent workflow ## What this connector enables Figma becomes an approved OneQuery source instead of a secret copied into an agent prompt, shell session, or model tool. The agent receives a governed access path, and the source credentials stay behind OneQuery. - Use bounded source API calls for endpoint-specific context for developer workflow context. - Keep Figma credentials centralized and out of agent runtimes. - Review agent access through OneQuery audit history instead of reconstructing direct service usage. Setup checklist ## Prepare the Figma connection Use figma credentials and connect the source through the Dashboard and CLI. Keep credentials scoped to the data the agent is allowed to read. 1. Create a Figma personal access token with the \`file\_content:read\` scope. 2. Add \`file\_variables:read\` when grouped design-context requests should include local variable definitions. 3. Copy the token into \`credentials.personalAccessToken\`. 4. Use \`fetch\_api\` for read-only REST paths or \`prepare\_design\_context\` to bundle nodes, renders, image fills, and optional variables for selected frames. FAQ ## Figma connector questions ### What is the OneQuery Figma connector? The OneQuery Figma connector makes developer workflow context from Figma available to AI agents through bounded source API calls for endpoint-specific context. Connect Figma with a personal access token for read-only REST API and grouped design-context access. ### How do AI agents access Figma through OneQuery? Agents call OneQuery instead of receiving raw Figma credentials. OneQuery keeps credentials centralized, applies source boundaries, and records access in audit logs while exposing bounded source API calls for endpoint-specific context. ### How do I set up the Figma connector? Prepare figma credentials and connect Figma from the OneQuery dashboard or CLI. Start with this setup step: Create a Figma personal access token with the \`file\_content:read\` scope. Related connectors ## More developer workflow sources [**Codex App Server API** Connect the OpenAI-compatible Codex App Server API without exposing its API key to the caller.](/connectors/codex-app-server-api/)[**GitHub** Connect GitHub with a fine-grained personal access token and optional repository or installation scoping.](/connectors/github/)[**Discord** Connect Discord with a bot token or OAuth bearer token for Discord REST API access.](/connectors/discord/) --- ## Source: https://onequery.dev/connectors/github/ [Connectors](/connectors/) / GitHub Developer workflow connector # GitHub connector for governed AI agent access Connect GitHub with a fine-grained personal access token and optional repository or installation scoping. API [Setup docs](/docs/guide/connect-source/)[All connectors](/connectors/) - Source GitHub - Access model API - Setup surface Dashboard and CLI - Provider key `github` Direct answer ## OneQuery supports GitHub for governed agent access. Teams use the GitHub connector to give AI agents bounded source API calls for endpoint-specific context while OneQuery keeps credentials centralized, limits access to approved sources, and preserves audit logs for review. Agent workflow ## What this connector enables GitHub becomes an approved OneQuery source instead of a secret copied into an agent prompt, shell session, or model tool. The agent receives a governed access path, and the source credentials stay behind OneQuery. - Use bounded source API calls for endpoint-specific context for developer workflow context. - Keep GitHub credentials centralized and out of agent runtimes. - Review agent access through OneQuery audit history instead of reconstructing direct service usage. Setup checklist ## Prepare the GitHub connection Use github credentials and connect the source through the Dashboard and CLI. Keep credentials scoped to the data the agent is allowed to read. 1. Create a fine-grained personal access token for the correct resource owner. 2. Grant read-only repository permissions for Contents, Issues, Pull requests, and Metadata. 3. Copy the token into \`credentials.accessToken\`; optionally include \`installationId\` and \`repositories\`. FAQ ## GitHub connector questions ### What is the OneQuery GitHub connector? The OneQuery GitHub connector makes developer workflow context from GitHub available to AI agents through bounded source API calls for endpoint-specific context. Connect GitHub with a fine-grained personal access token and optional repository or installation scoping. ### How do AI agents access GitHub through OneQuery? Agents call OneQuery instead of receiving raw GitHub credentials. OneQuery keeps credentials centralized, applies source boundaries, and records access in audit logs while exposing bounded source API calls for endpoint-specific context. ### How do I set up the GitHub connector? Prepare github credentials and connect GitHub from the OneQuery dashboard or CLI. Start with this setup step: Create a fine-grained personal access token for the correct resource owner. Related connectors ## More developer workflow sources [**Codex App Server API** Connect the OpenAI-compatible Codex App Server API without exposing its API key to the caller.](/connectors/codex-app-server-api/)[**Figma** Connect Figma with a personal access token for read-only REST API and grouped design-context access.](/connectors/figma/)[**Discord** Connect Discord with a bot token or OAuth bearer token for Discord REST API access.](/connectors/discord/) --- ## Source: https://onequery.dev/connectors/google-analytics/ [Connectors](/connectors/) / Google Analytics Product analytics connector # Google Analytics connector for governed AI agent access Connect Google Analytics with either Google OAuth tokens or a Google Cloud service account JSON key. API [Setup docs](/docs/guide/connect-source/)[All connectors](/connectors/) - Source Google Analytics - Access model API - Setup surface Dashboard and CLI - Provider key `ga` Direct answer ## OneQuery supports Google Analytics for governed agent access. Teams use the Google Analytics connector to give AI agents bounded source API calls for endpoint-specific context while OneQuery keeps credentials centralized, limits access to approved sources, and preserves audit logs for review. Agent workflow ## What this connector enables Google Analytics becomes an approved OneQuery source instead of a secret copied into an agent prompt, shell session, or model tool. The agent receives a governed access path, and the source credentials stay behind OneQuery. - Use bounded source API calls for endpoint-specific context for product analytics context. - Keep Google Analytics credentials centralized and out of agent runtimes. - Review agent access through OneQuery audit history instead of reconstructing direct service usage. Setup checklist ## Prepare the Google Analytics connection Use ga credentials and connect the source through the Dashboard and CLI. Keep credentials scoped to the data the agent is allowed to read. 1. Retrieve the GA4 \`propertyId\` from \`Admin > Property details\`. 2. For the live service-account flow, create a Google Cloud service account, create a JSON key, then add that service-account email as a GA4 Viewer. 3. The CLI does not accept raw Google service-account JSON. Map the downloaded key into \`serviceAccount.projectId\`, \`clientEmail\`, \`privateKey\`, and optional \`privateKeyId\`. 4. If you use OAuth instead, provide \`accessToken\`, \`refreshToken\`, and \`expiresAt\` with the Analytics readonly scope. FAQ ## Google Analytics connector questions ### What is the OneQuery Google Analytics connector? The OneQuery Google Analytics connector makes product analytics context from Google Analytics available to AI agents through bounded source API calls for endpoint-specific context. Connect Google Analytics with either Google OAuth tokens or a Google Cloud service account JSON key. ### How do AI agents access Google Analytics through OneQuery? Agents call OneQuery instead of receiving raw Google Analytics credentials. OneQuery keeps credentials centralized, applies source boundaries, and records access in audit logs while exposing bounded source API calls for endpoint-specific context. ### How do I set up the Google Analytics connector? Prepare ga credentials and connect Google Analytics from the OneQuery dashboard or CLI. Start with this setup step: Retrieve the GA4 \`propertyId\` from \`Admin > Property details\`. Related connectors ## More product analytics sources [**YouTube Analytics** Connect YouTube Analytics with Google OAuth tokens that can read YouTube Analytics reports.](/connectors/youtube-analytics/)[**Amplitude** Connect Amplitude with a project API key, secret key, and region.](/connectors/amplitude/)[**Mixpanel** Connect Mixpanel with an org-level service account, project ID, and region.](/connectors/mixpanel/) --- ## Source: https://onequery.dev/connectors/google-search-console/ [Connectors](/connectors/) / Google Search Console Marketing connector # Google Search Console connector for governed AI agent access Connect Google Search Console with Google OAuth or an OAuth access token and optional default site URL. API [Setup docs](/docs/guide/connect-source/)[All connectors](/connectors/) - Source Google Search Console - Access model API - Setup surface Dashboard and CLI - Provider key `google_search_console` Direct answer ## OneQuery supports Google Search Console for governed agent access. Teams use the Google Search Console connector to give AI agents bounded source API calls for endpoint-specific context while OneQuery keeps credentials centralized, limits access to approved sources, and preserves audit logs for review. Agent workflow ## What this connector enables Google Search Console becomes an approved OneQuery source instead of a secret copied into an agent prompt, shell session, or model tool. The agent receives a governed access path, and the source credentials stay behind OneQuery. - Use bounded source API calls for endpoint-specific context for marketing context. - Keep Google Search Console credentials centralized and out of agent runtimes. - Review agent access through OneQuery audit history instead of reconstructing direct service usage. Setup checklist ## Prepare the Google Search Console connection Use google search console credentials and connect the source through the Dashboard and CLI. Keep credentials scoped to the data the agent is allowed to read. 1. Confirm the Search Console property is visible to the Google account that will authorize OneQuery. 2. Use the dashboard \`Connect with Google\` flow, or create an OAuth 2.0 access token with the \`https\://www\.googleapis.com/auth/webmasters.readonly\` scope for CLI/JSON connections. 3. For CLI/JSON connections, copy the token into \`credentials.accessToken\`; optionally include the exact Search Console property string in \`credentials.siteUrl\` so selector \`/searchAnalytics/query\` expands to \`/sites/\/searchAnalytics/query\`. FAQ ## Google Search Console connector questions ### What is the OneQuery Google Search Console connector? The OneQuery Google Search Console connector makes marketing context from Google Search Console available to AI agents through bounded source API calls for endpoint-specific context. Connect Google Search Console with Google OAuth or an OAuth access token and optional default site URL. ### How do AI agents access Google Search Console through OneQuery? Agents call OneQuery instead of receiving raw Google Search Console credentials. OneQuery keeps credentials centralized, applies source boundaries, and records access in audit logs while exposing bounded source API calls for endpoint-specific context. ### How do I set up the Google Search Console connector? Prepare google search console credentials and connect Google Search Console from the OneQuery dashboard or CLI. Start with this setup step: Confirm the Search Console property is visible to the Google account that will authorize OneQuery. Related connectors ## More marketing sources [**Amazon Ads** Connect Amazon Ads with a Login with Amazon access token, client ID, region, and optional profile ID.](/connectors/amazon-ads/)[**LinkedIn Ads** Connect LinkedIn Ads with a Marketing API OAuth access token and version header.](/connectors/linkedin-ads/)[**TikTok Marketing** Connect TikTok Marketing API with an API for Business access token.](/connectors/tiktok-marketing/) --- ## Source: https://onequery.dev/connectors/granola/ [Connectors](/connectors/) / Granola Productivity connector # Granola connector for governed AI agent access Connect Granola with an API key that has access to the note scopes you want to query. API [Setup docs](/docs/guide/connect-source/)[All connectors](/connectors/) - Source Granola - Access model API - Setup surface Dashboard and CLI - Provider key `granola` Direct answer ## OneQuery supports Granola for governed agent access. Teams use the Granola connector to give AI agents bounded source API calls for endpoint-specific context while OneQuery keeps credentials centralized, limits access to approved sources, and preserves audit logs for review. Agent workflow ## What this connector enables Granola becomes an approved OneQuery source instead of a secret copied into an agent prompt, shell session, or model tool. The agent receives a governed access path, and the source credentials stay behind OneQuery. - Use bounded source API calls for endpoint-specific context for productivity context. - Keep Granola credentials centralized and out of agent runtimes. - Review agent access through OneQuery audit history instead of reconstructing direct service usage. Setup checklist ## Prepare the Granola connection Use granola credentials and connect the source through the Dashboard and CLI. Keep credentials scoped to the data the agent is allowed to read. 1. Create a Granola API key from the desktop app under Settings > Connectors > API keys. 2. Choose the Personal notes and/or Public notes scopes needed for OneQuery. 3. Copy the generated key into \`credentials.apiKey\`. FAQ ## Granola connector questions ### What is the OneQuery Granola connector? The OneQuery Granola connector makes productivity context from Granola available to AI agents through bounded source API calls for endpoint-specific context. Connect Granola with an API key that has access to the note scopes you want to query. ### How do AI agents access Granola through OneQuery? Agents call OneQuery instead of receiving raw Granola credentials. OneQuery keeps credentials centralized, applies source boundaries, and records access in audit logs while exposing bounded source API calls for endpoint-specific context. ### How do I set up the Granola connector? Prepare granola credentials and connect Granola from the OneQuery dashboard or CLI. Start with this setup step: Create a Granola API key from the desktop app under Settings > Connectors > API keys. Related connectors ## More productivity sources [**Airtable** Connect Airtable with a Personal Access Token and optional default base ID.](/connectors/airtable/)[**Slack** Connect Slack so agents can read channel and thread history and send messages where the installed app has access.](/connectors/slack/)[**Cal.com** Connect Cal.com API v2 with an API key or compatible bearer token.](/connectors/cal-com/) --- ## Source: https://onequery.dev/connectors/hermes-agent/ [Connectors](/connectors/) / Hermes Agent Developer workflow connector # Hermes Agent connector for governed AI agent access Connect the native Hermes Agent HTTP API without exposing its API key to the caller. API [Setup docs](/docs/guide/connect-source/)[All connectors](/connectors/) - Source Hermes Agent - Access model API - Setup surface Dashboard and CLI - Provider key `hermes` Direct answer ## OneQuery supports Hermes Agent for governed agent access. Teams use the Hermes Agent connector to give AI agents bounded source API calls for endpoint-specific context while OneQuery keeps credentials centralized, limits access to approved sources, and preserves audit logs for review. Agent workflow ## What this connector enables Hermes Agent becomes an approved OneQuery source instead of a secret copied into an agent prompt, shell session, or model tool. The agent receives a governed access path, and the source credentials stay behind OneQuery. - Use bounded source API calls for endpoint-specific context for developer workflow context. - Keep Hermes Agent credentials centralized and out of agent runtimes. - Review agent access through OneQuery audit history instead of reconstructing direct service usage. Setup checklist ## Prepare the Hermes Agent connection Use hermes credentials and connect the source through the Dashboard and CLI. Keep credentials scoped to the data the agent is allowed to read. 1. Enable the Hermes Agent API server with \`API\_SERVER\_ENABLED=true\` and a strong \`API\_SERVER\_KEY\`. 2. Expose the local Hermes API server through a secure HTTPS tunnel or private network endpoint reachable from OneQuery. 3. Set \`apiBaseUrl\` to the Hermes API origin, for example a Cloudflare Tunnel URL. 4. Copy the Hermes \`API\_SERVER\_KEY\` into \`apiKey\`. 5. Call native paths such as \`/v1/models\`, \`/v1/responses\`, \`/v1/runs\`, \`/api/sessions\`, and \`/api/jobs\` through the Source API. FAQ ## Hermes Agent connector questions ### What is the OneQuery Hermes Agent connector? The OneQuery Hermes Agent connector makes developer workflow context from Hermes Agent available to AI agents through bounded source API calls for endpoint-specific context. Connect the native Hermes Agent HTTP API without exposing its API key to the caller. ### How do AI agents access Hermes Agent through OneQuery? Agents call OneQuery instead of receiving raw Hermes Agent credentials. OneQuery keeps credentials centralized, applies source boundaries, and records access in audit logs while exposing bounded source API calls for endpoint-specific context. ### How do I set up the Hermes Agent connector? Prepare hermes credentials and connect Hermes Agent from the OneQuery dashboard or CLI. Start with this setup step: Enable the Hermes Agent API server with \`API\_SERVER\_ENABLED=true\` and a strong \`API\_SERVER\_KEY\`. Related connectors ## More developer workflow sources [**Codex App Server API** Connect the OpenAI-compatible Codex App Server API without exposing its API key to the caller.](/connectors/codex-app-server-api/)[**GitHub** Connect GitHub with a fine-grained personal access token and optional repository or installation scoping.](/connectors/github/)[**Figma** Connect Figma with a personal access token for read-only REST API and grouped design-context access.](/connectors/figma/) --- ## Source: https://onequery.dev/connectors/jam/ [Connectors](/connectors/) / Jam Developer workflow connector # Jam connector for governed AI agent access Connect a Jam workspace through Jam MCP with a read-only personal access token. API [Setup docs](/docs/guide/connect-source/)[All connectors](/connectors/) - Source Jam - Access model API - Setup surface Dashboard and CLI - Provider key `jam` Direct answer ## OneQuery supports Jam for governed agent access. Teams use the Jam connector to give AI agents bounded source API calls for endpoint-specific context while OneQuery keeps credentials centralized, limits access to approved sources, and preserves audit logs for review. Agent workflow ## What this connector enables Jam becomes an approved OneQuery source instead of a secret copied into an agent prompt, shell session, or model tool. The agent receives a governed access path, and the source credentials stay behind OneQuery. - Use bounded source API calls for endpoint-specific context for developer workflow context. - Keep Jam credentials centralized and out of agent runtimes. - Review agent access through OneQuery audit history instead of reconstructing direct service usage. Setup checklist ## Prepare the Jam connection Use jam credentials and connect the source through the Dashboard and CLI. Keep credentials scoped to the data the agent is allowed to read. 1. Open Jam workspace Settings, choose MCP, and create a personal access token for this connection. 2. Grant only the \`mcp:read\` scope so OneQuery can inspect Jams without moving them or adding comments. 3. Copy the token immediately and store it in \`credentials.accessToken\`; Jam does not show the token again after creation. FAQ ## Jam connector questions ### What is the OneQuery Jam connector? The OneQuery Jam connector makes developer workflow context from Jam available to AI agents through bounded source API calls for endpoint-specific context. Connect a Jam workspace through Jam MCP with a read-only personal access token. ### How do AI agents access Jam through OneQuery? Agents call OneQuery instead of receiving raw Jam credentials. OneQuery keeps credentials centralized, applies source boundaries, and records access in audit logs while exposing bounded source API calls for endpoint-specific context. ### How do I set up the Jam connector? Prepare jam credentials and connect Jam from the OneQuery dashboard or CLI. Start with this setup step: Open Jam workspace Settings, choose MCP, and create a personal access token for this connection. Related connectors ## More developer workflow sources [**Codex App Server API** Connect the OpenAI-compatible Codex App Server API without exposing its API key to the caller.](/connectors/codex-app-server-api/)[**GitHub** Connect GitHub with a fine-grained personal access token and optional repository or installation scoping.](/connectors/github/)[**Figma** Connect Figma with a personal access token for read-only REST API and grouped design-context access.](/connectors/figma/) --- ## Source: https://onequery.dev/connectors/jira/ [Connectors](/connectors/) / Jira Developer workflow connector # Jira connector for governed AI agent access Connect Jira Cloud with an Atlassian account email and API token. API [Setup docs](/docs/guide/connect-source/)[All connectors](/connectors/) - Source Jira - Access model API - Setup surface Dashboard and CLI - Provider key `jira` Direct answer ## OneQuery supports Jira for governed agent access. Teams use the Jira connector to give AI agents bounded source API calls for endpoint-specific context while OneQuery keeps credentials centralized, limits access to approved sources, and preserves audit logs for review. Agent workflow ## What this connector enables Jira becomes an approved OneQuery source instead of a secret copied into an agent prompt, shell session, or model tool. The agent receives a governed access path, and the source credentials stay behind OneQuery. - Use bounded source API calls for endpoint-specific context for developer workflow context. - Keep Jira credentials centralized and out of agent runtimes. - Review agent access through OneQuery audit history instead of reconstructing direct service usage. Setup checklist ## Prepare the Jira connection Use jira credentials and connect the source through the Dashboard and CLI. Keep credentials scoped to the data the agent is allowed to read. 1. Create an Atlassian API token for the account that can read the Jira site. 2. Copy the Atlassian account email into \`credentials.email\` and the token into \`credentials.apiToken\`. 3. Set \`siteUrl\` to the Atlassian Cloud site origin, for example \`https\://example.atlassian.net\`. FAQ ## Jira connector questions ### What is the OneQuery Jira connector? The OneQuery Jira connector makes developer workflow context from Jira available to AI agents through bounded source API calls for endpoint-specific context. Connect Jira Cloud with an Atlassian account email and API token. ### How do AI agents access Jira through OneQuery? Agents call OneQuery instead of receiving raw Jira credentials. OneQuery keeps credentials centralized, applies source boundaries, and records access in audit logs while exposing bounded source API calls for endpoint-specific context. ### How do I set up the Jira connector? Prepare jira credentials and connect Jira from the OneQuery dashboard or CLI. Start with this setup step: Create an Atlassian API token for the account that can read the Jira site. Related connectors ## More developer workflow sources [**Codex App Server API** Connect the OpenAI-compatible Codex App Server API without exposing its API key to the caller.](/connectors/codex-app-server-api/)[**GitHub** Connect GitHub with a fine-grained personal access token and optional repository or installation scoping.](/connectors/github/)[**Figma** Connect Figma with a personal access token for read-only REST API and grouped design-context access.](/connectors/figma/) --- ## Source: https://onequery.dev/connectors/laminar/ [Connectors](/connectors/) / Laminar Observability connector # Laminar connector for governed AI agent access Connect Laminar with an API key and optional non-default base URL. Query [Setup docs](/docs/guide/connect-source/)[All connectors](/connectors/) - Source Laminar - Access model Query - Setup surface Dashboard and CLI - Provider key `laminar` Direct answer ## OneQuery supports Laminar for governed agent access. Teams use the Laminar connector to give AI agents SQL-style query workflows for structured data access while OneQuery keeps credentials centralized, limits access to approved sources, and preserves audit logs for review. Agent workflow ## What this connector enables Laminar becomes an approved OneQuery source instead of a secret copied into an agent prompt, shell session, or model tool. The agent receives a governed access path, and the source credentials stay behind OneQuery. - Use SQL-style query workflows for structured data access for observability context. - Keep Laminar credentials centralized and out of agent runtimes. - Review agent access through OneQuery audit history instead of reconstructing direct service usage. Setup checklist ## Prepare the Laminar connection Use laminar credentials and connect the source through the Dashboard and CLI. Keep credentials scoped to the data the agent is allowed to read. 1. Retrieve a Laminar API key with access to the target workspace. 2. Only include \`apiBaseUrl\` when the account uses a non-default Laminar API host. FAQ ## Laminar connector questions ### What is the OneQuery Laminar connector? The OneQuery Laminar connector makes observability context from Laminar available to AI agents through SQL-style query workflows for structured data access. Connect Laminar with an API key and optional non-default base URL. ### How do AI agents access Laminar through OneQuery? Agents call OneQuery instead of receiving raw Laminar credentials. OneQuery keeps credentials centralized, applies source boundaries, and records access in audit logs while exposing SQL-style query workflows for structured data access. ### How do I set up the Laminar connector? Prepare laminar credentials and connect Laminar from the OneQuery dashboard or CLI. Start with this setup step: Retrieve a Laminar API key with access to the target workspace. Related connectors ## More observability sources [**Sentry** Connect Sentry with a Personal Token, organization slug, optional project slug, and optional self-hosted API base URL.](/connectors/sentry/)[**Cloudflare Workers Observability** Connect Cloudflare Workers Observability with an account-scoped API token and account ID.](/connectors/cloudflare-workers-observability/)[**PostgreSQL** Connect a Postgres database with a direct host, database, and login.](/connectors/postgresql/) --- ## Source: https://onequery.dev/connectors/linear/ [Connectors](/connectors/) / Linear Developer workflow connector # Linear connector for governed AI agent access Connect Linear with an API key and choose whether agents can only receive mentions, read issues, or read and create issues. APIWorkflow [Setup docs](/docs/guide/connect-source/)[All connectors](/connectors/) - Source Linear - Access model API - Setup surface Dashboard and CLI - Provider key `linear` Direct answer ## OneQuery supports Linear for governed agent access. Teams use the Linear connector to give AI agents bounded source API calls for endpoint-specific context while OneQuery keeps credentials centralized, limits access to approved sources, and preserves audit logs for review. Agent workflow ## What this connector enables Linear becomes an approved OneQuery source instead of a secret copied into an agent prompt, shell session, or model tool. The agent receives a governed access path, and the source credentials stay behind OneQuery. - Use bounded source API calls for endpoint-specific context for developer workflow context. - Keep Linear credentials centralized and out of agent runtimes. - Review agent access through OneQuery audit history instead of reconstructing direct service usage. Setup checklist ## Prepare the Linear connection Use linear credentials and connect the source through the Dashboard and CLI. Keep credentials scoped to the data the agent is allowed to read. 1. Create a Linear API key for the workspace you want OneQuery to access. 2. Choose \`mention\`, \`read\`, or \`read\_write\` in \`credentials.accessMode\`. 3. Optionally set \`credentials.graphqlAllowList\` to enable raw \`graphql\_request\` for selected Linear GraphQL root fields. 4. Use \`mention\` when OneQuery should keep the connection metadata but must not expose Linear issue reads or writes through Source API. FAQ ## Linear connector questions ### What is the OneQuery Linear connector? The OneQuery Linear connector makes developer workflow context from Linear available to AI agents through bounded source API calls for endpoint-specific context. Connect Linear with an API key and choose whether agents can only receive mentions, read issues, or read and create issues. ### How do AI agents access Linear through OneQuery? Agents call OneQuery instead of receiving raw Linear credentials. OneQuery keeps credentials centralized, applies source boundaries, and records access in audit logs while exposing bounded source API calls for endpoint-specific context. ### How do I set up the Linear connector? Prepare linear credentials and connect Linear from the OneQuery dashboard or CLI. Start with this setup step: Create a Linear API key for the workspace you want OneQuery to access. Related connectors ## More developer workflow sources [**Codex App Server API** Connect the OpenAI-compatible Codex App Server API without exposing its API key to the caller.](/connectors/codex-app-server-api/)[**GitHub** Connect GitHub with a fine-grained personal access token and optional repository or installation scoping.](/connectors/github/)[**Figma** Connect Figma with a personal access token for read-only REST API and grouped design-context access.](/connectors/figma/) --- ## Source: https://onequery.dev/connectors/linkedin-ads/ [Connectors](/connectors/) / LinkedIn Ads Marketing connector # LinkedIn Ads connector for governed AI agent access Connect LinkedIn Ads with a Marketing API OAuth access token and version header. API [Setup docs](/docs/guide/connect-source/)[All connectors](/connectors/) - Source LinkedIn Ads - Access model API - Setup surface Dashboard and CLI - Provider key `linkedin_ads` Direct answer ## OneQuery supports LinkedIn Ads for governed agent access. Teams use the LinkedIn Ads connector to give AI agents bounded source API calls for endpoint-specific context while OneQuery keeps credentials centralized, limits access to approved sources, and preserves audit logs for review. Agent workflow ## What this connector enables LinkedIn Ads becomes an approved OneQuery source instead of a secret copied into an agent prompt, shell session, or model tool. The agent receives a governed access path, and the source credentials stay behind OneQuery. - Use bounded source API calls for endpoint-specific context for marketing context. - Keep LinkedIn Ads credentials centralized and out of agent runtimes. - Review agent access through OneQuery audit history instead of reconstructing direct service usage. Setup checklist ## Prepare the LinkedIn Ads connection Use linkedin ads credentials and connect the source through the Dashboard and CLI. Keep credentials scoped to the data the agent is allowed to read. 1. Create or obtain a LinkedIn Marketing API OAuth access token with access to the ad accounts OneQuery should query. 2. Use a supported Marketing API version as \`credentials.apiVersion\` in \`YYYYMM\` format; OneQuery defaults to \`202605\`. 3. Only include \`apiBaseUrl\` when you need a non-default LinkedIn-compatible API origin. FAQ ## LinkedIn Ads connector questions ### What is the OneQuery LinkedIn Ads connector? The OneQuery LinkedIn Ads connector makes marketing context from LinkedIn Ads available to AI agents through bounded source API calls for endpoint-specific context. Connect LinkedIn Ads with a Marketing API OAuth access token and version header. ### How do AI agents access LinkedIn Ads through OneQuery? Agents call OneQuery instead of receiving raw LinkedIn Ads credentials. OneQuery keeps credentials centralized, applies source boundaries, and records access in audit logs while exposing bounded source API calls for endpoint-specific context. ### How do I set up the LinkedIn Ads connector? Prepare linkedin ads credentials and connect LinkedIn Ads from the OneQuery dashboard or CLI. Start with this setup step: Create or obtain a LinkedIn Marketing API OAuth access token with access to the ad accounts OneQuery should query. Related connectors ## More marketing sources [**Google Search Console** Connect Google Search Console with Google OAuth or an OAuth access token and optional default site URL.](/connectors/google-search-console/)[**Amazon Ads** Connect Amazon Ads with a Login with Amazon access token, client ID, region, and optional profile ID.](/connectors/amazon-ads/)[**TikTok Marketing** Connect TikTok Marketing API with an API for Business access token.](/connectors/tiktok-marketing/) --- ## Source: https://onequery.dev/connectors/microsoft-clarity/ [Connectors](/connectors/) / Microsoft Clarity Product analytics connector # Microsoft Clarity connector for governed AI agent access Connect Microsoft Clarity with a project Data Export API token. API [Setup docs](/docs/guide/connect-source/)[All connectors](/connectors/) - Source Microsoft Clarity - Access model API - Setup surface Dashboard and CLI - Provider key `microsoft_clarity` Direct answer ## OneQuery supports Microsoft Clarity for governed agent access. Teams use the Microsoft Clarity connector to give AI agents bounded source API calls for endpoint-specific context while OneQuery keeps credentials centralized, limits access to approved sources, and preserves audit logs for review. Agent workflow ## What this connector enables Microsoft Clarity becomes an approved OneQuery source instead of a secret copied into an agent prompt, shell session, or model tool. The agent receives a governed access path, and the source credentials stay behind OneQuery. - Use bounded source API calls for endpoint-specific context for product analytics context. - Keep Microsoft Clarity credentials centralized and out of agent runtimes. - Review agent access through OneQuery audit history instead of reconstructing direct service usage. Setup checklist ## Prepare the Microsoft Clarity connection Use microsoft clarity credentials and connect the source through the Dashboard and CLI. Keep credentials scoped to the data the agent is allowed to read. 1. Open the target Clarity project and generate a Data Export API token from Settings > Data Export. 2. Copy the token into \`credentials.apiToken\`. 3. Only include \`apiBaseUrl\` when you need a non-default Clarity-compatible export API origin. FAQ ## Microsoft Clarity connector questions ### What is the OneQuery Microsoft Clarity connector? The OneQuery Microsoft Clarity connector makes product analytics context from Microsoft Clarity available to AI agents through bounded source API calls for endpoint-specific context. Connect Microsoft Clarity with a project Data Export API token. ### How do AI agents access Microsoft Clarity through OneQuery? Agents call OneQuery instead of receiving raw Microsoft Clarity credentials. OneQuery keeps credentials centralized, applies source boundaries, and records access in audit logs while exposing bounded source API calls for endpoint-specific context. ### How do I set up the Microsoft Clarity connector? Prepare microsoft clarity credentials and connect Microsoft Clarity from the OneQuery dashboard or CLI. Start with this setup step: Open the target Clarity project and generate a Data Export API token from Settings > Data Export. Related connectors ## More product analytics sources [**Google Analytics** Connect Google Analytics with either Google OAuth tokens or a Google Cloud service account JSON key.](/connectors/google-analytics/)[**YouTube Analytics** Connect YouTube Analytics with Google OAuth tokens that can read YouTube Analytics reports.](/connectors/youtube-analytics/)[**Amplitude** Connect Amplitude with a project API key, secret key, and region.](/connectors/amplitude/) --- ## Source: https://onequery.dev/connectors/mixpanel/ [Connectors](/connectors/) / Mixpanel Product analytics connector # Mixpanel connector for governed AI agent access Connect Mixpanel with an org-level service account, project ID, and region. API [Setup docs](/docs/guide/connect-source/)[All connectors](/connectors/) - Source Mixpanel - Access model API - Setup surface Dashboard and CLI - Provider key `mixpanel` Direct answer ## OneQuery supports Mixpanel for governed agent access. Teams use the Mixpanel connector to give AI agents bounded source API calls for endpoint-specific context while OneQuery keeps credentials centralized, limits access to approved sources, and preserves audit logs for review. Agent workflow ## What this connector enables Mixpanel becomes an approved OneQuery source instead of a secret copied into an agent prompt, shell session, or model tool. The agent receives a governed access path, and the source credentials stay behind OneQuery. - Use bounded source API calls for endpoint-specific context for product analytics context. - Keep Mixpanel credentials centralized and out of agent runtimes. - Review agent access through OneQuery audit history instead of reconstructing direct service usage. Setup checklist ## Prepare the Mixpanel connection Use mixpanel credentials and connect the source through the Dashboard and CLI. Keep credentials scoped to the data the agent is allowed to read. 1. Create or retrieve a Mixpanel service account with access to the target project. 2. Copy the service account Username and Secret. 3. Copy the Project ID and map Data Residency to \`region\`: \`US\` -> \`us\`, \`EU\` -> \`eu\`, \`India\` -> \`in\`. FAQ ## Mixpanel connector questions ### What is the OneQuery Mixpanel connector? The OneQuery Mixpanel connector makes product analytics context from Mixpanel available to AI agents through bounded source API calls for endpoint-specific context. Connect Mixpanel with an org-level service account, project ID, and region. ### How do AI agents access Mixpanel through OneQuery? Agents call OneQuery instead of receiving raw Mixpanel credentials. OneQuery keeps credentials centralized, applies source boundaries, and records access in audit logs while exposing bounded source API calls for endpoint-specific context. ### How do I set up the Mixpanel connector? Prepare mixpanel credentials and connect Mixpanel from the OneQuery dashboard or CLI. Start with this setup step: Create or retrieve a Mixpanel service account with access to the target project. Related connectors ## More product analytics sources [**Google Analytics** Connect Google Analytics with either Google OAuth tokens or a Google Cloud service account JSON key.](/connectors/google-analytics/)[**YouTube Analytics** Connect YouTube Analytics with Google OAuth tokens that can read YouTube Analytics reports.](/connectors/youtube-analytics/)[**Amplitude** Connect Amplitude with a project API key, secret key, and region.](/connectors/amplitude/) --- ## Source: https://onequery.dev/connectors/mongodb/ [Connectors](/connectors/) / MongoDB Databases connector # MongoDB connector for governed AI agent access Connect MongoDB with one connection string plus database selection. API [Setup docs](/docs/guide/connect-source/)[All connectors](/connectors/) - Source MongoDB - Access model API - Setup surface Dashboard and CLI - Provider key `mongodb` Direct answer ## OneQuery supports MongoDB for governed agent access. Teams use the MongoDB connector to give AI agents bounded source API calls for endpoint-specific context while OneQuery keeps credentials centralized, limits access to approved sources, and preserves audit logs for review. Agent workflow ## What this connector enables MongoDB becomes an approved OneQuery source instead of a secret copied into an agent prompt, shell session, or model tool. The agent receives a governed access path, and the source credentials stay behind OneQuery. - Use bounded source API calls for endpoint-specific context for databases context. - Keep MongoDB credentials centralized and out of agent runtimes. - Review agent access through OneQuery audit history instead of reconstructing direct service usage. Setup checklist ## Prepare the MongoDB connection Use mongodb credentials and connect the source through the Dashboard and CLI. Keep credentials scoped to the data the agent is allowed to read. 1. Retrieve a MongoDB connection string with the required read access. 2. If the deployment spans multiple databases, include \`databases\`; otherwise provide one \`database\`. FAQ ## MongoDB connector questions ### What is the OneQuery MongoDB connector? The OneQuery MongoDB connector makes databases context from MongoDB available to AI agents through bounded source API calls for endpoint-specific context. Connect MongoDB with one connection string plus database selection. ### How do AI agents access MongoDB through OneQuery? Agents call OneQuery instead of receiving raw MongoDB credentials. OneQuery keeps credentials centralized, applies source boundaries, and records access in audit logs while exposing bounded source API calls for endpoint-specific context. ### How do I set up the MongoDB connector? Prepare mongodb credentials and connect MongoDB from the OneQuery dashboard or CLI. Start with this setup step: Retrieve a MongoDB connection string with the required read access. Related connectors ## More databases sources [**PostgreSQL** Connect a Postgres database with a direct host, database, and login.](/connectors/postgresql/)[**Supabase** Connect Supabase with the session pooler host, database, and login credentials over the Postgres wire protocol.](/connectors/supabase/)[**MySQL** Connect a MySQL database with host, schema, and login credentials.](/connectors/mysql/) --- ## Source: https://onequery.dev/connectors/motherduck/ [Connectors](/connectors/) / MotherDuck Warehouses connector # MotherDuck connector for governed AI agent access Connect MotherDuck through its PostgreSQL wire protocol endpoint with a service token. Query [Setup docs](/docs/guide/connect-source/)[All connectors](/connectors/) - Source MotherDuck - Access model Query - Setup surface Dashboard and CLI - Provider key `motherduck` Direct answer ## OneQuery supports MotherDuck for governed agent access. Teams use the MotherDuck connector to give AI agents SQL-style query workflows for structured data access while OneQuery keeps credentials centralized, limits access to approved sources, and preserves audit logs for review. Agent workflow ## What this connector enables MotherDuck becomes an approved OneQuery source instead of a secret copied into an agent prompt, shell session, or model tool. The agent receives a governed access path, and the source credentials stay behind OneQuery. - Use SQL-style query workflows for structured data access for warehouses context. - Keep MotherDuck credentials centralized and out of agent runtimes. - Review agent access through OneQuery audit history instead of reconstructing direct service usage. Setup checklist ## Prepare the MotherDuck connection Use motherduck credentials and connect the source through the Dashboard and CLI. Keep credentials scoped to the data the agent is allowed to read. 1. Create a MotherDuck service token with access to the target database. 2. Use \`md:\` for the default database, or \`md:database\_name\` for a specific MotherDuck database. 3. Only override host, port, or username if MotherDuck documents a different endpoint for your environment. FAQ ## MotherDuck connector questions ### What is the OneQuery MotherDuck connector? The OneQuery MotherDuck connector makes warehouses context from MotherDuck available to AI agents through SQL-style query workflows for structured data access. Connect MotherDuck through its PostgreSQL wire protocol endpoint with a service token. ### How do AI agents access MotherDuck through OneQuery? Agents call OneQuery instead of receiving raw MotherDuck credentials. OneQuery keeps credentials centralized, applies source boundaries, and records access in audit logs while exposing SQL-style query workflows for structured data access. ### How do I set up the MotherDuck connector? Prepare motherduck credentials and connect MotherDuck from the OneQuery dashboard or CLI. Start with this setup step: Create a MotherDuck service token with access to the target database. Related connectors ## More warehouses sources [**Snowflake** Connect Snowflake with an account identifier, warehouse, database, and login credentials.](/connectors/snowflake/)[**BigQuery** Connect BigQuery with either Google OAuth tokens or a Google Cloud service account JSON key.](/connectors/bigquery/)[**Cloudflare D1** Connect Cloudflare D1 with an account ID, D1 database ID, and account-scoped API token.](/connectors/cloudflare-d1/) --- ## Source: https://onequery.dev/connectors/mysql/ [Connectors](/connectors/) / MySQL Databases connector # MySQL connector for governed AI agent access Connect a MySQL database with host, schema, and login credentials. Query [Setup docs](/docs/guide/connect-source/)[All connectors](/connectors/) - Source MySQL - Access model Query - Setup surface Dashboard and CLI - Provider key `mysql` Direct answer ## OneQuery supports MySQL for governed agent access. Teams use the MySQL connector to give AI agents SQL-style query workflows for structured data access while OneQuery keeps credentials centralized, limits access to approved sources, and preserves audit logs for review. Agent workflow ## What this connector enables MySQL becomes an approved OneQuery source instead of a secret copied into an agent prompt, shell session, or model tool. The agent receives a governed access path, and the source credentials stay behind OneQuery. - Use SQL-style query workflows for structured data access for databases context. - Keep MySQL credentials centralized and out of agent runtimes. - Review agent access through OneQuery audit history instead of reconstructing direct service usage. Setup checklist ## Prepare the MySQL connection Use mysql credentials and connect the source through the Dashboard and CLI. Keep credentials scoped to the data the agent is allowed to read. 1. Retrieve the MySQL host, database name, username, and password from the deployment or secret manager. 2. Confirm the port and SSL requirement before building the payload. FAQ ## MySQL connector questions ### What is the OneQuery MySQL connector? The OneQuery MySQL connector makes databases context from MySQL available to AI agents through SQL-style query workflows for structured data access. Connect a MySQL database with host, schema, and login credentials. ### How do AI agents access MySQL through OneQuery? Agents call OneQuery instead of receiving raw MySQL credentials. OneQuery keeps credentials centralized, applies source boundaries, and records access in audit logs while exposing SQL-style query workflows for structured data access. ### How do I set up the MySQL connector? Prepare mysql credentials and connect MySQL from the OneQuery dashboard or CLI. Start with this setup step: Retrieve the MySQL host, database name, username, and password from the deployment or secret manager. Related connectors ## More databases sources [**PostgreSQL** Connect a Postgres database with a direct host, database, and login.](/connectors/postgresql/)[**Supabase** Connect Supabase with the session pooler host, database, and login credentials over the Postgres wire protocol.](/connectors/supabase/)[**MongoDB** Connect MongoDB with one connection string plus database selection.](/connectors/mongodb/) --- ## Source: https://onequery.dev/connectors/postgresql/ [Connectors](/connectors/) / PostgreSQL Databases connector # PostgreSQL connector for governed AI agent access Connect a Postgres database with a direct host, database, and login. Query [Setup docs](/docs/guide/connect-source/)[All connectors](/connectors/) - Source PostgreSQL - Access model Query - Setup surface Dashboard and CLI - Provider key `postgres` Direct answer ## OneQuery supports PostgreSQL for governed agent access. Teams use the PostgreSQL connector to give AI agents SQL-style query workflows for structured data access while OneQuery keeps credentials centralized, limits access to approved sources, and preserves audit logs for review. Agent workflow ## What this connector enables PostgreSQL becomes an approved OneQuery source instead of a secret copied into an agent prompt, shell session, or model tool. The agent receives a governed access path, and the source credentials stay behind OneQuery. - Use SQL-style query workflows for structured data access for databases context. - Keep PostgreSQL credentials centralized and out of agent runtimes. - Review agent access through OneQuery audit history instead of reconstructing direct service usage. Setup checklist ## Prepare the PostgreSQL connection Use postgres credentials and connect the source through the Dashboard and CLI. Keep credentials scoped to the data the agent is allowed to read. 1. Retrieve the Postgres host, database name, username, and password from the database deployment or secret manager. 2. Confirm the correct port and SSL mode for this environment before sending the payload. FAQ ## PostgreSQL connector questions ### What is the OneQuery PostgreSQL connector? The OneQuery PostgreSQL connector makes databases context from PostgreSQL available to AI agents through SQL-style query workflows for structured data access. Connect a Postgres database with a direct host, database, and login. ### How do AI agents access PostgreSQL through OneQuery? Agents call OneQuery instead of receiving raw PostgreSQL credentials. OneQuery keeps credentials centralized, applies source boundaries, and records access in audit logs while exposing SQL-style query workflows for structured data access. ### How do I set up the PostgreSQL connector? Prepare postgres credentials and connect PostgreSQL from the OneQuery dashboard or CLI. Start with this setup step: Retrieve the Postgres host, database name, username, and password from the database deployment or secret manager. Related connectors ## More databases sources [**Supabase** Connect Supabase with the session pooler host, database, and login credentials over the Postgres wire protocol.](/connectors/supabase/)[**MySQL** Connect a MySQL database with host, schema, and login credentials.](/connectors/mysql/)[**MongoDB** Connect MongoDB with one connection string plus database selection.](/connectors/mongodb/) --- ## Source: https://onequery.dev/connectors/posthog/ [Connectors](/connectors/) / PostHog Product analytics connector # PostHog connector for governed AI agent access Connect PostHog with the PostHog app host URL, a personal API key, and project ID. API [Setup docs](/docs/guide/connect-source/)[All connectors](/connectors/) - Source PostHog - Access model API - Setup surface Dashboard and CLI - Provider key `posthog` Direct answer ## OneQuery supports PostHog for governed agent access. Teams use the PostHog connector to give AI agents bounded source API calls for endpoint-specific context while OneQuery keeps credentials centralized, limits access to approved sources, and preserves audit logs for review. Agent workflow ## What this connector enables PostHog becomes an approved OneQuery source instead of a secret copied into an agent prompt, shell session, or model tool. The agent receives a governed access path, and the source credentials stay behind OneQuery. - Use bounded source API calls for endpoint-specific context for product analytics context. - Keep PostHog credentials centralized and out of agent runtimes. - Review agent access through OneQuery audit history instead of reconstructing direct service usage. Setup checklist ## Prepare the PostHog connection Use posthog credentials and connect the source through the Dashboard and CLI. Keep credentials scoped to the data the agent is allowed to read. 1. Open the PostHog project you want to connect, then go to \`Settings -> Project -> General\` and copy the \`Project ID\` from the \`Project token & ID\` section. 2. Use the PostHog app origin as \`credentials.hostUrl\`: \`https\://us.posthog.com\` for US Cloud, \`https\://eu.posthog.com\` for EU Cloud, or your self-hosted base URL. Do not use the SDK \`api\_host\` value such as \`https\://us.i.posthog.com\`. 3. Go to \`Settings -> Account -> Personal API keys\`, create a personal API key, and make sure \`Organization & project access\` includes the project you plan to connect. 4. Grant at least \`Read\` access to \`Project\` and \`Query\`, then copy the secret immediately into \`credentials.personalApiKey\`. PostHog may only show the full key once. 5. Use the canonical host URL without a trailing slash when possible; the server still normalizes extra trailing slashes. FAQ ## PostHog connector questions ### What is the OneQuery PostHog connector? The OneQuery PostHog connector makes product analytics context from PostHog available to AI agents through bounded source API calls for endpoint-specific context. Connect PostHog with the PostHog app host URL, a personal API key, and project ID. ### How do AI agents access PostHog through OneQuery? Agents call OneQuery instead of receiving raw PostHog credentials. OneQuery keeps credentials centralized, applies source boundaries, and records access in audit logs while exposing bounded source API calls for endpoint-specific context. ### How do I set up the PostHog connector? Prepare posthog credentials and connect PostHog from the OneQuery dashboard or CLI. Start with this setup step: Open the PostHog project you want to connect, then go to \`Settings -> Project -> General\` and copy the \`Project ID\` from the \`Project token & ID\` section. Related connectors ## More product analytics sources [**Google Analytics** Connect Google Analytics with either Google OAuth tokens or a Google Cloud service account JSON key.](/connectors/google-analytics/)[**YouTube Analytics** Connect YouTube Analytics with Google OAuth tokens that can read YouTube Analytics reports.](/connectors/youtube-analytics/)[**Amplitude** Connect Amplitude with a project API key, secret key, and region.](/connectors/amplitude/) --- ## Source: https://onequery.dev/connectors/sendgrid/ [Connectors](/connectors/) / SendGrid Marketing connector # SendGrid connector for governed AI agent access Connect SendGrid with a v3 Web API key. API [Setup docs](/docs/guide/connect-source/)[All connectors](/connectors/) - Source SendGrid - Access model API - Setup surface Dashboard and CLI - Provider key `sendgrid` Direct answer ## OneQuery supports SendGrid for governed agent access. Teams use the SendGrid connector to give AI agents bounded source API calls for endpoint-specific context while OneQuery keeps credentials centralized, limits access to approved sources, and preserves audit logs for review. Agent workflow ## What this connector enables SendGrid becomes an approved OneQuery source instead of a secret copied into an agent prompt, shell session, or model tool. The agent receives a governed access path, and the source credentials stay behind OneQuery. - Use bounded source API calls for endpoint-specific context for marketing context. - Keep SendGrid credentials centralized and out of agent runtimes. - Review agent access through OneQuery audit history instead of reconstructing direct service usage. Setup checklist ## Prepare the SendGrid connection Use sendgrid credentials and connect the source through the Dashboard and CLI. Keep credentials scoped to the data the agent is allowed to read. 1. Create a SendGrid API key with the scopes required for the account, email, or marketing endpoints OneQuery should call. 2. Copy the key into \`credentials.apiKey\`. 3. Only include \`apiBaseUrl\` when you need a non-default SendGrid-compatible API origin. FAQ ## SendGrid connector questions ### What is the OneQuery SendGrid connector? The OneQuery SendGrid connector makes marketing context from SendGrid available to AI agents through bounded source API calls for endpoint-specific context. Connect SendGrid with a v3 Web API key. ### How do AI agents access SendGrid through OneQuery? Agents call OneQuery instead of receiving raw SendGrid credentials. OneQuery keeps credentials centralized, applies source boundaries, and records access in audit logs while exposing bounded source API calls for endpoint-specific context. ### How do I set up the SendGrid connector? Prepare sendgrid credentials and connect SendGrid from the OneQuery dashboard or CLI. Start with this setup step: Create a SendGrid API key with the scopes required for the account, email, or marketing endpoints OneQuery should call. Related connectors ## More marketing sources [**Google Search Console** Connect Google Search Console with Google OAuth or an OAuth access token and optional default site URL.](/connectors/google-search-console/)[**Amazon Ads** Connect Amazon Ads with a Login with Amazon access token, client ID, region, and optional profile ID.](/connectors/amazon-ads/)[**LinkedIn Ads** Connect LinkedIn Ads with a Marketing API OAuth access token and version header.](/connectors/linkedin-ads/) --- ## Source: https://onequery.dev/connectors/sentry/ [Connectors](/connectors/) / Sentry Observability connector # Sentry connector for governed AI agent access Connect Sentry with a Personal Token, organization slug, optional project slug, and optional self-hosted API base URL. API [Setup docs](/docs/guide/connect-source/)[All connectors](/connectors/) - Source Sentry - Access model API - Setup surface Dashboard and CLI - Provider key `sentry` Direct answer ## OneQuery supports Sentry for governed agent access. Teams use the Sentry connector to give AI agents bounded source API calls for endpoint-specific context while OneQuery keeps credentials centralized, limits access to approved sources, and preserves audit logs for review. Agent workflow ## What this connector enables Sentry becomes an approved OneQuery source instead of a secret copied into an agent prompt, shell session, or model tool. The agent receives a governed access path, and the source credentials stay behind OneQuery. - Use bounded source API calls for endpoint-specific context for observability context. - Keep Sentry credentials centralized and out of agent runtimes. - Review agent access through OneQuery audit history instead of reconstructing direct service usage. Setup checklist ## Prepare the Sentry connection Use sentry credentials and connect the source through the Dashboard and CLI. Keep credentials scoped to the data the agent is allowed to read. 1. Create a Sentry Personal Token with organization and project read scopes. 2. Copy the Organization Slug and optional Project Slug. 3. Leave \`credentials.apiBaseUrl\` empty for Sentry Cloud. Set it only for self-hosted Sentry. FAQ ## Sentry connector questions ### What is the OneQuery Sentry connector? The OneQuery Sentry connector makes observability context from Sentry available to AI agents through bounded source API calls for endpoint-specific context. Connect Sentry with a Personal Token, organization slug, optional project slug, and optional self-hosted API base URL. ### How do AI agents access Sentry through OneQuery? Agents call OneQuery instead of receiving raw Sentry credentials. OneQuery keeps credentials centralized, applies source boundaries, and records access in audit logs while exposing bounded source API calls for endpoint-specific context. ### How do I set up the Sentry connector? Prepare sentry credentials and connect Sentry from the OneQuery dashboard or CLI. Start with this setup step: Create a Sentry Personal Token with organization and project read scopes. Related connectors ## More observability sources [**Laminar** Connect Laminar with an API key and optional non-default base URL.](/connectors/laminar/)[**Cloudflare Workers Observability** Connect Cloudflare Workers Observability with an account-scoped API token and account ID.](/connectors/cloudflare-workers-observability/)[**MongoDB** Connect MongoDB with one connection string plus database selection.](/connectors/mongodb/) --- ## Source: https://onequery.dev/connectors/slack/ [Connectors](/connectors/) / Slack Productivity connector # Slack connector for governed AI agent access Connect Slack so agents can read channel and thread history and send messages where the installed app has access. API [Setup docs](/docs/guide/connect-source/)[All connectors](/connectors/) - Source Slack - Access model API - Setup surface Dashboard and CLI - Provider key `slack` Direct answer ## OneQuery supports Slack for governed agent access. Teams use the Slack connector to give AI agents bounded source API calls for endpoint-specific context while OneQuery keeps credentials centralized, limits access to approved sources, and preserves audit logs for review. Agent workflow ## What this connector enables Slack becomes an approved OneQuery source instead of a secret copied into an agent prompt, shell session, or model tool. The agent receives a governed access path, and the source credentials stay behind OneQuery. - Use bounded source API calls for endpoint-specific context for productivity context. - Keep Slack credentials centralized and out of agent runtimes. - Review agent access through OneQuery audit history instead of reconstructing direct service usage. Setup checklist ## Prepare the Slack connection Use slack credentials and connect the source through the Dashboard and CLI. Keep credentials scoped to the data the agent is allowed to read. 1. Authorize or install the Slack app for the target workspace. 2. Grant chat:write if agents should send messages. 3. Invite the app to any private channels the source should analyze or message. 4. Use channel IDs or channel names when reading Slack history or sending messages. FAQ ## Slack connector questions ### What is the OneQuery Slack connector? The OneQuery Slack connector makes productivity context from Slack available to AI agents through bounded source API calls for endpoint-specific context. Connect Slack so agents can read channel and thread history and send messages where the installed app has access. ### How do AI agents access Slack through OneQuery? Agents call OneQuery instead of receiving raw Slack credentials. OneQuery keeps credentials centralized, applies source boundaries, and records access in audit logs while exposing bounded source API calls for endpoint-specific context. ### How do I set up the Slack connector? Prepare slack credentials and connect Slack from the OneQuery dashboard or CLI. Start with this setup step: Authorize or install the Slack app for the target workspace. Related connectors ## More productivity sources [**Airtable** Connect Airtable with a Personal Access Token and optional default base ID.](/connectors/airtable/)[**Cal.com** Connect Cal.com API v2 with an API key or compatible bearer token.](/connectors/cal-com/)[**Granola** Connect Granola with an API key that has access to the note scopes you want to query.](/connectors/granola/) --- ## Source: https://onequery.dev/connectors/snowflake/ [Connectors](/connectors/) / Snowflake Warehouses connector # Snowflake connector for governed AI agent access Connect Snowflake with an account identifier, warehouse, database, and login credentials. Query [Setup docs](/docs/guide/connect-source/)[All connectors](/connectors/) - Source Snowflake - Access model Query - Setup surface Dashboard and CLI - Provider key `snowflake` Direct answer ## OneQuery supports Snowflake for governed agent access. Teams use the Snowflake connector to give AI agents SQL-style query workflows for structured data access while OneQuery keeps credentials centralized, limits access to approved sources, and preserves audit logs for review. Agent workflow ## What this connector enables Snowflake becomes an approved OneQuery source instead of a secret copied into an agent prompt, shell session, or model tool. The agent receives a governed access path, and the source credentials stay behind OneQuery. - Use SQL-style query workflows for structured data access for warehouses context. - Keep Snowflake credentials centralized and out of agent runtimes. - Review agent access through OneQuery audit history instead of reconstructing direct service usage. Setup checklist ## Prepare the Snowflake connection Use snowflake credentials and connect the source through the Dashboard and CLI. Keep credentials scoped to the data the agent is allowed to read. 1. Create or choose a Snowflake role with read access to the target database and schemas. 2. Grant the role USAGE on the warehouse, database, and schema plus SELECT on the tables or views OneQuery should query. 3. Copy the account identifier, username, password, warehouse, database, optional schema, and optional role into the payload. FAQ ## Snowflake connector questions ### What is the OneQuery Snowflake connector? The OneQuery Snowflake connector makes warehouses context from Snowflake available to AI agents through SQL-style query workflows for structured data access. Connect Snowflake with an account identifier, warehouse, database, and login credentials. ### How do AI agents access Snowflake through OneQuery? Agents call OneQuery instead of receiving raw Snowflake credentials. OneQuery keeps credentials centralized, applies source boundaries, and records access in audit logs while exposing SQL-style query workflows for structured data access. ### How do I set up the Snowflake connector? Prepare snowflake credentials and connect Snowflake from the OneQuery dashboard or CLI. Start with this setup step: Create or choose a Snowflake role with read access to the target database and schemas. Related connectors ## More warehouses sources [**BigQuery** Connect BigQuery with either Google OAuth tokens or a Google Cloud service account JSON key.](/connectors/bigquery/)[**Cloudflare D1** Connect Cloudflare D1 with an account ID, D1 database ID, and account-scoped API token.](/connectors/cloudflare-d1/)[**Cloudflare R2 SQL** Connect Cloudflare R2 SQL with an account ID, R2 bucket name, and API token for querying R2 Data Catalog Iceberg tables.](/connectors/cloudflare-r2-sql/) --- ## Source: https://onequery.dev/connectors/supabase/ [Connectors](/connectors/) / Supabase Databases connector # Supabase connector for governed AI agent access Connect Supabase with the session pooler host, database, and login credentials over the Postgres wire protocol. Query [Setup docs](/docs/guide/connect-source/)[All connectors](/connectors/) - Source Supabase - Access model Query - Setup surface Dashboard and CLI - Provider key `supabase` Direct answer ## OneQuery supports Supabase for governed agent access. Teams use the Supabase connector to give AI agents SQL-style query workflows for structured data access while OneQuery keeps credentials centralized, limits access to approved sources, and preserves audit logs for review. Agent workflow ## What this connector enables Supabase becomes an approved OneQuery source instead of a secret copied into an agent prompt, shell session, or model tool. The agent receives a governed access path, and the source credentials stay behind OneQuery. - Use SQL-style query workflows for structured data access for databases context. - Keep Supabase credentials centralized and out of agent runtimes. - Review agent access through OneQuery audit history instead of reconstructing direct service usage. Setup checklist ## Prepare the Supabase connection Use postgres credentials and connect the source through the Dashboard and CLI. Keep credentials scoped to the data the agent is allowed to read. 1. Open the Supabase Connect panel and retrieve the Session pooler host, database name, username, and password. 2. Use the Supabase provider with the Postgres connection fields shown below. 3. Prefer the Session pooler for OneQuery's persistent backend connection path. Keep SSL enabled and confirm the correct port before building the payload. FAQ ## Supabase connector questions ### What is the OneQuery Supabase connector? The OneQuery Supabase connector makes databases context from Supabase available to AI agents through SQL-style query workflows for structured data access. Connect Supabase with the session pooler host, database, and login credentials over the Postgres wire protocol. ### How do AI agents access Supabase through OneQuery? Agents call OneQuery instead of receiving raw Supabase credentials. OneQuery keeps credentials centralized, applies source boundaries, and records access in audit logs while exposing SQL-style query workflows for structured data access. ### How do I set up the Supabase connector? Prepare postgres credentials and connect Supabase from the OneQuery dashboard or CLI. Start with this setup step: Open the Supabase Connect panel and retrieve the Session pooler host, database name, username, and password. Related connectors ## More databases sources [**PostgreSQL** Connect a Postgres database with a direct host, database, and login.](/connectors/postgresql/)[**MySQL** Connect a MySQL database with host, schema, and login credentials.](/connectors/mysql/)[**MongoDB** Connect MongoDB with one connection string plus database selection.](/connectors/mongodb/) --- ## Source: https://onequery.dev/connectors/tiktok-marketing/ [Connectors](/connectors/) / TikTok Marketing Marketing connector # TikTok Marketing connector for governed AI agent access Connect TikTok Marketing API with an API for Business access token. API [Setup docs](/docs/guide/connect-source/)[All connectors](/connectors/) - Source TikTok Marketing - Access model API - Setup surface Dashboard and CLI - Provider key `tiktok_marketing` Direct answer ## OneQuery supports TikTok Marketing for governed agent access. Teams use the TikTok Marketing connector to give AI agents bounded source API calls for endpoint-specific context while OneQuery keeps credentials centralized, limits access to approved sources, and preserves audit logs for review. Agent workflow ## What this connector enables TikTok Marketing becomes an approved OneQuery source instead of a secret copied into an agent prompt, shell session, or model tool. The agent receives a governed access path, and the source credentials stay behind OneQuery. - Use bounded source API calls for endpoint-specific context for marketing context. - Keep TikTok Marketing credentials centralized and out of agent runtimes. - Review agent access through OneQuery audit history instead of reconstructing direct service usage. Setup checklist ## Prepare the TikTok Marketing connection Use tiktok marketing credentials and connect the source through the Dashboard and CLI. Keep credentials scoped to the data the agent is allowed to read. 1. Create or obtain a TikTok API for Business access token authorized for the advertiser accounts OneQuery should query. 2. Optionally include the common advertiser ID as \`credentials.advertiserId\`; endpoint calls can still pass advertiser IDs in request params. 3. Only include \`apiBaseUrl\` when you need a non-default TikTok Business API origin. FAQ ## TikTok Marketing connector questions ### What is the OneQuery TikTok Marketing connector? The OneQuery TikTok Marketing connector makes marketing context from TikTok Marketing available to AI agents through bounded source API calls for endpoint-specific context. Connect TikTok Marketing API with an API for Business access token. ### How do AI agents access TikTok Marketing through OneQuery? Agents call OneQuery instead of receiving raw TikTok Marketing credentials. OneQuery keeps credentials centralized, applies source boundaries, and records access in audit logs while exposing bounded source API calls for endpoint-specific context. ### How do I set up the TikTok Marketing connector? Prepare tiktok marketing credentials and connect TikTok Marketing from the OneQuery dashboard or CLI. Start with this setup step: Create or obtain a TikTok API for Business access token authorized for the advertiser accounts OneQuery should query. Related connectors ## More marketing sources [**Google Search Console** Connect Google Search Console with Google OAuth or an OAuth access token and optional default site URL.](/connectors/google-search-console/)[**Amazon Ads** Connect Amazon Ads with a Login with Amazon access token, client ID, region, and optional profile ID.](/connectors/amazon-ads/)[**LinkedIn Ads** Connect LinkedIn Ads with a Marketing API OAuth access token and version header.](/connectors/linkedin-ads/) --- ## Source: https://onequery.dev/connectors/vercel/ [Connectors](/connectors/) / Vercel Developer workflow connector # Vercel connector for governed AI agent access Connect Vercel with an API token for deployments, projects, teams, and runtime observability endpoints. API [Setup docs](/docs/guide/connect-source/)[All connectors](/connectors/) - Source Vercel - Access model API - Setup surface Dashboard and CLI - Provider key `vercel` Direct answer ## OneQuery supports Vercel for governed agent access. Teams use the Vercel connector to give AI agents bounded source API calls for endpoint-specific context while OneQuery keeps credentials centralized, limits access to approved sources, and preserves audit logs for review. Agent workflow ## What this connector enables Vercel becomes an approved OneQuery source instead of a secret copied into an agent prompt, shell session, or model tool. The agent receives a governed access path, and the source credentials stay behind OneQuery. - Use bounded source API calls for endpoint-specific context for developer workflow context. - Keep Vercel credentials centralized and out of agent runtimes. - Review agent access through OneQuery audit history instead of reconstructing direct service usage. Setup checklist ## Prepare the Vercel connection Use vercel credentials and connect the source through the Dashboard and CLI. Keep credentials scoped to the data the agent is allowed to read. 1. Create a Vercel API token with read access to the account or team OneQuery should inspect. 2. Copy the token into \`credentials.apiToken\`. 3. Use \`params\[teamId]\` in Source API requests when calling team-scoped Vercel endpoints. 4. Only include \`apiBaseUrl\` when you need a non-default Vercel-compatible API origin. FAQ ## Vercel connector questions ### What is the OneQuery Vercel connector? The OneQuery Vercel connector makes developer workflow context from Vercel available to AI agents through bounded source API calls for endpoint-specific context. Connect Vercel with an API token for deployments, projects, teams, and runtime observability endpoints. ### How do AI agents access Vercel through OneQuery? Agents call OneQuery instead of receiving raw Vercel credentials. OneQuery keeps credentials centralized, applies source boundaries, and records access in audit logs while exposing bounded source API calls for endpoint-specific context. ### How do I set up the Vercel connector? Prepare vercel credentials and connect Vercel from the OneQuery dashboard or CLI. Start with this setup step: Create a Vercel API token with read access to the account or team OneQuery should inspect. Related connectors ## More developer workflow sources [**Codex App Server API** Connect the OpenAI-compatible Codex App Server API without exposing its API key to the caller.](/connectors/codex-app-server-api/)[**GitHub** Connect GitHub with a fine-grained personal access token and optional repository or installation scoping.](/connectors/github/)[**Figma** Connect Figma with a personal access token for read-only REST API and grouped design-context access.](/connectors/figma/) --- ## Source: https://onequery.dev/connectors/youtube-analytics/ [Connectors](/connectors/) / YouTube Analytics Product analytics connector # YouTube Analytics connector for governed AI agent access Connect YouTube Analytics with Google OAuth tokens that can read YouTube Analytics reports. API [Setup docs](/docs/guide/connect-source/)[All connectors](/connectors/) - Source YouTube Analytics - Access model API - Setup surface Dashboard and CLI - Provider key `youtube_analytics` Direct answer ## OneQuery supports YouTube Analytics for governed agent access. Teams use the YouTube Analytics connector to give AI agents bounded source API calls for endpoint-specific context while OneQuery keeps credentials centralized, limits access to approved sources, and preserves audit logs for review. Agent workflow ## What this connector enables YouTube Analytics becomes an approved OneQuery source instead of a secret copied into an agent prompt, shell session, or model tool. The agent receives a governed access path, and the source credentials stay behind OneQuery. - Use bounded source API calls for endpoint-specific context for product analytics context. - Keep YouTube Analytics credentials centralized and out of agent runtimes. - Review agent access through OneQuery audit history instead of reconstructing direct service usage. Setup checklist ## Prepare the YouTube Analytics connection Use youtube analytics credentials and connect the source through the Dashboard and CLI. Keep credentials scoped to the data the agent is allowed to read. 1. Enable the YouTube Analytics API in the Google Cloud project used for OAuth. 2. Authorize a Google account that owns or manages the YouTube channel or content owner data you need to analyze. 3. Use the \`https\://www\.googleapis.com/auth/youtube.readonly\` and \`https\://www\.googleapis.com/auth/yt-analytics.readonly\` scopes for non-monetary metrics. Revenue and ad performance metrics require \`https\://www\.googleapis.com/auth/yt-analytics-monetary.readonly\`. 4. Call \`/reports\` through Source API with query params such as \`ids\`, \`startDate\`, \`endDate\`, \`metrics\`, \`dimensions\`, and \`filters\`. FAQ ## YouTube Analytics connector questions ### What is the OneQuery YouTube Analytics connector? The OneQuery YouTube Analytics connector makes product analytics context from YouTube Analytics available to AI agents through bounded source API calls for endpoint-specific context. Connect YouTube Analytics with Google OAuth tokens that can read YouTube Analytics reports. ### How do AI agents access YouTube Analytics through OneQuery? Agents call OneQuery instead of receiving raw YouTube Analytics credentials. OneQuery keeps credentials centralized, applies source boundaries, and records access in audit logs while exposing bounded source API calls for endpoint-specific context. ### How do I set up the YouTube Analytics connector? Prepare youtube analytics credentials and connect YouTube Analytics from the OneQuery dashboard or CLI. Start with this setup step: Enable the YouTube Analytics API in the Google Cloud project used for OAuth. Related connectors ## More product analytics sources [**Google Analytics** Connect Google Analytics with either Google OAuth tokens or a Google Cloud service account JSON key.](/connectors/google-analytics/)[**Amplitude** Connect Amplitude with a project API key, secret key, and region.](/connectors/amplitude/)[**Mixpanel** Connect Mixpanel with an org-level service account, project ID, and region.](/connectors/mixpanel/) --- ## Source: https://onequery.dev/docs/concepts/ # Concepts OneQuery keeps production credentials behind a governed interface. Callers use source identifiers; OneQuery handles credentials, limits, execution, and audit history. The mental model is: ``` caller -> source identifier -> OneQuery gateway -> provider -> bounded result ``` [Governed access](/docs/concepts/governed-access/)How OneQuery separates agents from credentials and production authority. [Source identifiers](/docs/concepts/source-identifiers/)How connected sources become addresses like postgres\://warehouse. [Query boundaries](/docs/concepts/query-boundaries/)What OneQuery validates and limits before a query reaches a source. [Audit history](/docs/concepts/audit-history/)What operators should expect to review after a query or API request runs. [Edit page](https://github.com/wordbricks/onequery/edit/main/apps/landing/src/content/docs/docs/concepts/index.mdx) [Previous\ Getting Started](/docs/getting-started/)[Next\ Governed Access](/docs/concepts/governed-access/) --- ## Source: https://onequery.dev/docs/concepts/audit-history/ # Audit History Audit history is the record operators use after a human or agent asks OneQuery for production context. It should show which source was used, which command or API path was requested, who initiated it, and when it happened. ## What to Capture [Section titled “What to Capture”](#what-to-capture) For each production-facing operation, expect enough detail to answer: - Who or what initiated the request? - Which organization and source were used? - Which query, endpoint, or operation ran? - Did the request succeed, fail, or get blocked? - What limits or validations were applied? - When did it happen? ## Evidence Over Guesswork [Section titled “Evidence Over Guesswork”](#evidence-over-guesswork) Audit records are part of the operational loop. They let a team confirm that an agent used approved evidence instead of guessing from stale logs, screenshots, or copied credentials. When a production change follows an agent run, link the change back to the OneQuery source and operation that supplied the evidence. Use [Audit review](/docs/operations/audit-review/) for the operational checklist. [Edit page](https://github.com/wordbricks/onequery/edit/main/apps/landing/src/content/docs/docs/concepts/audit-history.mdx) [Previous\ Query Boundaries](/docs/concepts/query-boundaries/)[Next\ Overview](/docs/guide/) --- ## Source: https://onequery.dev/docs/concepts/governed-access/ # Governed Access Governed access means the caller does not receive the raw credential for the production system. The caller receives a controlled interface to a named source. For an agent, this distinction is the product boundary. The agent can ask for relevant production context, but OneQuery still owns source resolution, credential handling, validation, result limits, and audit records. ## What Stays Outside the Agent [Section titled “What Stays Outside the Agent”](#what-stays-outside-the-agent) - Database passwords and SaaS API tokens. - Provider-specific authentication flows. - Source connection metadata that is not needed for the task. - Server-side validation and execution behavior. - Audit storage. ## What the Agent Receives [Section titled “What the Agent Receives”](#what-the-agent-receives) - A source identifier such as `postgres://warehouse` or `github://github_main`. - A command surface such as `onequery query exec` or `onequery api`. - A bounded result set or provider response. - Clear failure output when a request is blocked, invalid, or unavailable. ## Production Rule [Section titled “Production Rule”](#production-rule) Treat OneQuery as the only path from agent tools to production data. Do not place the same database password, SaaS token, or cloud credential directly in the agent environment. ## Rollout Pattern [Section titled “Rollout Pattern”](#rollout-pattern) 1. Connect one low-risk read-only source. 2. Verify a few human-run commands from the CLI. 3. Give the agent only the source identifier and command pattern it needs. 4. Review audit history after the first automated runs. 5. Expand sources only after the operator workflow is clear. [Edit page](https://github.com/wordbricks/onequery/edit/main/apps/landing/src/content/docs/docs/concepts/governed-access.mdx) [Previous\ Overview](/docs/concepts/)[Next\ Source Identifiers](/docs/concepts/source-identifiers/) --- ## Source: https://onequery.dev/docs/concepts/query-boundaries/ # Query Boundaries OneQuery should be used as a bounded execution path, not as a credential transport. The boundary is useful because it gives operators a place to enforce deterministic behavior before a request reaches the data source. ## SQL Query Boundary [Section titled “SQL Query Boundary”](#sql-query-boundary) For SQL-oriented sources, OneQuery is designed around read-only execution. A production query should be narrow, inspectable, and bounded. The expected safeguards are: - Read-only query validation. - Single-statement execution. - Source-specific timeout or cost controls where the provider supports them. - Result windows that keep responses usable for humans and agents. - Audit records that show the source and operation. ## Source API Boundary [Section titled “Source API Boundary”](#source-api-boundary) Source API integrations call provider APIs such as GitHub, Sentry, Vercel, Cloudflare, and analytics systems. The credential you connect determines what the provider will allow, so the upstream token or account should still be scoped as tightly as possible. Use read-only provider tokens for agent-facing sources whenever the provider supports them. ## Prompt Rules Are Not Boundaries [Section titled “Prompt Rules Are Not Boundaries”](#prompt-rules-are-not-boundaries) Instructions like “only read production data” are useful guidance, but they are not an access control layer. The OneQuery boundary should be the enforcement point. Agent prompts should describe how to use OneQuery, while credentials and provider permissions stay outside the prompt. ## Blocked Requests [Section titled “Blocked Requests”](#blocked-requests) A blocked request should be treated as a useful signal. It usually means one of these is true: - The agent asked for a write or multi-step operation that is outside the allowed shape. - The source identifier is wrong. - The connected credential does not have provider access. - The query is too broad for the configured limits. Use the failure output to revise the query or source setup instead of giving the agent a broader credential. [Edit page](https://github.com/wordbricks/onequery/edit/main/apps/landing/src/content/docs/docs/concepts/query-boundaries.mdx) [Previous\ Source Identifiers](/docs/concepts/source-identifiers/)[Next\ Audit History](/docs/concepts/audit-history/) --- ## Source: https://onequery.dev/docs/concepts/source-identifiers/ # Source Identifiers Connected sources are addressed as: ``` :// ``` The provider ID is the integration type. The local name is the `sourceKey` value you choose during setup. ## Examples [Section titled “Examples”](#examples) | Identifier | Meaning | | --- | --- | | `postgres://warehouse` | PostgreSQL connection `warehouse`. | | `snowflake://analytics_prod` | Snowflake connection `analytics_prod`. | | `github://github_main` | GitHub connection `github_main`. | | `sentry://sentry_prod` | Sentry connection `sentry_prod`. | | `cloudflare_workers_observability://cloudflare_workers` | Cloudflare Workers Observability connection `cloudflare_workers`. | ## Naming [Section titled “Naming”](#naming) Choose stable names. Use environment-specific names like `warehouse_prod` or `sentry_checkout_prod` when ambiguity would be risky. ## Usage [Section titled “Usage”](#usage) Terminal window ``` onequery query exec --source postgres://warehouse --sql "select 1" onequery api --source github://github_main /repos/acme/web/pulls --json ``` Some providers support SQL queries; others expose provider API calls. See [integrations](/docs/integrations/) for provider families. [Edit page](https://github.com/wordbricks/onequery/edit/main/apps/landing/src/content/docs/docs/concepts/source-identifiers.mdx) [Previous\ Governed Access](/docs/concepts/governed-access/)[Next\ Query Boundaries](/docs/concepts/query-boundaries/) --- ## Source: https://onequery.dev/docs/examples/ # Examples These examples show how to combine source identifiers, narrow requests, and audit-friendly investigation notes. [Production debugging](/docs/examples/production-debugging/)Use Sentry, Cloudflare, and code context without raw production tokens. [Read-only warehouse review](/docs/examples/warehouse-readonly/)Ask bounded analytics questions with aggregate-first warehouse queries. [Release review](/docs/examples/release-review/)Connect GitHub, deployments, and incident evidence around a release. [Incident triage](/docs/examples/incident-triage/)Give an agent a controlled evidence loop during an outage. [Analytics investigation](/docs/examples/analytics-investigation/)Inspect product analytics changes while keeping provider tokens centralized. ## Example Format [Section titled “Example Format”](#example-format) Each example uses the same shape: 1. Define the allowed sources. 2. Run a narrow query or API request. 3. Summarize evidence. 4. Decide the next bounded request. 5. Preserve the source identifiers in notes and changes. [Edit page](https://github.com/wordbricks/onequery/edit/main/apps/landing/src/content/docs/docs/examples/index.mdx) [Previous\ Marketing and Productivity](/docs/integrations/marketing-productivity/)[Next\ Production Debugging](/docs/examples/production-debugging/) --- ## Source: https://onequery.dev/docs/examples/analytics-investigation/ # Analytics Investigation Analytics investigations often require more than one source. OneQuery lets an agent compare product analytics, traffic data, and deploy history through named sources. ## Allowed Sources [Section titled “Allowed Sources”](#allowed-sources) ``` posthog://posthog_main ga://ga_marketing github://github_main ``` ## Product Event Check [Section titled “Product Event Check”](#product-event-check) Terminal window ``` onequery api \ --source posthog://posthog_main \ /api/projects/12345/events/ \ --json ``` ## Traffic Check [Section titled “Traffic Check”](#traffic-check) Terminal window ``` onequery api \ --source ga://ga_marketing \ /v1beta/properties/123456789:runReport \ --json ``` ## Investigation Rules [Section titled “Investigation Rules”](#investigation-rules) - Use exact date ranges. - Ask for aggregate dimensions first. - Compare analytics changes with release history. - Avoid exporting user-level rows unless an operator approves the need. - Keep the source identifiers in the final summary. [Edit page](https://github.com/wordbricks/onequery/edit/main/apps/landing/src/content/docs/docs/examples/analytics-investigation.mdx) [Previous\ Incident Triage](/docs/examples/incident-triage/)[Next\ Overview](/docs/operations/) --- ## Source: https://onequery.dev/docs/examples/incident-triage/ # Incident Triage During an incident, avoid expanding agent access out of urgency. Give the agent a small source set and require concise evidence summaries between requests. ## Incident Prompt [Section titled “Incident Prompt”](#incident-prompt) ``` We have elevated API errors. Use only OneQuery sources sentry://sentry_prod, cloudflare_workers_observability://cloudflare_workers, and github://github_main. Use a 60-minute window unless evidence requires a smaller window. Do not suggest a production change until you summarize source-backed evidence. ``` ## First Requests [Section titled “First Requests”](#first-requests) Ask the agent for three short facts before it inspects code: 1. First-seen time and affected service from observability. 2. Current error shape and whether it is still increasing. 3. Recent deploy, configuration, or dependency changes near the first-seen time. ## Triage Loop [Section titled “Triage Loop”](#triage-loop) 1. Narrow the time window. 2. Compare error evidence with release or configuration evidence. 3. State the most likely failure mode and the source identifiers behind it. 4. Propose a mitigation only after the evidence summary is reviewed. ## Stop Conditions [Section titled “Stop Conditions”](#stop-conditions) Stop and involve an operator when: - The agent asks for a raw credential. - The investigation requires write access to a provider. - Evidence conflicts across sources. - The proposed fix affects authentication, billing, security controls, or data deletion. [Edit page](https://github.com/wordbricks/onequery/edit/main/apps/landing/src/content/docs/docs/examples/incident-triage.mdx) [Previous\ Release Review](/docs/examples/release-review/)[Next\ Analytics Investigation](/docs/examples/analytics-investigation/) --- ## Source: https://onequery.dev/docs/examples/production-debugging/ # Production Debugging This example gives an agent access to approved observability and repository sources during a production investigation. ## Allowed Sources [Section titled “Allowed Sources”](#allowed-sources) ``` sentry://sentry_prod cloudflare_workers_observability://cloudflare_workers github://github_main ``` ## Prompt [Section titled “Prompt”](#prompt) ``` Investigate the failing scheduled job. Use OneQuery for production evidence. Allowed sources are sentry://sentry_prod, cloudflare_workers_observability://cloudflare_workers, and github://github_main. Use narrow time windows. Summarize evidence before editing code. ``` ## Start With Open Errors [Section titled “Start With Open Errors”](#start-with-open-errors) Terminal window ``` onequery api \ --source sentry://sentry_prod \ /organizations/acme/issues/ \ -f 'params[query]=is:unresolved' \ --json ``` ## Inspect Recent Commits [Section titled “Inspect Recent Commits”](#inspect-recent-commits) Terminal window ``` onequery api \ --source github://github_main \ /repos/acme/web/commits?sha=main \ --json ``` ## Evidence Summary [Section titled “Evidence Summary”](#evidence-summary) Ask the agent to produce a summary like: ``` Evidence: - sentry://sentry_prod shows issue WEB-123 started after 2026-05-30 09:10 UTC. - github://github_main shows commit abc123 changed the retry window in the scheduled job. - cloudflare_workers_observability://cloudflare_workers shows failures only on scheduled runs, not manual runs. Next step: inspect scheduler retry policy in src/jobs. ``` The summary should name the sources so a reviewer can match the claim to audit history. [Edit page](https://github.com/wordbricks/onequery/edit/main/apps/landing/src/content/docs/docs/examples/production-debugging.mdx) [Previous\ Overview](/docs/examples/)[Next\ Read-Only Warehouse Review](/docs/examples/warehouse-readonly/) --- ## Source: https://onequery.dev/docs/examples/release-review/ # Release Review Release review is a good fit for Source API integrations. The agent can compare repository activity, deployment metadata, and observability signals without receiving provider tokens. ## Allowed Sources [Section titled “Allowed Sources”](#allowed-sources) ``` github://github_main vercel://vercel_main sentry://sentry_prod ``` ## Pull Requests [Section titled “Pull Requests”](#pull-requests) Terminal window ``` onequery api \ --source github://github_main \ /repos/acme/web/pulls?state=closed \ --paginate \ --max-pages 1 \ --jq '.[] | {number,title,merged_at,user}' \ --json ``` ## Deployments [Section titled “Deployments”](#deployments) Terminal window ``` onequery api \ --source vercel://vercel_main \ /v6/deployments \ --json ``` ## Open Production Issues [Section titled “Open Production Issues”](#open-production-issues) Terminal window ``` onequery api \ --source sentry://sentry_prod \ /organizations/acme/issues/ \ -f 'params[query]=is:unresolved' \ --json ``` ## Review Output [Section titled “Review Output”](#review-output) Ask the agent to separate facts from recommendations: ``` Facts: - github://github_main: PR #418 merged at 16:42 UTC and touched checkout retry behavior. - vercel://vercel_main: deployment dpl_123 promoted at 16:49 UTC. - sentry://sentry_prod: checkout errors increased after 16:53 UTC. Recommendation: - Inspect retry behavior and payment provider response handling before rolling back. ``` [Edit page](https://github.com/wordbricks/onequery/edit/main/apps/landing/src/content/docs/docs/examples/release-review.mdx) [Previous\ Read-Only Warehouse Review](/docs/examples/warehouse-readonly/)[Next\ Incident Triage](/docs/examples/incident-triage/) --- ## Source: https://onequery.dev/docs/examples/warehouse-readonly/ # Read-Only Warehouse Review Warehouse investigations should start broad and aggregate, then narrow only when needed. ## Allowed Source [Section titled “Allowed Source”](#allowed-source) ``` snowflake://analytics_prod ``` ## Aggregate First [Section titled “Aggregate First”](#aggregate-first) Terminal window ``` onequery query exec \ --source snowflake://analytics_prod \ --sql "select event_name, count(*) as events from analytics.events where event_date >= current_date - 7 group by event_name order by events desc limit 20" ``` ## Narrow by Time Window [Section titled “Narrow by Time Window”](#narrow-by-time-window) Terminal window ``` onequery query exec \ --source snowflake://analytics_prod \ --sql "select date_trunc('hour', occurred_at) as hour, count(*) as failures from analytics.events where event_name = 'checkout_failed' and occurred_at >= current_timestamp - interval '24 hours' group by 1 order by 1" ``` ## Review Rules [Section titled “Review Rules”](#review-rules) - Do not start with raw event dumps. - Keep time windows explicit. - Preserve the source identifier in the analysis. - Use a read-only warehouse role. - Prefer saved views for sensitive data. ## Result Note [Section titled “Result Note”](#result-note) ``` Source: snowflake://analytics_prod Window: last 24 hours Finding: checkout_failed increased after 14:00 UTC, concentrated in payment_method='card'. Follow-up: compare deployment and provider incident timelines. ``` [Edit page](https://github.com/wordbricks/onequery/edit/main/apps/landing/src/content/docs/docs/examples/warehouse-readonly.mdx) [Previous\ Production Debugging](/docs/examples/production-debugging/)[Next\ Release Review](/docs/examples/release-review/) --- ## Source: https://onequery.dev/docs/guide/ # Guide Task guides for setup, querying, provider APIs, and agent access. New users should start with [Getting started](/docs/getting-started/). [Install the CLI](/docs/guide/install-cli/)Choose npm, Homebrew, Bun, the install script, or direct npx usage. [Choose server path](/docs/guide/start-gateway/)Use a shared OneQuery server or run and inspect a local gateway. [Connect a source](/docs/guide/connect-source/)Create named source connections with provider-specific credentials. [Run a query](/docs/guide/run-query/)Execute a read-only SQL query through a source identifier. [Use Source API](/docs/guide/source-api/)Call provider APIs through OneQuery without handing tokens to agents. [Agent workflows](/docs/guide/agent-workflows/)Expose a narrow OneQuery command surface to coding agents and automation. [Agent tool setup](/docs/guide/agent-tool-setup/)Copy bounded OneQuery instructions into agent and automation environments. [Edit page](https://github.com/wordbricks/onequery/edit/main/apps/landing/src/content/docs/docs/guide/index.mdx) [Previous\ Audit History](/docs/concepts/audit-history/)[Next\ Install the CLI](/docs/guide/install-cli/) --- ## Source: https://onequery.dev/docs/guide/agent-tool-setup/ # Agent Tool Setup Use this page when adding OneQuery instructions to a coding agent, CI assistant, or local automation tool. | Source type | Allowed shape | | --- | --- | | SQL source | `onequery query exec --source :// --sql ""` | | Provider API source | `onequery api --source :// --json` | ## Minimal Agent Instruction [Section titled “Minimal Agent Instruction”](#minimal-agent-instruction) ``` Use OneQuery for production context. Do not ask for or use raw provider credentials. Allowed sources: - postgres://warehouse_prod - sentry://sentry_prod - github://github_main Use read-only queries, exact source identifiers, explicit time windows, and small result limits. Summarize source-backed evidence before editing code or recommending a production change. ``` ## AGENTS.md [Section titled “AGENTS.md”](#agentsmd) ``` ## Production Evidence Use OneQuery for production evidence. - Do not request raw database credentials, SaaS tokens, or cloud keys. - Use only the source identifiers listed in the task. - Use `onequery query exec --source :// --sql ""` for SQL sources. - Use `onequery api --source :// --json` for provider API sources. - Keep queries read-only and bounded. - Summarize evidence with the source identifier before changing code. ``` ## Smoke Test [Section titled “Smoke Test”](#smoke-test) Terminal window ``` onequery auth whoami onequery source list onequery query exec --source postgres://warehouse_prod --sql "select 1" ``` [Edit page](https://github.com/wordbricks/onequery/edit/main/apps/landing/src/content/docs/docs/guide/agent-tool-setup.mdx) [Previous\ Agent Workflows](/docs/guide/agent-workflows/)[Next\ Overview](/docs/integrations/) --- ## Source: https://onequery.dev/docs/guide/agent-workflows/ # Agent Workflows Agents need context, but they should not receive the original production credential. Give the agent a narrow OneQuery command surface and a task-specific list of approved source identifiers. ## Command Surface [Section titled “Command Surface”](#command-surface) Terminal window ``` onequery query exec \ --source \ --sql "" ``` Terminal window ``` onequery api \ --source \ \ --json ``` Use [Run a query](/docs/guide/run-query/) for SQL examples and [Source API](/docs/guide/source-api/) for provider API examples. ## Guardrails [Section titled “Guardrails”](#guardrails) - Give the agent only the source identifiers needed for the task. - Require bounded queries and an evidence summary before production recommendations. - Review audit history after the first run against a new source. Use [Agent tool setup](/docs/guide/agent-tool-setup/) for copy-paste instructions and `AGENTS.md` snippets. ## Example Workflow [Section titled “Example Workflow”](#example-workflow) 1. The operator asks the agent to investigate an incident. 2. The agent queries Sentry and logs through OneQuery. 3. The agent narrows evidence to a source, endpoint, and failure window. 4. The agent inspects code locally. 5. The agent proposes a patch with a short production evidence summary. 6. The operator reviews the diff and the OneQuery audit trail. [Edit page](https://github.com/wordbricks/onequery/edit/main/apps/landing/src/content/docs/docs/guide/agent-workflows.mdx) [Previous\ Use Source API](/docs/guide/source-api/)[Next\ Agent Tool Setup](/docs/guide/agent-tool-setup/) --- ## Source: https://onequery.dev/docs/guide/connect-source/ # Connect a Source A source is a named connection to a provider. `--source postgres` plus `"sourceKey": "warehouse"` creates the identifier `postgres://warehouse`. ## Basic Flow [Section titled “Basic Flow”](#basic-flow) 1. Pick the provider. Terminal window ``` onequery source connect --help ``` 2. Ask for provider-specific setup guidance. Terminal window ``` onequery source connect --source postgres ``` 3. Build the input payload with a read-only credential. ``` { "sourceKey": "warehouse", "credentials": { "host": "db.example.com", "port": 5432, "database": "app", "username": "onequery_readonly", "password": "", "sslMode": "require" } } ``` 4. Connect the source. Terminal window ``` onequery source connect --source postgres \ --input '{"sourceKey":"warehouse","credentials":{"host":"db.example.com","port":5432,"database":"app","username":"onequery_readonly","password":"","sslMode":"require"}}' ``` 5. Confirm the source appears. Terminal window ``` onequery source list ``` ## Credential Guidance [Section titled “Credential Guidance”](#credential-guidance) - Prefer read-only users or provider tokens. - Create separate OneQuery sources for production, staging, and customer data. - Rotate provider credentials outside the agent runtime. - Do not paste source credentials into prompts or task descriptions. ## Provider Families [Section titled “Provider Families”](#provider-families) Use the integration pages for provider-specific patterns: - [Databases](/docs/integrations/databases/) - [Warehouses](/docs/integrations/warehouses/) - [Observability](/docs/integrations/observability/) - [Developer tools](/docs/integrations/developer-tools/) - [Product analytics](/docs/integrations/product-analytics/) [Edit page](https://github.com/wordbricks/onequery/edit/main/apps/landing/src/content/docs/docs/guide/connect-source.mdx) [Previous\ Choose Server Path](/docs/guide/start-gateway/)[Next\ Run a Query](/docs/guide/run-query/) --- ## Source: https://onequery.dev/docs/guide/install-cli/ # Install the CLI The CLI is the main local surface for setup and source access. ## Install Options [Section titled “Install Options”](#install-options) - [npm](#tab-panel-4) - [Homebrew](#tab-panel-5) - [Bun](#tab-panel-6) - [Script](#tab-panel-7) Terminal window ``` npm install -g @onequery/cli ``` Terminal window ``` brew install wordbricks/tap/onequery ``` Terminal window ``` bun add -g @onequery/cli ``` Terminal window ``` curl -fsSL https://onequery.dev/install.sh | sh ``` ## Run Without Installing Globally [Section titled “Run Without Installing Globally”](#run-without-installing-globally) Terminal window ``` npx @onequery/cli --help ``` ## Verify [Section titled “Verify”](#verify) Terminal window ``` onequery --version onequery --help ``` ## Auth [Section titled “Auth”](#auth) Terminal window ``` onequery auth login onequery auth whoami ``` ## CLI State [Section titled “CLI State”](#cli-state) The CLI stores the default auth session and config under `~/.onequery/`. Set `ONEQUERY_HOME` when you need an isolated state directory for a test environment or agent runtime. Named profiles keep separate state: Terminal window ``` onequery --profile work auth login ONEQUERY_PROFILE=work onequery auth whoami ``` Use profiles for separate production, staging, or customer environments. [Edit page](https://github.com/wordbricks/onequery/edit/main/apps/landing/src/content/docs/docs/guide/install-cli.mdx) [Previous\ Overview](/docs/guide/)[Next\ Choose Server Path](/docs/guide/start-gateway/) --- ## Source: https://onequery.dev/docs/guide/run-query/ # Run a Query Use this page after `onequery source list` shows the source you connected. ## Confirm Context [Section titled “Confirm Context”](#confirm-context) Terminal window ``` onequery config get api.server_url onequery auth whoami onequery source list ``` ## Execute a Smoke Query [Section titled “Execute a Smoke Query”](#execute-a-smoke-query) Terminal window ``` onequery query exec --source postgres://warehouse --sql "select 1" ``` ## Query Application Data [Section titled “Query Application Data”](#query-application-data) Terminal window ``` onequery query exec \ --source postgres://warehouse \ --sql "select id, email, created_at from users order by created_at desc limit 20" ``` ## Warehouse Example [Section titled “Warehouse Example”](#warehouse-example) Terminal window ``` onequery query exec \ --source snowflake://analytics_prod \ --sql "select count(*) as events from analytics.events where event_date >= current_date - 1" ``` ## Query Rules [Section titled “Query Rules”](#query-rules) - Keep queries read-only. - Ask for the smallest result set needed. - Use explicit columns instead of `select *` for agent workflows. - Include time windows for logs, events, and analytics tables. - Prefer source-specific read replicas or service users for production data. ## When a Query Fails [Section titled “When a Query Fails”](#when-a-query-fails) Check these in order: 1. Confirm the source exists: `onequery source list`. 2. Confirm the CLI is pointed at the expected server: `onequery config get api.server_url`. 3. Confirm your session and organization: `onequery auth whoami`. 4. Retry the smoke query: `onequery query exec --source postgres://warehouse --sql "select 1"`. 5. Check that the SQL is read-only and valid for the provider dialect. [Edit page](https://github.com/wordbricks/onequery/edit/main/apps/landing/src/content/docs/docs/guide/run-query.mdx) [Previous\ Connect a Source](/docs/guide/connect-source/)[Next\ Use Source API](/docs/guide/source-api/) --- ## Source: https://onequery.dev/docs/guide/source-api/ # Use Source API Source API is the path for integrations where the useful operation is a provider API call instead of SQL. GitHub, Sentry, Vercel, Cloudflare, and analytics systems are common examples. ## Basic Shape [Section titled “Basic Shape”](#basic-shape) Terminal window ``` onequery api --source github://github_main /repos/acme/web/pulls --json ``` The source identifier selects the connected credential. The path selects the provider endpoint. ## GitHub Pull Requests [Section titled “GitHub Pull Requests”](#github-pull-requests) Terminal window ``` onequery api \ --source github://github_main \ /repos/acme/web/pulls \ --paginate \ --max-pages 2 \ --jq '.[] | {number,title,user,head,base}' \ --json ``` ## Sentry Issues [Section titled “Sentry Issues”](#sentry-issues) Terminal window ``` onequery api \ --source sentry://sentry_prod \ /organizations/acme/issues/ \ -f 'params[query]=is:unresolved' \ --json ``` ## Cloudflare Workers Observability [Section titled “Cloudflare Workers Observability”](#cloudflare-workers-observability) Terminal window ``` onequery api \ --source cloudflare_workers_observability://cloudflare_workers \ /accounts/{account_id}/workers/observability/telemetry \ --json ``` Replace provider path parameters with the values required by the provider API or the connected source configuration. ## Source API Rules [Section titled “Source API Rules”](#source-api-rules) - Scope provider tokens to read-only permissions when possible. - Prefer endpoint-specific commands in agent instructions. - Use pagination limits for list endpoints. - Use `--jq` to reduce large provider responses before the agent reads them. - Keep write-capable provider tokens out of agent-facing sources unless an operator has explicitly approved that workflow. [Edit page](https://github.com/wordbricks/onequery/edit/main/apps/landing/src/content/docs/docs/guide/source-api.mdx) [Previous\ Run a Query](/docs/guide/run-query/)[Next\ Agent Workflows](/docs/guide/agent-workflows/) --- ## Source: https://onequery.dev/docs/guide/start-gateway/ # Choose Server Path OneQuery commands need a server path. Use a shared or hosted server URL when your team provides one. Start a local gateway only when you operate OneQuery yourself. ## Shared or Hosted Server [Section titled “Shared or Hosted Server”](#shared-or-hosted-server) Terminal window ``` onequery config set api.server_url https://onequery.example.com onequery config get api.server_url onequery auth login ``` Use this when your team has a shared OneQuery deployment and you do not need a local gateway. ## Start in the Background [Section titled “Start in the Background”](#start-in-the-background) Terminal window ``` onequery gateway start ``` Use this when the shell should return after startup. ## Run in the Foreground [Section titled “Run in the Foreground”](#run-in-the-foreground) Terminal window ``` onequery gateway ``` Use this when a process manager owns the lifecycle or you want logs in the terminal. ## Inspect Status [Section titled “Inspect Status”](#inspect-status) Terminal window ``` onequery gateway status onequery gateway logs ``` ## Stop [Section titled “Stop”](#stop) Terminal window ``` onequery gateway stop ``` For deeper operations detail, see [Self-host OneQuery](/docs/operations/self-host/). [Edit page](https://github.com/wordbricks/onequery/edit/main/apps/landing/src/content/docs/docs/guide/start-gateway.mdx) [Previous\ Install the CLI](/docs/guide/install-cli/)[Next\ Connect a Source](/docs/guide/connect-source/) --- ## Source: https://onequery.dev/docs/integrations/ # Integrations OneQuery integrations become named sources. Each source has a provider, a local name, credential metadata, and one or more interfaces. [Databases](/docs/integrations/databases/)PostgreSQL, Supabase, MySQL, and MongoDB setup patterns. [Warehouses](/docs/integrations/warehouses/)Snowflake, BigQuery, AWS Athena Connector, and MotherDuck setup patterns. [Observability](/docs/integrations/observability/)Sentry, Laminar, and Cloudflare Workers Observability for incident evidence. [Developer tools](/docs/integrations/developer-tools/)GitHub, Linear, Jira, Confluence, Vercel, Discord, and 1Password access patterns. [Product analytics](/docs/integrations/product-analytics/)Google Analytics, Amplitude, Mixpanel, PostHog, Clarity, and Cloudflare Web Analytics. [Marketing and productivity](/docs/integrations/marketing-productivity/)Airtable, Cal.com, Granola, Amazon Ads, LinkedIn Ads, TikTok Marketing, SendGrid, and Search Console. ## Interfaces [Section titled “Interfaces”](#interfaces) OneQuery sources commonly expose one of two access patterns. | Interface | Use it for | | --- | --- | | Query | SQL-oriented sources such as databases and warehouses. | | Source API | Provider APIs such as GitHub pull requests, Sentry issues, or product analytics endpoints. | Some provider credentials can be used from the dashboard and the CLI. Others are CLI-first because their setup or workflow is more specialized. ## Provider-Specific Guides [Section titled “Provider-Specific Guides”](#provider-specific-guides) Run a provider guide command before connecting a new source: Terminal window ``` onequery source connect --source postgres ``` Replace `postgres` with the provider ID you plan to connect. The provider guide shows the expected credential shape and an example input payload. Use [source identifiers](/docs/concepts/source-identifiers/) in agent instructions and runbooks after a source is connected. [Edit page](https://github.com/wordbricks/onequery/edit/main/apps/landing/src/content/docs/docs/integrations/index.mdx) [Previous\ Agent Tool Setup](/docs/guide/agent-tool-setup/)[Next\ Databases](/docs/integrations/databases/) --- ## Source: https://onequery.dev/docs/integrations/databases/ # Databases Database providers cover both SQL databases and document databases. SQL providers use `onequery query exec`; MongoDB uses the Source API path. ## Supported Database Patterns [Section titled “Supported Database Patterns”](#supported-database-patterns) | Provider | Provider ID | Connection notes | | --- | --- | --- | | PostgreSQL | `postgres` | Host, port, database, username, password, and SSL mode. | | Supabase | `supabase` | Uses the Postgres wire protocol, typically through the Supabase session pooler. | | MySQL | `mysql` | Host, port, database, username, password, and SSL mode. | | MongoDB | `mongodb` | Connection string plus database selection. | ## PostgreSQL Example [Section titled “PostgreSQL Example”](#postgresql-example) Terminal window ``` onequery source connect --source postgres \ --input '{"sourceKey":"warehouse","credentials":{"host":"db.example.com","port":5432,"database":"app","username":"onequery_readonly","password":"","sslMode":"require"}}' ``` Run a query: Terminal window ``` onequery query exec \ --source postgres://warehouse \ --sql "select id, created_at from users order by created_at desc limit 20" ``` ## Supabase Notes [Section titled “Supabase Notes”](#supabase-notes) Use the session pooler host from the Supabase Connect panel. Keep SSL enabled and use a role with only the table or schema access required for the workflow. ## SQL Database Safety Checklist [Section titled “SQL Database Safety Checklist”](#sql-database-safety-checklist) - Use a read-only user for production. - Prefer replica or analytics databases when available. - Limit schemas and tables at the database permission layer. - Use explicit columns and `limit` clauses in agent queries. Cloudflare D1 is covered with warehouse-style SQL sources because its provider ID, `cloudflare_d1`, is grouped with OneQuery warehouse providers. Cloudflare R2 SQL uses the separate `cloudflare_r2_sql` warehouse provider for querying R2 Data Catalog Iceberg tables. [Edit page](https://github.com/wordbricks/onequery/edit/main/apps/landing/src/content/docs/docs/integrations/databases.mdx) [Previous\ Overview](/docs/integrations/)[Next\ Warehouses](/docs/integrations/warehouses/) --- ## Source: https://onequery.dev/docs/integrations/developer-tools/ # Developer Tools Developer tool integrations are usually Source API integrations. They let agents inspect pull requests, issues, releases, deployments, project metadata, and workflow context through approved provider tokens. ## Common Sources [Section titled “Common Sources”](#common-sources) | Provider | Provider ID | Use it for | | --- | --- | --- | | GitHub | `github` | Pull requests, commits, issues, repository metadata, and code review context. | | Linear | `linear` | Issue and workflow context. | | Jira | `jira` | Project and ticket context. | | Confluence | `confluence` | Internal documentation context. | | Vercel | `vercel` | Deployments, projects, teams, and runtime observability endpoints. | | Discord | `discord` | Workspace and channel context through bot or OAuth access. | | 1Password | `onepassword` | Vault and item context through a 1Password Connect Server token. | ## GitHub Example [Section titled “GitHub Example”](#github-example) Connect GitHub with a fine-grained personal access token or compatible installation token. Terminal window ``` onequery source connect --source github \ --input '{"sourceKey":"github_main","credentials":{"accessToken":"github_pat_or_installation_token","repositories":["octocat/Hello-World"]}}' ``` Use [Source API](/docs/guide/source-api/) for pull request, issue, deployment, and repository requests after the source is connected. ## Token Scoping [Section titled “Token Scoping”](#token-scoping) For agent-facing GitHub access, prefer fine-grained tokens limited to specific repositories and read-only permissions for contents, issues, pull requests, and metadata. For Jira and Confluence, create provider tokens for service accounts that have only the project or site access needed for the workflow. ## Review Pattern [Section titled “Review Pattern”](#review-pattern) Use developer tool sources to connect evidence to code changes: 1. Inspect production issue or deployment context. 2. Query the relevant source for details. 3. Inspect local code. 4. Create a small patch. 5. Mention the OneQuery source and provider endpoint in the change summary. [Edit page](https://github.com/wordbricks/onequery/edit/main/apps/landing/src/content/docs/docs/integrations/developer-tools.mdx) [Previous\ Observability](/docs/integrations/observability/)[Next\ Product Analytics](/docs/integrations/product-analytics/) --- ## Source: https://onequery.dev/docs/integrations/marketing-productivity/ # Marketing and Productivity Marketing and productivity systems often contain sensitive operational context. Connect them with service accounts or narrow provider tokens, then expose only the source identifiers agents need. ## Productivity Sources [Section titled “Productivity Sources”](#productivity-sources) | Provider | Provider ID | Use it for | | --- | --- | --- | | Airtable | `airtable` | Base records and metadata. | | Cal.com | `cal` | Booking and scheduling API access. | | Granola | `granola` | Meeting notes and note metadata. | ## Marketing Sources [Section titled “Marketing Sources”](#marketing-sources) | Provider | Provider ID | Use it for | | --- | --- | --- | | Google Search Console | `google_search_console` | Search analytics and site data. | | Amazon Ads | `amazon_ads` | Advertising account data. | | LinkedIn Ads | `linkedin_ads` | Campaign and ad account data. | | TikTok Marketing | `tiktok_marketing` | Advertiser and campaign data. | | SendGrid | `sendgrid` | Email, account, and marketing endpoints. | ## Airtable Example [Section titled “Airtable Example”](#airtable-example) Terminal window ``` onequery source connect --source airtable \ --input '{"sourceKey":"airtable_ops","credentials":{"personalAccessToken":"pat...","baseId":"appXXXXXXXXXXXXXX"}}' ``` ## Search Console Example [Section titled “Search Console Example”](#search-console-example) ``` { "sourceKey": "gsc_site", "credentials": { "accessToken": "ya29...", "siteUrl": "https://www.example.com/" } } ``` ## Access Rules [Section titled “Access Rules”](#access-rules) - Prefer provider tokens dedicated to OneQuery. - Limit scopes to read-only data when the provider supports it. - Use separate OneQuery sources for customer, internal, and production data. - Redact provider tokens from issue comments, prompts, and docs examples. [Edit page](https://github.com/wordbricks/onequery/edit/main/apps/landing/src/content/docs/docs/integrations/marketing-productivity.mdx) [Previous\ Product Analytics](/docs/integrations/product-analytics/)[Next\ Overview](/docs/examples/) --- ## Source: https://onequery.dev/docs/integrations/observability/ # Observability Observability integrations give agents production evidence without giving them direct access to provider tokens. ## Common Sources [Section titled “Common Sources”](#common-sources) | Provider | Provider ID | Use it for | | --- | --- | --- | | Sentry | `sentry` | Issues, events, releases, and project-level production errors. | | Laminar | `laminar` | LLM telemetry and run traces. | | Cloudflare Workers Observability | `cloudflare_workers_observability` | Worker telemetry and runtime investigation. | ## Sentry Example [Section titled “Sentry Example”](#sentry-example) Connect Sentry with a personal token scoped to organization and project read access. Terminal window ``` onequery source connect --source sentry \ --input '{"sourceKey":"sentry_prod","credentials":{"authToken":"sntrys_...","organizationSlug":"acme","projectSlug":"web"}}' ``` Use [Source API](/docs/guide/source-api/) for issue, event, and release requests after the source is connected. ## Cloudflare Workers Observability [Section titled “Cloudflare Workers Observability”](#cloudflare-workers-observability) Enable Workers Logs for the target Worker before expecting useful telemetry. Connect the account ID and a token with the Workers Observability permission required by Cloudflare. ``` { "sourceKey": "cloudflare_workers", "credentials": { "type": "cloudflare_workers_observability", "accountId": "023e105f4ecef8ad9ca31a8372d0c353", "apiToken": "cloudflare_api_token", "scriptName": "api-production" } } ``` ## Agent Debugging Rules [Section titled “Agent Debugging Rules”](#agent-debugging-rules) - Start with a short time window. - Ask the provider for fields and status before assuming event shape. - Summarize evidence separately from hypotheses. - Link production changes to the source and query used for evidence. [Edit page](https://github.com/wordbricks/onequery/edit/main/apps/landing/src/content/docs/docs/integrations/observability.mdx) [Previous\ Warehouses](/docs/integrations/warehouses/)[Next\ Developer Tools](/docs/integrations/developer-tools/) --- ## Source: https://onequery.dev/docs/integrations/product-analytics/ # Product Analytics Product analytics sources are commonly Source API integrations. They are useful for funnel checks, activation analysis, product telemetry review, and agent-assisted investigations. ## Common Sources [Section titled “Common Sources”](#common-sources) | Provider | Provider ID | Connection notes | | --- | --- | --- | | Google Analytics | `ga` | GA4 property ID plus OAuth or service account credentials. | | Amplitude | `amplitude` | Project API key, secret key, and region. | | Mixpanel | `mixpanel` | Service account, project ID, and data residency region. | | PostHog | `posthog` | Host URL, personal API key, and project ID. | | Microsoft Clarity | `microsoft_clarity` | Project Data Export API token. | | Cloudflare Web Analytics | `cloudflare_web_analytics` | Account ID, API token, and optional site tag. | ## PostHog Example [Section titled “PostHog Example”](#posthog-example) Terminal window ``` onequery source connect --source posthog \ --input '{"sourceKey":"posthog_main","credentials":{"hostUrl":"https://us.posthog.com","personalApiKey":"phx_personal_key","projectId":"12345"}}' ``` ## Analytics Query Habits [Section titled “Analytics Query Habits”](#analytics-query-habits) - Ask for aggregate metrics before raw event lists. - Include exact date ranges. - Keep project IDs and source identifiers explicit in task notes. ## Cross-Source Investigations [Section titled “Cross-Source Investigations”](#cross-source-investigations) Product analytics often becomes more useful when paired with developer or observability sources. For example: - PostHog event drop plus GitHub deployment history. - GA4 traffic drop plus Cloudflare Web Analytics. - Amplitude activation change plus Sentry release errors. Use OneQuery source identifiers in the investigation notes so each evidence source is traceable. [Edit page](https://github.com/wordbricks/onequery/edit/main/apps/landing/src/content/docs/docs/integrations/product-analytics.mdx) [Previous\ Developer Tools](/docs/integrations/developer-tools/)[Next\ Marketing and Productivity](/docs/integrations/marketing-productivity/) --- ## Source: https://onequery.dev/docs/integrations/warehouses/ # Warehouses Warehouse sources are useful for analytics, operations review, and agent-assisted investigations where the agent needs broad context but narrow execution authority. ## Supported Warehouse Patterns [Section titled “Supported Warehouse Patterns”](#supported-warehouse-patterns) | Provider | Provider ID | Connection notes | | --- | --- | --- | | Snowflake | `snowflake` | Account identifier, warehouse, database, optional schema, user, password, and optional role. | | BigQuery | `bigquery` | Project ID plus OAuth tokens or mapped service account fields. | | AWS Athena Connector | `aws_athena_connector` | Uses a registered OneQuery connector and Athena database details. | | MotherDuck | `motherduck` | PostgreSQL wire protocol endpoint with service token. | | Cloudflare D1 | `cloudflare_d1` | Serverless SQL source for edge application data. | | Cloudflare R2 SQL | `cloudflare_r2_sql` | Serverless analytics SQL over R2 Data Catalog Iceberg tables. | ## Snowflake Setup Notes [Section titled “Snowflake Setup Notes”](#snowflake-setup-notes) Create or choose a Snowflake role with read access to the target database and schemas. Grant `USAGE` on the warehouse, database, and schema, then grant `SELECT` on the tables or views OneQuery should query. Terminal window ``` onequery source connect --source snowflake \ --input '{"sourceKey":"snowflake_prod","credentials":{"account":"xy12345.us-east-1","warehouse":"ANALYTICS_WH","database":"ANALYTICS","schema":"PUBLIC","username":"ONEQUERY_READER","password":"","role":"ONEQUERY_READONLY"}}' ``` ## BigQuery Setup Notes [Section titled “BigQuery Setup Notes”](#bigquery-setup-notes) For service-account based access, map the Google Cloud JSON key into the fields OneQuery expects rather than pasting the raw JSON blob. ``` { "sourceKey": "bigquery_prod", "credentials": { "projectId": "analytics-project", "serviceAccount": { "projectId": "analytics-project", "clientEmail": "onequery@analytics-project.iam.gserviceaccount.com", "privateKey": "-----BEGIN PRIVATE KEY-----\n...\n-----END PRIVATE KEY-----\n" } } } ``` ## Warehouse Query Habits [Section titled “Warehouse Query Habits”](#warehouse-query-habits) - Always include a time window. - Prefer aggregate queries before requesting raw rows. - Use provider cost controls where available. - Keep service accounts separate from human analyst accounts. [Edit page](https://github.com/wordbricks/onequery/edit/main/apps/landing/src/content/docs/docs/integrations/warehouses.mdx) [Previous\ Databases](/docs/integrations/databases/)[Next\ Observability](/docs/integrations/observability/) --- ## Source: https://onequery.dev/docs/operations/ # Operations Use these pages when OneQuery becomes part of a production workflow. [Self-host OneQuery](/docs/operations/self-host/)Run the gateway, connect the CLI, and understand lifecycle commands. [Credential management](/docs/operations/credential-management/)Keep source credentials centralized, scoped, rotated, and out of agent runtimes. [Audit review](/docs/operations/audit-review/)Review source activity after human and agent runs. [Security checklist](/docs/operations/security-checklist/)Use a production checklist before exposing sources to agents. [Troubleshooting](/docs/operations/troubleshooting/)Debug gateway, auth, source, query, and provider failures. [Edit page](https://github.com/wordbricks/onequery/edit/main/apps/landing/src/content/docs/docs/operations/index.mdx) [Previous\ Analytics Investigation](/docs/examples/analytics-investigation/)[Next\ Self-Host OneQuery](/docs/operations/self-host/) --- ## Source: https://onequery.dev/docs/operations/audit-review/ # Audit Review Audit review turns OneQuery from a convenience tool into an operational control. ## Review After These Events [Section titled “Review After These Events”](#review-after-these-events) - A new production source is connected. - A provider credential changes. - An agent runs against a production source for the first time. - A query is blocked or fails repeatedly. - A production change cites evidence from OneQuery. ## What to Check [Section titled “What to Check”](#what-to-check) | Question | Why it matters | | --- | --- | | Which actor initiated the request? | Separates human, agent, and automation activity. | | Which source was used? | Confirms the request stayed inside the approved boundary. | | What operation ran? | Shows whether the request was narrow and task-relevant. | | What was the outcome? | Distinguishes success, provider failure, and policy failure. | | When did it happen? | Links source activity to incidents, deployments, or PRs. | ## Agent Review Template [Section titled “Agent Review Template”](#agent-review-template) ``` Agent run: - Task: - Allowed sources: - Sources actually used: - Queries or endpoints: - Blocked requests: - Production change created: - Reviewer: ``` Keep review notes short enough that operators will actually write them. [Edit page](https://github.com/wordbricks/onequery/edit/main/apps/landing/src/content/docs/docs/operations/audit-review.mdx) [Previous\ Credential Management](/docs/operations/credential-management/)[Next\ Security Checklist](/docs/operations/security-checklist/) --- ## Source: https://onequery.dev/docs/operations/credential-management/ # Credential Management OneQuery is most useful when it replaces scattered credentials with named source access. ## Credential Rules [Section titled “Credential Rules”](#credential-rules) - Create provider credentials dedicated to OneQuery when possible. - Use read-only database roles and provider tokens for agent-facing sources. - Scope tokens to the projects, repositories, accounts, or datasets needed for the workflow. - Rotate provider credentials through the source configuration path. - Do not paste raw credentials into prompts, issue comments, docs, or test fixtures. ## Source Separation [Section titled “Source Separation”](#source-separation) Use separate OneQuery sources for separate risk levels: | Source identifier | Purpose | | --- | --- | | `postgres://warehouse_staging` | Lower-risk test or staging analytics. | | `postgres://warehouse_prod` | Production warehouse access. | | `github://github_main` | Main repository access. | | `sentry://sentry_web_prod` | Production web error evidence. | Do not reuse a source identifier for a different environment after an agent has been instructed to use it. ## Rotation Pattern [Section titled “Rotation Pattern”](#rotation-pattern) 1. Create the replacement credential at the provider. 2. Update the OneQuery source configuration. 3. Test a minimal command. 4. Revoke the previous provider credential. 5. Review recent audit history for unexpected failures. [Edit page](https://github.com/wordbricks/onequery/edit/main/apps/landing/src/content/docs/docs/operations/credential-management.mdx) [Previous\ Self-Host OneQuery](/docs/operations/self-host/)[Next\ Audit Review](/docs/operations/audit-review/) --- ## Source: https://onequery.dev/docs/operations/security-checklist/ # Security Checklist Use this checklist before making a source available to an agent workflow. ## Source Setup [Section titled “Source Setup”](#source-setup) - The provider credential is read-only when the provider supports read-only access. - The credential is dedicated to OneQuery or clearly owned by the OneQuery deployment. - Production and staging data use separate OneQuery sources. - The source was tested with a minimal query or API request. ## Agent Access [Section titled “Agent Access”](#agent-access) - The agent receives source identifiers, not raw credentials. - The task prompt lists the allowed sources. - The prompt requires narrow time windows and result limits. - The prompt requires an evidence summary before code changes. - The agent environment does not contain duplicate provider credentials. ## Operations [Section titled “Operations”](#operations) - Operators know where gateway logs and audit records are reviewed. - Credential rotation has an owner. - Incident runbooks name approved OneQuery sources. - Blocked requests are reviewed instead of bypassed with raw credentials. - Production changes cite evidence sources when OneQuery was used. ## Red Flags [Section titled “Red Flags”](#red-flags) Stop the rollout if: - A prompt includes a database password, provider token, or cloud key. - The approved source list uses ambiguous identifiers such as `postgres://prod` or `postgres://db`. - The provider token can write to production systems and the workflow only needs read access. - The agent asks to broaden access before producing a source-backed explanation. [Edit page](https://github.com/wordbricks/onequery/edit/main/apps/landing/src/content/docs/docs/operations/security-checklist.mdx) [Previous\ Audit Review](/docs/operations/audit-review/)[Next\ Troubleshooting](/docs/operations/troubleshooting/) --- ## Source: https://onequery.dev/docs/operations/self-host/ # Self-Host OneQuery Self-hosting keeps the OneQuery gateway under your control while still giving developers and agents a single access path. This page covers deployment concerns; use [Choose Server Path](/docs/guide/start-gateway/) for local lifecycle commands. ## Runtime Ownership [Section titled “Runtime Ownership”](#runtime-ownership) Treat the gateway as infrastructure, not a developer helper script. Decide who owns: - Runtime configuration. - Secret rotation. - Process restarts. - Log review. - Upgrade timing. ## Process Manager [Section titled “Process Manager”](#process-manager) Run foreground mode under your process manager when you need supervised restarts: Terminal window ``` onequery gateway ``` Keep the OneQuery home directory and runtime state on persistent storage. Back it up before upgrades and credential rotations. ## Shared Server URL [Section titled “Shared Server URL”](#shared-server-url) Terminal window ``` onequery config set api.server_url https://onequery.example.com onequery auth login ``` Document the server URL for operators and agents that should use the shared gateway instead of a local one. ## Deployment Notes [Section titled “Deployment Notes”](#deployment-notes) - Put the gateway behind your normal TLS, identity, and network controls. - Put provider credentials in the OneQuery source configuration path, not agent environment variables. - Monitor startup, runtime logs, and source connection failures. - Document the server URL and approved source identifiers for operators. - Test backup restore before depending on self-hosted state. See the repository self-hosting guide for deeper runtime, storage, proxy, backup, and upgrade details. [Edit page](https://github.com/wordbricks/onequery/edit/main/apps/landing/src/content/docs/docs/operations/self-host.mdx) [Previous\ Overview](/docs/operations/)[Next\ Credential Management](/docs/operations/credential-management/) --- ## Source: https://onequery.dev/docs/operations/troubleshooting/ # Troubleshooting Start with the failing layer. Most issues are install, gateway, auth, source, query, or provider-scope problems. ## CLI Is Not Found [Section titled “CLI Is Not Found”](#cli-is-not-found) Terminal window ``` onequery --help ``` If the command is missing, reinstall with your chosen package manager: Terminal window ``` npm install -g @onequery/cli ``` ## Gateway Is Not Running [Section titled “Gateway Is Not Running”](#gateway-is-not-running) Terminal window ``` onequery gateway status onequery gateway logs onequery gateway start ``` If a remote team server should be used instead, confirm the configured server: Terminal window ``` onequery config set api.server_url https://onequery.example.com ``` ## Auth Fails [Section titled “Auth Fails”](#auth-fails) Check that you are using the expected profile and server: Terminal window ``` onequery --profile work auth whoami ONEQUERY_PROFILE=work onequery auth whoami ``` Re-authenticate if the token expired or was revoked. ## Source Is Missing [Section titled “Source Is Missing”](#source-is-missing) Terminal window ``` onequery source list ``` If the source is missing, connect it or switch to the organization/profile where it exists. ## Query Is Blocked [Section titled “Query Is Blocked”](#query-is-blocked) Check whether the SQL is read-only, single-statement, and small enough for the source limits. Add explicit columns, a time window, and a limit. ## Provider Request Fails [Section titled “Provider Request Fails”](#provider-request-fails) Provider API failures usually come from: - Token scope mismatch. - Wrong organization, project, site, repository, or account ID. - Expired provider token. - Pagination or payload size. - Provider endpoint path mismatch. Run a smaller Source API request and expand only after the source and permission are confirmed. [Edit page](https://github.com/wordbricks/onequery/edit/main/apps/landing/src/content/docs/docs/operations/troubleshooting.mdx) [Previous\ Security Checklist](/docs/operations/security-checklist/)[Next\ Overview](/docs/security/) --- ## Source: https://onequery.dev/docs/reference/ # Reference Reference pages are compact lookup material. Use the guides for task flows and these pages when you need exact names or conventions. [CLI commands](/docs/reference/cli/)Common OneQuery CLI commands grouped by task. [Source providers](/docs/reference/source-providers/)Current public provider families and provider IDs. [Terminology](/docs/reference/terminology/)Definitions for source, provider, query interface, Source API, gateway, and audit history. [Errors and blocked requests](/docs/reference/errors/)Likely causes and safe next actions for common OneQuery failures. [Edit page](https://github.com/wordbricks/onequery/edit/main/apps/landing/src/content/docs/docs/reference/index.mdx) [Previous\ Cost Limits](/docs/security/cost-limits/)[Next\ CLI Commands](/docs/reference/cli/) --- ## Source: https://onequery.dev/docs/reference/cli/ # CLI Commands ## Help [Section titled “Help”](#help) Terminal window ``` onequery --help onequery gateway --help onequery source --help onequery query --help ``` ## Gateway [Section titled “Gateway”](#gateway) Terminal window ``` onequery gateway onequery gateway start onequery gateway status onequery gateway logs onequery gateway restart onequery gateway stop ``` ## Auth and Server [Section titled “Auth and Server”](#auth-and-server) Terminal window ``` onequery config set api.server_url https://onequery.example.com onequery auth login onequery auth whoami onequery org use ``` ## Sources [Section titled “Sources”](#sources) Terminal window ``` onequery source connect --help onequery source connect --source postgres onequery source connect --source postgres --input '{"sourceKey":"warehouse","credentials":{"host":"db.example.com","database":"app","username":"onequery_readonly","password":""}}' onequery source list onequery source show postgres://warehouse ``` ## Queries [Section titled “Queries”](#queries) Terminal window ``` onequery query exec --source postgres://warehouse --sql "select 1" ``` ## Source API [Section titled “Source API”](#source-api) Terminal window ``` onequery api --source github://github_main /repos/acme/web/pulls --json ``` Use `--paginate`, `--max-pages`, and `--jq` for provider endpoints that return large arrays. [Edit page](https://github.com/wordbricks/onequery/edit/main/apps/landing/src/content/docs/docs/reference/cli.mdx) [Previous\ Overview](/docs/reference/)[Next\ Source Providers](/docs/reference/source-providers/) --- ## Source: https://onequery.dev/docs/reference/errors/ # Errors and Blocked Requests Use blocked requests as feedback. Do not bypass OneQuery by giving an agent raw credentials. ## Common Failures [Section titled “Common Failures”](#common-failures) | Failure | Likely cause | Next action | | --- | --- | --- | | CLI command not found | CLI not installed or not on `PATH`. | Reinstall the CLI and run `onequery --help`. | | Gateway unavailable | Local gateway is stopped or remote server is misconfigured. | Run `onequery gateway status` or set the server URL. | | Unauthorized | CLI session expired or wrong profile/server. | Run `onequery auth login` for the intended profile. | | Source not found | Source identifier is wrong or belongs to another org. | Run `onequery source list`. | | Query blocked | SQL is not read-only, has multiple statements, or is too broad. | Narrow the SQL, add limits, and retry. | | Provider permission denied | Provider token lacks scope or points to the wrong account. | Fix provider permissions in the source credential. | | Pagination too large | Source API request returns too much data. | Add `--max-pages`, provider filters, or `--jq`. | ## Safe Recovery Pattern [Section titled “Safe Recovery Pattern”](#safe-recovery-pattern) 1. Identify the layer: CLI, gateway, auth, source, query, or provider. 2. Retry with a smaller request. 3. Keep the source identifier the same unless it is wrong. 4. Escalate to an operator if broader access appears necessary. 5. Record the blocked request in the investigation notes when it affects the result. ## What Not to Do [Section titled “What Not to Do”](#what-not-to-do) - Do not paste provider tokens into the agent environment. - Do not switch to a broad production credential to save time. - Do not remove query limits just because the first request returned too little data. - Do not ignore repeated blocked requests from the same workflow. [Edit page](https://github.com/wordbricks/onequery/edit/main/apps/landing/src/content/docs/docs/reference/errors.mdx) [Previous\ Terminology](/docs/reference/terminology/)[Next\ Overview](/docs/support/) --- ## Source: https://onequery.dev/docs/reference/source-providers/ # Source Providers Use the provider ID with `onequery source connect --source `. The source identifier later uses the same provider ID before `://`. ## Provider Families [Section titled “Provider Families”](#provider-families) | Family | Provider IDs | | --- | --- | | Databases | `postgres`, `supabase`, `mysql`, `mongodb` | | Warehouses | `snowflake`, `bigquery`, `aws_athena_connector`, `motherduck`, `cloudflare_d1`, `cloudflare_r2_sql` | | Observability | `sentry`, `laminar`, `cloudflare_workers_observability` | | Developer workflow | `github`, `linear`, `jira`, `confluence`, `vercel`, `discord`, `onepassword` | | Product analytics | `ga`, `amplitude`, `mixpanel`, `posthog`, `microsoft_clarity`, `cloudflare_web_analytics` | | Marketing | `google_search_console`, `amazon_ads`, `linkedin_ads`, `tiktok_marketing`, `sendgrid` | | Productivity | `airtable`, `cal`, `granola` | For the live list used by the site, see [Connectors](/connectors/). [Edit page](https://github.com/wordbricks/onequery/edit/main/apps/landing/src/content/docs/docs/reference/source-providers.mdx) [Previous\ CLI Commands](/docs/reference/cli/)[Next\ Terminology](/docs/reference/terminology/) --- ## Source: https://onequery.dev/docs/reference/terminology/ # Terminology ## Terms [Section titled “Terms”](#terms) | Term | Means | Example | | --- | --- | --- | | Agent | A tool that can invoke OneQuery commands for approved context. | Coding agent, CI assistant | | Audit history | Records of who asked, which source was used, what ran, and when. | Query and Source API records | | Gateway | The OneQuery server runtime for local or self-hosted deployments. | `onequery gateway start` | | Provider ID | The integration type passed to source setup. | `postgres`, `github`, `sentry` | | Local name | The name you choose for one connection. | `warehouse`, `github_main`, `sentry_prod` | | Source | A named connection to a provider. | PostgreSQL warehouse | | `sourceKey` | The JSON field for the local name during source setup. | `"sourceKey": "warehouse"` | | Source identifier | The address used by the CLI and agents. | `postgres://warehouse` | | Query-capable source | A source that supports SQL-oriented query execution. | PostgreSQL, Snowflake, BigQuery | | Source API source | A source where the useful operation is a provider API request. | GitHub pull requests, Sentry issues | | Read-only | Access intended for inspection, not mutation. | `select 1`, limited API tokens | | Profile | A named CLI state selection for separate environments or organizations. | `onequery --profile work auth login` | | OneQuery home | The local directory where CLI state and gateway runtime state live. | `~/.onequery/`, or a custom `ONEQUERY_HOME` | | Shared server | A OneQuery server operated for a team or organization. | `https://onequery.example.com` | | Local gateway | A OneQuery gateway process you run yourself. | `onequery gateway start` | [Edit page](https://github.com/wordbricks/onequery/edit/main/apps/landing/src/content/docs/docs/reference/terminology.mdx) [Previous\ Source Providers](/docs/reference/source-providers/)[Next\ Errors and Blocked Requests](/docs/reference/errors/) --- ## Source: https://onequery.dev/docs/security/ # Security Security is the reason to put OneQuery between agents and production data. These pages explain what OneQuery is meant to control, what still belongs to operators, and how to avoid turning prompts into the only access boundary. [Security architecture](/docs/security/security-architecture/)Credential flow, source execution, gateway placement, and audit boundaries. [Threat model](/docs/security/threat-model/)What OneQuery helps protect against and what it does not claim to solve. [Data handling](/docs/security/data-handling/)How to reason about credentials, result payloads, logs, and support sharing. [Cost limits](/docs/security/cost-limits/)Use budgets, query shape, and provider controls to keep agent requests bounded. ## Security Principle [Section titled “Security Principle”](#security-principle) OneQuery should be the deterministic boundary. The agent prompt should explain the workflow, but source credentials, source permissions, query validation, result limits, and audit review should live outside the prompt. [Edit page](https://github.com/wordbricks/onequery/edit/main/apps/landing/src/content/docs/docs/security/index.mdx) [Previous\ Troubleshooting](/docs/operations/troubleshooting/)[Next\ Security Architecture](/docs/security/security-architecture/) --- ## Source: https://onequery.dev/docs/security/cost-limits/ # Cost Limits Agent workflows can accidentally ask expensive questions. Cost control should be part of the source setup and prompt, especially for warehouses and analytics systems. ## Where Cost Comes From [Section titled “Where Cost Comes From”](#where-cost-comes-from) - Warehouse scan volume. - Provider API pagination. - Large JSON responses. - Repeated retries after ambiguous failures. - Raw event exports instead of aggregate checks. ## Query Habits [Section titled “Query Habits”](#query-habits) Use query shape as the first cost control: ``` select date_trunc('hour', occurred_at) as hour, count(*) as events from analytics.events where occurred_at >= current_timestamp - interval '24 hours' group by 1 order by 1 ``` Avoid open-ended raw exports: ``` select * from analytics.events ``` ## Provider Controls [Section titled “Provider Controls”](#provider-controls) Use provider-side budgets and role limits where available: - BigQuery job budgets and project-level controls. - Snowflake warehouse sizing and role scope. - Athena workgroup controls. - API pagination limits. - Analytics endpoint date ranges. ## Agent Instruction [Section titled “Agent Instruction”](#agent-instruction) Add cost language to agent prompts: ``` Use aggregate queries first. Include explicit date windows and limits. Do not request raw event exports unless an operator approves the need. ``` [Edit page](https://github.com/wordbricks/onequery/edit/main/apps/landing/src/content/docs/docs/security/cost-limits.mdx) [Previous\ Data Handling](/docs/security/data-handling/)[Next\ Overview](/docs/reference/) --- ## Source: https://onequery.dev/docs/security/data-handling/ # Data Handling OneQuery keeps source credentials out of the agent runtime, but result data still matters. Treat returned rows, provider responses, logs, and support artifacts as production data unless you know otherwise. ## Credentials [Section titled “Credentials”](#credentials) - Store provider credentials only through the OneQuery source setup path. - Use dedicated provider credentials when possible. - Rotate credentials when a source owner changes or a provider token may have been exposed. - Never include real credentials in docs examples, prompts, issues, or screenshots. ## Result Payloads [Section titled “Result Payloads”](#result-payloads) Agents can still see whatever the approved query or API request returns. Reduce payloads before they reach the agent: - Select only needed columns. - Add time windows. - Add row limits. - Use aggregate queries before raw rows. - Use `--jq` to filter provider JSON responses. ## Logs and Audit Records [Section titled “Logs and Audit Records”](#logs-and-audit-records) Keep command logs and audit records useful without turning them into a second sensitive data store. Avoid logging raw credentials. Keep command examples sanitized. Review whether query text or provider paths can reveal sensitive identifiers before sharing them outside the team. ## Support Sharing [Section titled “Support Sharing”](#support-sharing) When asking for help, share: - CLI version. - Gateway mode. - Sanitized command. - Source identifier. - Provider family. - Error output with secrets removed. Do not share: - Database passwords. - Provider tokens. - Service account private keys. - Raw user rows or customer records. [Edit page](https://github.com/wordbricks/onequery/edit/main/apps/landing/src/content/docs/docs/security/data-handling.mdx) [Previous\ Threat Model](/docs/security/threat-model/)[Next\ Cost Limits](/docs/security/cost-limits/) --- ## Source: https://onequery.dev/docs/security/security-architecture/ # Security Architecture OneQuery separates the caller from the underlying provider credential. The caller invokes a command against a named source; OneQuery resolves the source, uses the stored credential, executes the bounded operation, and returns the result. ## Request Flow [Section titled “Request Flow”](#request-flow) ``` agent or developer -> onequery CLI -> OneQuery gateway or server -> named source configuration -> provider credential -> database, warehouse, or provider API -> bounded result -> audit record ``` ## Credential Boundary [Section titled “Credential Boundary”](#credential-boundary) The provider credential belongs to the OneQuery source configuration. It should not be copied into: - Agent prompts. - Local task descriptions. - CI logs. - Issue comments. - `AGENTS.md` or tool setup files. - Shell environment variables available to the agent. ## Gateway Placement [Section titled “Gateway Placement”](#gateway-placement) For self-hosted deployments, the gateway is the control point between local tools and connected sources. Run it where it can reach the sources it needs while still giving operators access to logs, runtime state, and configuration. Common placements: | Placement | Use it for | | --- | --- | | Local developer gateway | Evaluation, development, and private source testing. | | Shared team gateway | Team-wide CLI and agent workflows. | | Production-managed gateway | Repeatable production source access with operator-owned runtime and storage. | ## What Leaves the Source [Section titled “What Leaves the Source”](#what-leaves-the-source) The result payload returns to the caller. Keep result shape small and task-specific. For SQL, select explicit columns and limits. For Source API, use pagination limits and `--jq` filtering where possible. ## What Gets Reviewed [Section titled “What Gets Reviewed”](#what-gets-reviewed) Operators should be able to review source activity by actor, source, operation, outcome, and time. See [Audit review](/docs/operations/audit-review/) for a lightweight review workflow. [Edit page](https://github.com/wordbricks/onequery/edit/main/apps/landing/src/content/docs/docs/security/security-architecture.mdx) [Previous\ Overview](/docs/security/)[Next\ Threat Model](/docs/security/threat-model/) --- ## Source: https://onequery.dev/docs/security/threat-model/ # Threat Model OneQuery is an access boundary for source execution. It is not a complete replacement for provider permissions, database roles, incident process, or human review. ## Helps Protect Against [Section titled “Helps Protect Against”](#helps-protect-against) | Risk | OneQuery control | | --- | --- | | Agent receives raw production credentials | Credentials stay in OneQuery source configuration. | | Agent invents a direct production access path | Workflow uses named source identifiers and commands. | | SQL request is too broad or unsafe | Query validation, single-statement expectations, and result limits can block or narrow execution. | | Provider token is scattered across tools | OneQuery source configuration replaces copied provider credentials. | | No record of what the agent inspected | Audit history records source activity. | ## Does Not Automatically Protect Against [Section titled “Does Not Automatically Protect Against”](#does-not-automatically-protect-against) - A provider token that has broader permissions than the workflow needs. - A database role that can read sensitive tables the agent should not inspect. - Sensitive data returned in a legitimate result payload. - A human approving a risky source or prompt. - A second credential path outside OneQuery. - Unsupported provider behavior or provider-side outages. ## Prompt Injection and Tool Output [Section titled “Prompt Injection and Tool Output”](#prompt-injection-and-tool-output) Prompt rules can tell an agent what to do, but they cannot enforce source access. Treat hostile or confusing tool output as a reason to keep the deterministic boundary narrow: - Limit sources by task. - Limit query shape. - Limit provider endpoints. - Require evidence summaries. - Review audit history. ## Operator Responsibility [Section titled “Operator Responsibility”](#operator-responsibility) Operators still own: - Provider credential scope. - Database role design. - Source naming and environment separation. - Agent prompt review. - Production change review. - Audit review after sensitive runs. [Edit page](https://github.com/wordbricks/onequery/edit/main/apps/landing/src/content/docs/docs/security/threat-model.mdx) [Previous\ Security Architecture](/docs/security/security-architecture/)[Next\ Data Handling](/docs/security/data-handling/) --- ## Source: https://onequery.dev/docs/support/ # Support Start with [Troubleshooting](/docs/operations/troubleshooting/) when a command fails. Use this page when you need to decide what information to collect before asking for help. ## Before Asking for Help [Section titled “Before Asking for Help”](#before-asking-for-help) Collect: - CLI version and install method. - Gateway mode: local, foreground, background, or remote server. - Command that failed, with secrets removed. - Source identifier, such as `postgres://warehouse`. - Provider family, such as database, warehouse, observability, or developer tool. - Whether the failure is install, auth, source setup, query validation, provider permission, or provider response shape. ## Do Not Share [Section titled “Do Not Share”](#do-not-share) - Database passwords. - Provider tokens. - Service account private keys. - Raw production rows unless the support workflow explicitly requires them and an operator approves the share. ## Useful Links [Section titled “Useful Links”](#useful-links) - [Getting started](/docs/getting-started/) - [Connect a source](/docs/guide/connect-source/) - [Security checklist](/docs/operations/security-checklist/) - [Connectors](/connectors/) [Edit page](https://github.com/wordbricks/onequery/edit/main/apps/landing/src/content/docs/docs/support/index.mdx) [Previous\ Errors and Blocked Requests](/docs/reference/errors/)