> Documentation index: https://docs.beetl.io/llms.txt # The agent trust boundary > What the assistant and MCP clients can read and change, and how each change is gated. Source: https://docs.beetl.io/concepts/agent-trust-boundary/ Last updated: 2026-11-10 The short version: Beetl reads your systems, never writes back to them, and publishes only where you told it to. The assistant can still change things inside Beetl, so this page lists exactly what and how each change is gated. There are two planes. The **analysis plane** (queries, previews, the knowledge base) cannot change anything. The **platform plane** changes Beetl's own objects: page drafts, pipelines, deployments, automations, apps, reports and file processors. Neither writes to a system you connected. ## Could it change data in your systems? Not through the assistant, MCP, an app or a query. Registered and external datasets are read in place, and Beetl rejects them as pipeline destinations both at deploy and at run time. SQL that runs as a query, from the Query editor or `execute_query` in chat, automations and MCP, is planned with DML and DDL disabled. It cannot insert, update, delete or create anything, whatever the model writes or a prompt injection asks for. The restriction is in the query engine, not in a prompt. The exception is integration code you install. A Connect package runs in an isolated sandbox, but its own code decides which endpoints it calls, including write endpoints. Review a package before you install it. See [Sandbox](https://docs.beetl.io/connect/sandbox). ## What the assistant and MCP clients can change Every tool is either read or write. Chat can use write tools, automations only read tools, and an MCP client gets the scope of its API key. These are the write tools, and all of them write only to Beetl or to your own storage: | Tool | Available in | What it changes | Gate | | ---------------------- | --------------------- | ---------------------------------------------------------------------------------------------------------------- | --------------------------------------------------- | | Page edits | Chat | The page you have open (see below) | Dismiss undoes the latest turn's edits | | `build_pipeline` | Chat, MCP `write` key | Creates a pipeline's Working version | None | | `update_pipeline` | Chat, MCP `write` key | Changes a pipeline's Working version | None | | `deploy_pipeline` | Chat, MCP `write` key | Promotes Working to Deployed and starts a run | Your confirmation in chat; none over MCP | | Automation tools | Chat, MCP `write` key | Create, update, run, pause or resume automations | None | | `delete_automation` | Chat, MCP `write` key | Deletes an automation | Your confirmation in chat; none over MCP | | Report tools | Chat, MCP `write` key | Create, change, tag and render reports and save report templates; each render writes PDFs to your storage | None | | App tools | Chat only | Create, change, run and delete apps, bind inputs, set schedules, operate app screens | Your confirmation in chat; MCP refuses them | | File processor changes | Chat only | Save a processor's settings, analyze or process documents, re-analyze a document, change fields and instructions | Your confirmation in chat; MCP has no tool for them | **Page drafts.** On Query, Home, the pipeline editor and the automation editor, the assistant can read the page and change it, but never fields the page marks as read-only. Changed fields flash and the reply shows a Draft updated row with Dismiss. In the pipeline and automation editors nothing is kept until you save; on Query and Home the changes apply right away, and Dismiss undoes them. See [Building with the assistant](https://docs.beetl.io/chat/building-with-the-assistant). **Pipeline drafts.** `build_pipeline` creates a pipeline and `update_pipeline` changes only the fields it sends on any pipeline in the tenant, by ID. Neither deploys or runs anything, and chat cannot undo them. If the pipeline is open in the editor, the assistant edits your draft there instead of overwriting it. **Deployment.** `deploy_pipeline` promotes the Working version and starts a run, which writes the pipeline's destination dataset. In chat the turn pauses on an Allow or Deny card; over MCP a `write` key deploys directly. `run_pipeline` is a read tool that only previews a draft, and no tool reruns a deployed pipeline. **Apps and reports.** Running an app replaces its output datasets. Rendering a report writes PDFs to your storage. App changes need your confirmation in chat and are refused over MCP. Report writes need no confirmation, in chat or over MCP with a `write` key. See [Apps](https://docs.beetl.io/apps) and [Reports](https://docs.beetl.io/reports). **File processors.** In chat the assistant can open a processor's screens and read what is on them. Reading, selecting a document or record, searching, showing a record's source and previewing the output need no confirmation. Saving settings, analyzing, processing, re-analyzing and any edit to the processor's fields or instructions ask for your confirmation first, because they can start an AI request that is billed and can change the dataset. MCP clients and automations can only read processors, their records and their source text. See [Documents and spreadsheets](https://docs.beetl.io/sources/documents). **Automations** are observe-only. A run can query and read but cannot change anything or propose an action. Managing automations from chat or over MCP is a write action, and over MCP needs a `write` key. Beetl has no outbound notifications, so nothing leaves Beetl by email, Slack or webhook. ## Could untrusted content take over the conversation? Beetl treats everything the assistant reads through its tools, including your data, as data rather than instructions. The only tenant text it treats as trusted guidance is the assistant instructions a TenantAdmin writes in Settings. See [AI settings](https://docs.beetl.io/concepts/ai-settings). Documents are data in the same way: their contents never act as instructions. Extraction sends document text to the AI provider of your tenant, as chat and automations send the data they read. See [AI settings](https://docs.beetl.io/concepts/ai-settings#where-model-traffic-goes). Credentials and keys are stored encrypted, and no tool returns them. The knowledge base the assistant reads (platform reference docs and generated pipeline docs) is read-only, so nothing the assistant reads in one session can shape another. ## MCP keys An MCP key is `read` or `write`, checked on every call. A `read` key only sees and can only call read tools. See [MCP setup](https://docs.beetl.io/mcp/setup). ## Can a conclusion be verified afterwards? Every chat turn is recorded on the chat's Timeline tab, with each tool call, token counts and timings. Automation runs record the purpose of every query next to the SQL that ran and its result. Query results carry cell-level lineage and expire after 7 days, including those an automation report links to. See [Query results](https://docs.beetl.io/concepts/query-results). ## Good practice * Review what the assistant changed before you save a page or deploy a pipeline. In chat, deploys, app changes, file processor changes and deleting an automation ask for confirmation; other changes do not. * Give MCP clients a `read` key unless they need to change things. Treat a `write` key like a deploy credential, since it deploys pipelines, deletes automations and writes report PDFs without confirmation. App changes are not available over MCP. * Revoke keys you no longer use. See [API keys](https://docs.beetl.io/mcp/setup). More detail for a reviewer is in [Security and compliance](https://docs.beetl.io/security).