Buyer guide
The security checklist for Claude connectors
You are the person who has to sign off on this. Here is the concrete list of what to verify before any connector touches a production system.
Before giving Claude access to your tools, verify seven things: authentication runs through OAuth as a real user account, permissions are inherited from that account and never exceed it, read and write tools are separated, destructive actions are gated behind human approval, access is revocable at the identity provider, data handling is documented, and someone owns maintenance.
Key takeaways
- The connector should authenticate as a real user account via OAuth, never a shared master credential.
- Access is bounded by the account: Claude inherits its permissions and can never exceed them.
- Deletes, sends, and payments must sit behind a human confirmation, not flow automatically.
- You should be able to revoke access instantly at the identity provider or in the tool itself.
What should a security reviewer check before approving a Claude connector?
Check the seven areas below in order: how it authenticates, what permissions it inherits, whether reads and writes are separate tools, which actions are gated, how you revoke it, where it runs and what it stores, and who maintains it. If any item fails, that is the conversation to have before approval, not after.
This is the checklist as a whole. Each item gets its own section below with what a passing answer looks like.
- 1Authentication: OAuth as a real user account, no shared master credentials or long-lived master API keys.
- 2Permission scoping: the connector inherits the connected account's permissions exactly and can never exceed them.
- 3Read/write separation: reads and writes are distinct tools, so read access can be granted without write access riding along.
- 4Gating on destructive actions: delete, send, and payment actions require a human confirmation before they execute.
- 5Revocability: access can be cut off immediately at the identity provider or inside the tool, with no residual path.
- 6Data handling: you know where the connector runs, what it stores, and what it does not store.
- 7Maintenance ownership: a named party patches the connector when the underlying APIs or auth requirements change.
None of this is exotic. It is the same review you would run on any third-party integration, applied to one where the caller is a model acting on a user's instructions.
How should a Claude connector authenticate?
It should authenticate through OAuth as a real, individual user account in your system, the same way a person signs in. Reject designs built on a shared master credential or an org-wide API key, because those collapse every user into one identity with one blast radius and no per-person audit trail.
The connectors we build authenticate as the user's own account via OAuth. That single design choice does most of the security work: identity is individual, sessions are standard, and everything downstream (permissions, audit, revocation) keys off machinery your systems already have.
Questions to ask of any connector, ours included:
- Does each user connect their own account, or does everyone share one credential?
- Is the grant a standard OAuth flow your identity provider can see and manage?
- Are tokens stored encrypted, and are they scoped to the user who granted them?
- Does activity in the target system attribute to the individual user, so audit logs stay meaningful?
What permissions does Claude actually get through a connector?
Exactly the permissions of the account it authenticates as, and nothing more. The connector cannot see a record, folder, or client that the connected account cannot see, and it cannot perform an action the account is not allowed to perform. Your existing role model is the boundary, unchanged.
This is the property to verify hardest, because it means the connector adds no new access to your environment. It gives an existing, already-governed identity a new interface, a conversation, instead of a screen.
The practical test: take the account you plan to connect, list what it can and cannot do under your current roles, and confirm the connector's reach matches that list exactly. If a vendor asks you to elevate the account's permissions to make the connector work, that is scope creep to push back on. The right fix is a narrower connector, not a wider account.
Read/write separation belongs in the same review. Reads and writes should be distinct tools, so you can approve a read-only connector first and add specific write paths later as separate, reviewable decisions rather than one bundled grant.
Which actions need a human in the loop?
Anything destructive or outbound: deletes, sends, and payments. These should be gated so Claude can stage the action but a person confirms it before it executes. Creates and updates to internal records can flow inside the conversation if you choose, but the irreversible and external actions must not.
The distinction is consequence. An update_record call on an internal field is visible, attributable, and correctable. A delete_record, a sent email, or a record_payment is not something you take back. The gates go where the consequences are.
In the connectors we build, destructive and outbound actions are gated behind a confirmation by default, and you decide during the build which additional writes should also require approval. The gate is enforced in the connector, not left to prompt instructions, so it holds regardless of what the conversation asks for.
Gates belong in the connector, not the prompt
A prompt that says never delete anything is a suggestion. A connector that requires a human confirmation before delete_record executes is a control. Verify the gate is enforced in code before you approve write access.
How do you revoke Claude's access if something goes wrong?
The same way you cut off any user: revoke the OAuth grant at the identity provider, disable the account, or revoke the connection inside the tool itself. Because the connector authenticates as a real account, any of those acts immediately and completely, with no separate credential left behind to hunt down.
Revocability is the reason the OAuth-as-a-real-account model matters so much. There is no shadow credential outside your identity system. Verify all three paths work before approval:
- Identity provider: suspending the user or revoking the app grant kills the connector's access at the source.
- The tool itself: revoking the connected app's authorization in the target system's settings cuts it off there.
- The connector: disconnecting or disabling the connector configuration stops it end to end.
Run the drill once during review. Revoke, confirm the connector's calls fail, then re-grant. Five minutes now beats discovering an untested revocation path during an incident.
Where does the connector run and who maintains it?
You should get concrete answers to both. Know where the connector is hosted, what it stores, ideally credentials encrypted and little else, and what it does not retain. And a named party must own maintenance, because upstream APIs change and an unmaintained connector fails either quietly or unsafely.
On data handling, the questions are plain: where does the connector run, what does it persist, and for how long? A connector needs to hold credentials to act on a user's behalf; those should be encrypted at rest. Business data flowing through a request should pass through, not accumulate in a shadow copy of your systems. Get the answer in writing and check it against your data residency and retention requirements.
On maintenance, the failure mode is slow. The connector works at approval time, then an API version is deprecated or an auth requirement changes months later. Our model pairs the one-time build with ongoing maintenance so a named party is on the hook for exactly this. If you are reviewing any connector, from anyone, the question is the same: when the upstream API changes, who patches this, and under what commitment?