Connect 1Password to Claude, ChatGPT and Cursor with Governed Access

The ticket that started it read: "Priya's last day was Friday, please confirm her 1Password account is closed." It sat in the helpdesk queue for two days. The two IT admins who hold the 1Password service credential were both travelling, and nobody else in the company could confirm the account's state, let alone change it. It took two days because reading a user record and acting on it were welded into one credential held by two people.

Elaichi separates them. You connect 1Password once for the organisation, and the connector's operations become tools an agent can call. Helpdesk, security reviewers and People Ops all point Claude, ChatGPT or Cursor at the same organisation endpoint and sign in as themselves, and what each of them can invoke is worked out from their own role, their own shares and the restrictions written against them. Nobody borrows the credential. Nobody gets a second console login. A helpdesk agent can answer "is this account still active" without being able to suspend anything, and the admin who does suspend it leaves a row in an append-only log carrying the id of the record they touched.

One application, six sets of legitimate reach

1Password is the unusual case where every team argues over the same object: a user. What differs is what each of them is entitled to do with it.

IT owns provisioning and suspensions. For them a user is a lifecycle object, and they need both the read and the state change, because closing a leaver ticket means confirming the account exists and then suspending it.

Security runs account reviews and access checks. That work is almost entirely reading: pulling the roster, opening individual records by user id, asking which accounts look stale. A reviewer who can suspend accounts mid-review is a reviewer who can lock out a colleague by accident.

People Ops drives joiners and leavers. They are the trigger rather than the executor. The HR event is theirs, the suspension is IT's, and what they genuinely need is confirmation that a leaver's record reached the state it was meant to.

Helpdesk handles lookups and reactivations. Reactivation is the interesting one. It is a state change, but it is the safe direction of travel: an account wrongly reactivated is visible and reversible, while an account wrongly suspended cuts somebody off from every credential they own.

Compliance wants evidence. They need to show that a named account was suspended on a named date, and the user id in the record is what makes that evidence checkable rather than asserted.

Engineering cares about service account users and mostly wants to read them.

Six teams, one object family, six different boundaries. All of them legitimate.

Connecting 1Password

Open Connections, choose Add connection, pick 1Password, set Share with if you already know who needs it, and connect. You land on Connection added.

What does not happen is the point. This connector authenticates machine to machine. No vendor authorization window opens, there is no consent screen for anybody to read, and there is no per-person grant at any stage. A service credential is configured once, and from then on every call any employee makes runs as that one identity. 1Password sees a single caller. It does not see your helpdesk.

Let that set your expectations for everything downstream. With a user-consented connector, whoever approves the vendor's authorization screen fixes a ceiling that the vendor itself then enforces. Here no such ceiling exists. The credential's reach was decided by whoever created and scoped it, and 1Password will honour anything that credential is permitted to do, without any notion of which employee's agent asked. So the entire separation between one employee and another is Elaichi's to perform.

It gets performed in two places: the share on the connection, and the restrictions written against roles and members. Sharing is how people use the credential without holding it. Someone granted Use can run tools against this connection while being unable to open it, edit it, transfer it, or see it listed anywhere. Grant View to a lead who should know the connection exists without being able to run against it, and Edit only to whoever is trusted to change its settings and its sharing. That delegation is re-resolved against the owner every time it is used, so when the owner's own access disappears, everything hanging off it disappears too.

Which makes ownership a real decision. Put it with someone who will still be here in a year.

Which tools anyone should see

The 1Password catalog is four tools, and they sort into two object families that deserve different default answers.

The first family treats the user as something to read. list_all_1_password_users returns the roster. get_single_1_password_user_by_id returns one record once you have the id. They compose the way you would hope: list, find the person, open the record. Nearly every question anybody actually asks about 1Password is answered inside this family. Who was added this month. Whether Priya's account is still live. Which accounts belong to contractors. This is the sensible default for the widest audience, covering security, compliance, engineering, People Ops and helpdesk. Reading a roster of people your company already employs is not a privileged act.

The second family changes the user's lifecycle state. 1_password_users_suspend and 1_password_users_reactivate are that family. Neither deletes anything, and that shapes the risk: suspension is reversible, which is precisely why it is safe to delegate and precisely why people get casual about it. The damage from a wrong suspension is not lost data, it is a colleague locked out of every password they hold, at whatever hour an agent decided to act.

Split the two rather than treating them as a matched pair. Reactivation restores access for somebody who is already an employee and is telling you loudly that they cannot log in. It is self-correcting and helpdesk-shaped. Suspension removes access, usually as the step of an offboarding that feels irreversible even though it is not, and it belongs with the team that owns offboarding. Handing both to the same audience because they are opposites is the common mistake.

A workable default: the reads go to everyone who touches user access, reactivation goes to helpdesk and IT, and suspension goes to IT alone.

Building a toolbox for each team

A template is a reusable definition. It holds the tool entries you want and their per-tool overrides, with no connection attached. A toolbox is connection-bound and is what MCP clients actually talk to. Stamping a template produces a toolbox and binds connections to its entries; anything left unbound shows as needs connection and will not run.

Three templates cover the whole company here.

A review template carries list_all_1_password_users and get_single_1_password_user_by_id, and nothing else. Stamp it, bind the 1Password connection, share the resulting toolbox with Security, Compliance and Engineering at Use.

A helpdesk template carries both reads plus 1_password_users_reactivate. On the reactivate entry, rewrite the description to state plainly that this restores a suspended account and should follow a verified identity check, because that description is what the model reads when deciding whether to call it. Share the toolbox with Helpdesk at Use.

