{"slug": "your-agent-can-now-change-things-if-you-say-so-once", "title": "Your Agent Can Now Change Things — If You Say So Once", "summary": "Datanika released eight write tools over its hosted MCP endpoint, letting connected agents create connections, uploads, pipelines and transformations, bulk-import projects and trigger runs, where previously they could only read. Write access is granted at OAuth consent time, with the resulting API key carrying exactly the approved scopes; clients that omit a scope or request unrecognized scopes default to read-only, and pasted API keys stay read-only on the hosted endpoint. The company deliberately skipped a per-call confirmation and a split between building and triggering, arguing that controls not backed by the token's scopes amount to security theatre.", "body_md": "Until now, an agent connected to Datanika over [MCP](https://datanika.io/docs/mcp-server/) could look but not touch. It read your connections, previewed tables, compiled dbt models and pulled run logs — genuinely useful for debugging, and deliberately unable to change anything.\n\nThe eight write tools are now available over the hosted endpoint: create connections, uploads, pipelines and transformations, bulk-import a whole project, and trigger runs. This is the first release where an agent can act on your data rather than only read it.\n\nThe interesting part isn't the tools. It's where the decision lives.\n\nWrite access is granted at **OAuth consent time**. When a client asks for write scopes, you approve them in the browser, and the API key that approval mints carries exactly those scopes. There is no runtime toggle, no per-call prompt, and nothing to restart.\n\nWe considered a per-call confirmation — the agent asks, you approve each write. It doesn't survive contact with a stateless transport, and more importantly it gates the wrong party: a token the agent mints and echoes back to itself is a ritual, not a control. The agent is the thing being gated, so it can't also hold the gate.\n\nSo the human decision moves to the one moment a human is definitely present and definitely paying attention: the consent screen. What you approve is what the credential can do, and enforcement stays on the key's scopes where it already lived.\n\n**Silence is not consent.** A client that omits `scope`, or asks for something we don't recognise, gets read-only. Clients omit it routinely, so this had to be the default rather than an error — an agent should never acquire write access because a request was ambiguous.\n\n**A pasted API key stays read-only on the hosted endpoint** — even if that key's own scopes would permit writes. Nothing recorded a human decision, so the hosted path won't infer one from a credential you copied into a config file. (Your key's scopes still bound what the REST API does with it; this is specifically about what the MCP layer will expose.)\n\n**There is no \"may build but may not trigger\" tier**, and this is the refinement we deliberately didn't ship. It sounds prudent: let the agent draft a pipeline, reserve the run for a human. But the REST API gives `create_upload` and `trigger_upload` the same `uploads:write` scope. A checkbox splitting them could only be enforced inside the MCP layer, while the credential itself still permitted both — a control the token doesn't back, which is exactly the kind of security theatre the per-call confirmation would have been. Spend is bounded by your key's rate limit and byte quota instead, which are real limits rather than a UI promise.\n\nA read-only grant shows a green **Read-only** badge and says the app cannot create, modify, delete or trigger anything.\n\nA write grant shows an amber **Read and write** badge and spells the capability out: *\"Create, modify and delete connections, uploads, pipelines, transformations, schedules and notifications — and trigger runs\"*, with a caution that the app can change your data and start jobs that use your quota.\n\nIt also names the API key that approving will create — `MCP: <app name>` — so you know what to look for later. Revoking that key in **Settings → API Keys** ends the grant; the authority travels with the credential, so there's no second place to check.\n\nOften, no — and that's not false modesty. The most common thing people want from an agent here is *\"help me understand why this pipeline broke,\"* which is entirely a read operation. Read-only is the better default for a connection you'll leave in place.\n\nWrite access earns its keep when you want the agent to actually build: scaffold a set of dbt models, wire up a new source, re-run a failed load while you're reading the logs. If that's the job, grant it — knowingly, to a client you trust, with a key you can revoke in one click.\n\nWhat we'd suggest either way: use a separate grant for agent work rather than reusing a key from CI. If an agent does something surprising, you want to revoke one thing and know exactly what you broke.\n\nThe write tools create dbt models and dlt-backed uploads — the same artifacts you'd have built by hand. `create_transformation` writes SQL with `ref()` and `source()`, testable and runnable by plain `dbt run` on a machine that has never heard of Datanika.\n\nThat matters more with write access than without it. An agent can produce a lot of work quickly, and if that work lands in a proprietary format the speed becomes a liability. We wrote about that trade-off on the [AI agents page](https://datanika.io/ai-agents/#portability); write tools are the point where it stops being theoretical.\n\nFull setup, the complete tool list, and the security model are in the [MCP server guide](https://datanika.io/docs/mcp-server/). If you're already connected read-only, re-authorize with a client that requests write scopes — the consent screen will show you the difference.\n\n*Datanika is an open-source data pipeline platform built on dlt and dbt-core. [Start free](https://app.datanika.io/) with 10 GB/month, or [self-host it](https://datanika.io/docs/self-hosting/).*", "url": "https://wpnews.pro/news/your-agent-can-now-change-things-if-you-say-so-once", "canonical_source": "https://dev.to/eu_ti_f127c5b5d7535b7174f/your-agent-can-now-change-things-if-you-say-so-once-4k0", "published_at": "2026-11-13 11:13:19+00:00", "updated_at": "2026-11-13 11:22:09.287558+00:00", "lang": "en", "topics": ["ai-agents", "agent-protocols", "ai-tools", "developer-tools"], "entities": ["Datanika", "MCP", "dbt"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/your-agent-can-now-change-things-if-you-say-so-once", "markdown": "https://wpnews.pro/news/your-agent-can-now-change-things-if-you-say-so-once.md", "text": "https://wpnews.pro/news/your-agent-can-now-change-things-if-you-say-so-once.txt", "jsonld": "https://wpnews.pro/news/your-agent-can-now-change-things-if-you-say-so-once.jsonld"}}