Managing MCP permissions and read-only scopes

The questionnaire arrives as a spreadsheet. Nine rows, no small talk. Between your team's enthusiasm and a working connection sits a security review, and an engineer you have never met decides how long it takes.

Answer them thinly and the request waits a quarter in somebody's queue. Answer them completely, in the first message, and the ticket becomes a paste instead of a project.

So here are the questions security teams send, in the order a reviewer reaches them. The subject is the MCP connection: the standard that lets an AI assistant read a data source directly, so your team asks questions in the assistant instead of exporting spreadsheets.

The short version: it signs in with your existing account, reads and never writes, sees only your organization, and logs what it did.

How does the connection sign in?

In your browser, with credentials you already have.

Sign-in runs on OAuth 2.1 with PKCE. Your AI client never sees a password or an API key. No long-lived secret sits in a chat tool's settings, which removes the leak class security teams worry about most.

Tokens expire quickly and carry a cryptographic signature. Refresh tokens rotate on every use. You can revoke them.

When a reviewer asks about token lifetime and storage, those are the answers, and the docs' security section gives them in the reviewer's own vocabulary rather than a marketing one. If your team has ever spent a weekend rotating a leaked API key, this is the part built for you.

What can it actually do?

Read. That is the list.

The connection carries one permission called quattr:read, a single read-only scope that can query analyses and read results and never change anything. The blast radius of a compromised session stops at what you can already see in a browser.

Access inherits from your Quattr account and goes no further. Somebody without access to a dataset in the app does not acquire it through the assistant. The connection is a window onto the same account, opened with the same identity.

It also settles the prompt-injection question, which is the newest line on most checklists and the one reviewers are least sure how to score. An instruction smuggled into content the assistant reads could at worst trigger more reads of data the user already sees. It cannot exfiltrate credentials the client never held, and it cannot write, because no write path exists.

Where does your data stay?

Inside your organization. The data layer enforces it.

Results come from your organization's data and nobody else's. Every result carries the company it belongs to, so somebody holding several accounts can see whose numbers are on screen. A conversation stays pinned to one organization.

Client access runs on an allowlist. Approved clients today are Claude on web and desktop, Claude Code, ChatGPT, Cursor and VS Code. The server rejects anything else before it reaches data.

It also keeps a durable log of every call, per user and per organization. Reviewers ask for that audit trail third.

The nine questions, mapped

Reviews converge on the same list. We have watched an enterprise security team send nine formal questions, and they are the nine every reviewer reaches eventually.

Most are answered above or in the docs. The manifest is the published tool list. Tokens expire quickly and rotate. Access mirrors your account roles. A read-only scope bounds what any injected instruction could do, since a connection that cannot write cannot be made to write.

Two depend on your contract rather than the design: retention specifics and subprocessors. The honest answer is to ask. A vendor who answers quickly is telling you something as useful as the answer.

One caution belongs in every review, whatever the vendor. Your assistant processes results under its own provider's terms, so that policy is part of your compliance picture too, separate from any data connection.

The nine, grouped the way a reviewer reads them:

• The tool manifest, token lifetime, and where tokens live
• What personal data is in scope, plus MFA and role-based access
• Retention, subprocessors, and how the connection handles prompt injection

The approval path, in practice

Send the reviewer's homework before the reviewer asks for it.

That means the security section of the docs plus the eight-question evaluation from the piece on evaluating MCPs, pre-answered, in the first message rather than the fourth. Reviews go fastest when the checklist arrives filled in.

After approval, connecting takes minutes per person, in the browser, with nothing to install. The enterprise wait was never the technology. It was the queue.

There is a side effect worth having: the champion who walks in with that sheet becomes the person security calls first the next time any AI request lands.

The workflow card below is a useful artifact for the review itself, a worked example of one question answered end to end. It shows a data answer in flight, carrying its scope and its as-of date, the date that data was last complete. That settles the what-does-it-actually-see question faster than a diagram.

See also: the eight questions to ask before you connect anything →

The workflow that does this: AI assistant referrals →

What does IT actually risk here?

A read-only window onto data the requesting user already sees in a browser.

Opened with existing credentials, from an allowlisted client, with server-side logs behind it. Give that answer in exactly those words, because the bound is the point.

The residual risks are the generic ones of any SaaS-plus-AI workflow, and your organization already manages those with the policies it applies to the assistant itself, so nothing in this connection asks anyone for a new category of policy.

Which is why the review is worth doing well once. The same answers cover every surface it runs on and every teammate who connects after the first, so the next client is a diff rather than a restart.