An IT template carries all four entries, including 1_password_users_suspend, and goes to the IT team.

Two habits are worth forming. Share the template itself at View with leads who need to understand what their team can reach, and at Edit only with whoever may change it. And treat stamping as a copy taken at that moment: a toolbox is a snapshot, so editing the template afterwards leaves toolboxes already stamped from it untouched. When you tighten a template, work through the toolboxes stamped from it and restamp on purpose. Entry lists cap at 200, which no 1Password toolbox approaches, though a mixed toolbox carrying your directory and ticketing connectors alongside it can.

Governing it, restrictions first

Shares decide what a person is offered. Restrictions decide what the platform lets through regardless of what they were offered, and for a machine-authenticated connector they are the more important half. Write them before you write the shares.

A restriction is an allow-list or a block-list over connectors and individual tools, aimed at a role or at one named member. There is no organisation-level version, and the absence is deliberate: the general case goes onto roles, the exceptions go onto people.

The shape that fits 1Password is an allow rule on the Member role naming only the two read tools. Every employee can then ask whether an account exists and in what state, and no employee can change one, whatever toolbox reached them and whoever shared it. The people who suspend and reactivate get member-level rules of their own.

Two properties to internalise first. A member-level rule replaces the role's rule instead of layering over it, so the exception you write for an IT admin has to restate everything that admin needs, the reads included. That replacement behaviour is why writing member-level rules carries its own permission. And an allow rule that names nothing denies everything, which is the strictest statement the system can make and a genuinely useful thing to aim at a contractor role.

Enforcement runs at four points: when a connection is made, when tools are listed, when one is called, and on the outbound request itself. Matching uses the tool's original catalog name, so renaming an entry to something friendlier inside a toolbox does not move it out of a rule's reach.

One timing fact. Role and restriction edits read a snapshot that can lag by roughly a minute, sometimes two, so tightening a restriction is not instant. Revoking a share, disconnecting the connection, or removing the member is effective on the very next request. When somebody has to be stopped now, revoke rather than rewrite.

One endpoint, resolved per person

Your organisation has a single MCP endpoint. Copy it from the Connect your AI client dialog and give everybody the same string. There is no per-person URL and no per-team variant. Setup in each client is manual: a person pastes a URL into a settings screen.

At connection time the client asks for consent by scope. The scopes are Read, Create and change, Delete, and Run tools, and only Read starts enabled. Anyone who needs to suspend or reactivate an account has to turn on Run tools deliberately. Leaving it off yields a client that answers questions and cannot act, which is the right configuration for most of the company.

Once attached, what the client sees is resolved from the person holding it. Two colleagues using the same endpoint in the same client get different tool lists, because their roles, shares and restrictions differ.

Plan for one behaviour. Past 30 advertised tools, counting Elaichi's own operations together with your connected ones, names stop being listed and the client is given search_tools and execute_tool instead. That search ranks lexically rather than by meaning, so entry names should contain the words your people would actually type. Narrow per-team toolboxes are the simplest way to stay under the threshold.

Connect 1Password to Claude

In Claude, open Settings, go to Connectors, and choose Add custom connector. Paste your organisation's endpoint from the Connect your AI client dialog and sign in. On Claude Team and Enterprise only an Owner may add a custom connector, so this tends to be done once by the workspace owner rather than by each person individually. At the consent step grant only what the person needs: Read alone for security reviewers and compliance, Read plus Run tools for the admins who suspend and reactivate. Then ask Claude to list all 1Password users added this month, and check the tools it offers match the toolbox shared with that person.

Connect 1Password to ChatGPT

In ChatGPT, open Settings, go to Apps, turn developer mode on, choose Create, paste your organisation's endpoint, then run Scan tools to pull in what is available to you. This path exists on Business, Enterprise and Edu plans and is web-only, so expect people to set it up in a browser rather than in a desktop or mobile app. Grant Read for lookups and add Run tools only for those who need suspension or reactivation. A good first check is asking for the 1Password user record for a named colleague and confirming the result matches what you can see yourself.

Connect 1Password to Cursor

Cursor reads MCP servers from a JSON file. Add an entry under mcpServers in ~/.cursor/mcp.json to make the connection available in every project, or in a repository's .cursor/mcp.json to scope it to that codebase. The value is your organisation's endpoint, copied from the Connect your AI client dialog. This configuration is per machine, so an engineer with a laptop and a desktop configures both, and a replacement machine starts empty. For engineers reading service account users, Read is normally the only scope worth granting; a coding session has little reason to suspend anyone's account.

Day two

Machine credentials get rotated, expire, or are revoked by whoever is tidying the vendor console. When that happens the connection breaks for everyone at once, because everyone was always running as the same identity. Reconnect repairs it in place, so toolboxes bound to it keep working and nothing needs restamping. Route notifications to Slack or email so the owner hears about a failure before the helpdesk does, and forward the audit log to Datadog if that is where your team already watches.

Offboarding has two halves worth keeping straight. Suspending the 1Password account is one. Removing the person from your organisation in Elaichi is the other, and that lands on the next request rather than after a delay. Do both.

Access requests are the pressure valve for a restriction-first setup. A helpdesk agent who hits a denial on suspension should ask for it rather than be handed the IT toolbox, and the asking leaves a record.

The audit log covers tool calls, memberships, roles and teams, connections and transfers, toolboxes, shares, restrictions and sign-ins, and for a call that changed a record it keeps that record's id. Arguments and results are not recorded, because a payload is your data. It is eventually consistent, so allow a row a moment to appear before deciding it is missing. Give compliance reviewers the Auditor role, which is one of the roles that does not consume a billable seat.