Every time we’ve talked about MCP — what it is, what it means for people managing forms — the same question eventually comes up: does this mean I’m handing an AI company my business data?
It’s a fair question, and the honest answer requires understanding a few mechanics that aren’t actually complicated once someone walks you through them. So let’s walk through them.
How the connection actually works, without the jargon
When you “connect” an AI assistant to a tool through MCP, nothing about your password changes hands. Here’s the sequence, in plain terms:
- You click connect, and you’re sent to the actual login page of the tool you’re connecting — not a page controlled by the AI assistant.
- You sign in there, the same way you always do.
- You’re shown the access or permissions the connection is requesting, and you approve or decline them.
- The assistant receives a token, not your password. A token is like a guest key card: it opens the specific doors you approved, it can be cut off at any time, and it doesn’t tell anyone what your actual key looks like.
This pattern is called OAuth, and it’s the same mechanism behind “Sign in with Google” buttons you’ve clicked a hundred times. MCP didn’t invent it — it borrowed a system that’s already been battle-tested across the internet for two decades.
What the assistant can actually see
This is the part people worry about most, so it’s worth being specific rather than reassuring in the abstract.
An AI assistant connected through MCP can only use the capabilities and data that the connected server makes available under the permissions you’ve granted. If you approved “read forms and submissions,” it can read forms and submissions — not your billing information, not other tools you use, not anything outside that specific tool. If you didn’t grant write access, it can’t submit or change anything, full stop. Worth being clear about, though: those permissions govern what the assistant is allowed to reach — they’re not, by themselves, a guarantee that everything within that scope will be handled safely, which is why the next section matters just as much as this one.
And critically: what the assistant reads to answer your question doesn’t just sit around afterward. On PlatoForms’ own MCP server, for instance, each request is handled and then forgotten — there’s no separate copy of your form or submission data being quietly stored somewhere for later. The data lives in your account, the same place it always did.
The part that’s genuinely worth being careful about
None of this means “connect anything to anything and stop thinking about it.” Agent permissions have become a live topic of public discussion lately, and for good reason — there’s one real risk worth naming clearly here: not every MCP server is reviewed or vetted by the AI assistant you’re using. When you connect a custom or newly published one, you’ll often see a plain warning along the lines of “this application is unverified — only continue if you recognize where this is going.” That warning exists for a reason, and it’s worth reading instead of clicking past.
The practical version of “being careful” looks like this:
- Only connect servers from providers you actually recognize and trust — the same instinct you’d apply before typing your password into any website.
- Read what access is being requested before you approve it. If a form tool is asking for permissions that have nothing to do with forms, that’s worth pausing on.
- Know that you can revoke access at any time, the same way you can remove a “Sign in with Google” connection you no longer use.
- If your organization handles regulated data, check whether the tool restricts AI integrations for that specific type of data — this is common enough that it’s worth confirming rather than assuming.
There’s a related risk worth naming too, separate from permissions entirely: a trusted connection can still expose an assistant to untrusted content. If a form submission, document, or message retrieved through an MCP server contains text written to look like an instruction, an assistant reading it could be misled into treating that text as something it should act on. This isn’t a flaw specific to any one tool — it’s a known risk across AI systems that read content from external sources, sometimes called prompt injection. It’s a reason to keep an eye on what happened after a connection, not just what was approved at the start — legitimate permissions don’t automatically mean everything that flows through them is safe to act on without a second look.
We didn’t just take PlatoForms’ word for how this behaves — we tested it directly. We connected an AI assistant to a PlatoForms account and then deliberately tried to have it reach a form that belonged to a different, unrelated account. It couldn’t. The request was blocked outright, as expected from the account-level permission boundary: an assistant only ever sees what the account it’s connected to is actually allowed to see, nothing more.
There’s a second layer of control worth knowing about, too — this one lives on the AI assistant’s side rather than PlatoForms’. Some AI assistants let you approve individual actions one by one rather than granting blanket permission, so you can allow the ones you’re comfortable automating and block a specific one you’re not. We tested this by turning off permission for a single action (submitting entries to a form) while leaving everything else available. In a fresh session, that one action wasn’t just refused when attempted — it disappeared entirely from what the assistant could offer to do, while the rest of the connection kept working normally. It’s worth knowing this control exists, even though it’s a feature of the assistant you’re using rather than something PlatoForms itself enforces.
The short version
The underlying authorization mechanics aren’t new or experimental — they build on established OAuth patterns already widely used across the web, the same kind sitting behind most “connect your account” buttons you click without thinking twice. What’s new is what’s on the other end of the connection: an AI assistant instead of another app. That’s worth a moment of attention the first time you set one up, and after that, it works the same way any authorized connection does — visible, scoped, and something you can turn off whenever you want.
🛠️ Curious what this looks like in PlatoForms specifically? Visit the MCP overview for the full picture, see our MCP integration guide for the exact permissions requested at connection time, or browse what you can ask your assistant once it’s connected.
A few things people usually ask:
Can the AI assistant read things I never explicitly shared with it? No. It can only access what falls within the scope you approved when you connected it.
What happens if I disconnect it later? The connection is removed, and the assistant can no longer use it to access that tool. Depending on the implementation, the underlying access token is typically revoked as well.
Does the AI company keep a copy of my data forever? That depends on the AI provider’s own policies, since they process what the assistant reads under their own terms — but on the tool side, a well-built MCP server shouldn’t be storing a duplicate copy of your data just for having answered a request.
Is this different from just giving someone my login? Yes, meaningfully. A shared login gives full access indefinitely. A scoped token gives specific access that you can see, limit, and revoke.
