Guide
MCP governance for teams: what security asks before Claude can write
Letting an assistant write to production systems is a governance decision, not just a technical one. These are the questions security teams actually ask, and the connector design decisions that answer each one.
Before Claude writes to a business system, security teams need six answers: who approved write access and its scope, which actions are gated behind human confirmation, where changes are audited, whether each user authenticates individually, how tokens are scoped and revoked, and whether the rollout can start read-only. A well-built MCP connector answers all six by design.
Key takeaways
- Write access should be an itemized grant someone approved, not a blanket permission: separate read and write tools, exposing only the actions chosen.
- Destructive actions like delete and send should wait for a human-in-the-loop confirmation; create and update stay visible and reversible inside the tool's own history.
- Per-user OAuth beats shared credentials: each person's connector inherits exactly their existing permissions, and every change is attributed to them in the tool.
- Read-only-first rollouts turn one big trust decision into a series of small, reviewable ones, with each write action added as its own scoped grant.
Who approves write access, and how is it scoped?
Write access should be an explicit, itemized grant, not a blanket permission. In a custom connector, read and write tools are separate, and each write action is a deliberate scoped addition someone signed off on. The connector exposes only the actions chosen, even where the underlying API could technically do more.
The governance failure mode is a connector that quietly holds every permission its API key allows. The fix is structural: build read and write as distinct, narrowly scoped capabilities, so the approval conversation happens per action, in concrete terms a security reviewer can evaluate.
That gives the review a real artifact. Instead of approving Claude access to the CRM, the team approves a list: search and read these objects, create and update these, nothing else. The connector cannot drift beyond that list, because the tools beyond it were never built.
It also gives you a clean answer to the who-approved-this question later: the scope document is the approval, and anything outside it is by definition not something the connector can do.
Which actions should be gated behind human confirmation?
Gate the irreversible ones. Create and update run inside the tool's own history and permissions, so they are visible and reversible like any team member's change. Delete and send are different: they leave the building or destroy data, so they wait for an explicit human-in-the-loop confirmation before anything executes.
The useful dividing line is reversibility, not writing itself. A created record can be edited, an updated field has history, and both stay inside your tool's own permission model. An email that has been sent or a record that has been deleted cannot be pulled back.
In a gated design, Claude proposes the risky action, shows exactly what it is about to do, and waits. The person approves or declines. Nothing irreversible happens on the assistant's own judgement, which is precisely the assurance a security review is looking for.
Gates are policy, not friction
Which actions are gated is a decision you make when the connector is scoped, alongside which actions exist at all. Teams commonly gate delete and send everywhere, and add gates on writes their own workflow treats as sensitive.
Where is the audit trail when Claude writes to a system?
Primarily in the system itself. Because the connector writes through the tool's real API as an authenticated account, every change appears in that tool's native history and audit logs, the same place your team's changes already live. Anything gated also has a human approval in the conversation record before it ran.
This is one place governance gets easier, not harder. A connector does not bypass your tool's change tracking; it goes through the front door of the API, so the record history, activity feeds, and audit exports you already rely on capture its writes like anyone else's.
With per-user auth, those entries carry the actual person's identity. Combined with the gating step, the trail for a sensitive action reads: proposed by Claude in a conversation the user started, approved by that user, executed as that user's account, recorded in the tool. Each link is checkable in systems you already have.
How are tokens scoped, stored, and revoked?
Tokens should carry the narrowest scopes the chosen actions require, be stored securely by whoever hosts the connector, and be revocable from the tool's own account settings. Revoking the grant, rotating the credential, or removing the connector in Claude cuts access immediately. No build should ever lock you in.
Scoped tokens are the enforcement layer under the scoped toolset: even if a tool exposed more than intended, the credential itself cannot exceed the grant. Requesting the narrowest scopes the work requires should be the default, not an option.
Revocation matters just as much as scoping, because it is your unilateral exit. A well-run connector gives you three independent kill switches: remove it inside Claude, revoke the OAuth grant in the tool's account settings, or rotate the credential. Any one of them ends access immediately, without a support ticket to anyone.
Why start with a read-only rollout?
Because trust is earned action by action. A read-only connector lets the team watch Claude work with live data while nothing can change, which gives security a low-stakes review period. Write actions are then added one at a time as deliberate, scoped grants, each with its own approval, instead of a single all-or-nothing decision.
Read-only-first converts an abstract risk debate into an observed track record. The team sees what Claude actually does with the tool for a few weeks: what it queries, how it reasons, where it is useful. By the time the first write action is proposed, the conversation is about a specific capability with evidence behind it.
It also sets the pattern for everything after. Each subsequent write is a small, reviewable addition with a clear owner and scope, which is exactly the shape a governance process can approve quickly. The alternative, one big yes-or-no on full write access, tends to produce either a long stall or a grant nobody fully reviewed.