# Ironclad MCP access for legal team, governed

> How to set up Ironclad MCP access for legal team members in ChatGPT so contract search and reads work while signature-send and workflow approval stay blocked.

**TL;DR** Elaichi serves Ironclad through one organization-wide MCP endpoint, so a legal team can search and read contracts in ChatGPT under each member's own identity. Block the send-for-signature and workflow-approval tools by role, and freeze the workspace argument so the model never sees it. A restriction change takes effect within about two minutes, and the compliance reviewer reads the audit trail on a free Auditor seat.

## Ironclad MCP access for legal team: what ChatGPT actually gets asked to do

The first requests are reads. Find the MSA with the uncapped indemnity. List the agreements renewing in the next ninety days. Pull the notice period out of a vendor contract. All of that is search against the contract repository, and it is why Legal wants the connection.

The requests that arrive in week two are different in kind. Send this version out for signature. Approve the workflow step so the deal closes today. Those change the world outside the company, because a counterparty receives the result. Ironclad MCP access for legal team members has to separate the two kinds of request before the connection exists.

MCP (MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps) is how ChatGPT reaches Ironclad here. Elaichi serves every connected account through one organization-wide MCP endpoint, `POST /mcp`. You point ChatGPT at that single address through its admin console, and each member signs in with their own identity. There are no per-user URLs and no tokens pasted into a client.

## Why the setup starts with a restriction, not a connection

Because the default is allow-all. A restriction is a rule about which connectors and which individual tools a target may reach. Targets are role or user only. restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything, and the organization default is the absence of any rule, which means everything the connection exposes is reachable.

Connecting Ironclad and configuring nothing is a decision, not a neutral starting point. The Ironclad user behind the connection carries whatever rights that user has, and a model driving it inherits all of them.

Precedence is worth learning once before you write anything. A rule on a user replaces the role rules for that user rather than adding to them A user-targeted rule replaces role rules entirely rather than layering on top of them. Use the role rule for the team posture, and reserve user rules for a genuine exception.

## Which Ironclad tools to block before the first contract query

Block the operations that leave the building: sending a document out for signature, and approving a workflow step. For a read-heavy legal team, the rest can stay open.

You have two shapes available. A block list names the few operations you refuse and lets new read tools keep working as the Ironclad connector gains them. An allowlist names the reads you want and denies the rest, which is stricter and needs maintenance every time Legal asks for one more report. Within the winning layer, allow rules union, block rules union, and blocks always beat allows.

One trap is worth naming. the allowlist stage engages on the presence of an allow rule, not its contents, so an allow rule that names nothing denies everything. An allow rule that names nothing therefore denies everything. It is the strictest rule you can express, and it is almost always written by accident.

## Does a renamed tool get around the rule?

A block survives a rename. An allow does not, and the asymmetry is deliberate.

A rule is written against a connector and a tool, and the canonical resource and method are pinned against the catalog at write time. A block matches on the tool name or the pinned operation. An allow matches the pinned operation only. An advertised tool name can be changed by whoever edits the connector's documentation, so the name is a token the governed party controls. Governance binds the operation, never the label.

The practical consequence for Legal is small and specific. Express "do not send for signature" as a block, not as the absence of an allow. The full argument sits in [why a block matches the name and an allow matches the operation](/blog/block-matches-name-allow-matches-operation/).

## What Legal sees in ChatGPT once Ironclad is connected

Usually two tools, not fifty. Past a threshold of 30 tools, the connected tools collapse behind two meta-tools, `search_tools` and `execute_tool`.

The threshold counts catalog operations and connected tools together. The Elaichi control-plane catalog alone is dozens of operations, so one connected app normally trips it. Collapse is the normal case. Control-plane operations stay listed individually, and `search_tools` never returns one.

Two details matter for a legal rollout. Tools withheld by a restriction are excluded from the count, because they were handed to nobody, and the model cannot search for what it was never given. And `execute_tool` is only a naming indirection. It unwraps to the same name and the same arguments, and falls through the identical gates. There is no separate execution path and no privilege in it.

Ranking behind `search_tools` is lexical over the tool name, the description and the connector label, with a relevance floor: a tool must account for at least half the query's own IDF-weighted mass. A lawyer searching for a clause tool gets nothing rather than something from an unrelated app. The reasoning is in [the relevance floor in search_tools](/blog/search-tools-ranking-floor-idf/).

## Freezing the arguments Legal should not choose

Frozen parameters are a per-entry map over a tool's flattened argument space. They do two things. Frozen keys are stripped from the advertised schema, so the model never sees them. Frozen values are merged over caller arguments at execution, so passing the key cannot un-freeze it.

Full precedence runs entry defaults, then caller and model arguments, then frozen parameters. If the Ironclad connector takes a workspace or repository argument, freeze it to the legal workspace. ChatGPT then cannot widen the search by guessing an identifier, and nobody has to review every call to check that it did not.

## Where the Ironclad credential actually lives

Not in Elaichi. A separate credential service holds per-account secrets, encrypted at rest, and owns refresh. A failed refresh marks the connection `needs_reauth` rather than failing silently.

A connect URL is not a credential. It is a one-time session that carries no token, which is why it is safe to return over MCP. Read-back of an account's configuration returns public values plus `secret_paths`, the list of dot-paths that were encrypted, carrying none of their values. Editing one is refused.

An organization can supply its own OAuth app per connector. OAuth is the sign-in standard that lets a client act for a user without holding their password. The accepted body is `client_id`, `client_secret` and scopes, so everything endpoint-shaped is unrepresentable. It is gated on `connector:manage`, not `connection:manage`, so everyone who can delete a connection does not silently gain the ability to repoint the organization's OAuth app.

## Does the compliance reviewer need a paid seat?

No. Auditor is a free, read-only seat in Elaichi, so a reviewer who only reads the audit log does not consume a license.

Auditor sits off the role chain, and it lacks `tool:execute`. That permission gates the whole MCP endpoint ahead of every scope. Without it, `tools/list` comes back empty and a call returns an in-band error naming the missing permission. An Auditor cannot reach Ironclad at all, even where a restriction would have allowed the operation. Guest and Billing Admin are free in the same way.

Every member holds exactly one role, enforced by a unique index, which is why each role is a complete persona rather than a bolt-on. A working lawyer sits on Member and sees only what they own or what was explicitly shared with them. Billable seats are active memberships; Guest, Billing Admin and Auditor are excluded. Gold is $15 per user per month or $120 per user per year on [pricing](/pricing/).

## What the audit trail answers after an unexpected send

one entry per tool-call attempt, succeeded or failed, and both name the account actually reached. The recorded connection comes from the execution rather than from the intent, which answers the first question after a surprise: which Ironclad account did the agent write to.

`actor_kind` is a recorded field, not an inference. Its values include `user`, `system`, `scim`, `api_token` and `ai_assistant`, so whether an AI took the action is written at the point of action. Each record carries the operation and tool, the connection, the classification, whether the call was approved, the outcome, and an error code only.

Argument names and counts are logged. Argument values never are, so clause text a lawyer pushed through a tool does not end up in the log pipe. There is a second reason the log stays clean. Two error strings exist per failed call: the one returned to the caller is derived from the third party's response body, and the one written to the audit trail is never derived from the request or the response. Audit records are org-visible, readable by the in-product assistant and fanned out to whatever SIEM you configure, so a remote Ironclad error body reaching one would be third-party payload leaving through the log pipe.

The trail is append-only, newest-first and filterable by text, category, actor and time. It is eventually consistent, so a row may take a moment to appear. Export forwards to your own destination: Datadog is implemented, while Splunk HEC and Microsoft Sentinel are accepted but not yet delivering.

## Timing, joiners, and what happens when a lawyer leaves

A role or restriction change in Elaichi takes effect within about two minutes. Role membership and restrictions resolve through a 60 second cache plus edge propagation, on the MCP endpoint, the console and REST alike. Plan the change window around that, not around a single refresh.

Three things are effective on the next call instead: grant revocation, member removal and suspension. removing or suspending a member revokes every live grant in the same transaction as the membership change.

Joiners can come through SCIM v2 with group-to-role mapping, so adding a new lawyer to the legal group in your identity provider creates the member and assigns the role that already carries the Ironclad blocks. Invites, verified-domain auto-join and just-in-time SSO are the other three paths.

Offboarding runs a preflight. A personal Ironclad connection referenced by a toolbox entry must be resolved first, by transfer to the organization, a team or another member, or by deletion, or the removal is refused. A private connection is not transferable at all, because a credential only its owner could use does not become someone else's when its owner leaves. The same sequence for short-term staff is in [contractor offboarding AI access](/blog/shadow-ai-contractor-offboarding/).

## Contract text is input the model will act on

The prompt-injection write gate in the Elaichi agent window does not apply to `POST /mcp`, and it cannot. An MCP server never sees a user prompt. A clause drafted to read like an instruction is just text as far as the endpoint is concerned.

What does hold on the endpoint: RBAC per operation, the `forbidden` classification, output redaction, OAuth scope limits and full audit logging. Scopes run `mcp:read`, `mcp:write`, `mcp:destructive` and `mcp:tools`, and `mcp:tools` does not replace the ladder. A tool classified `forbidden` is reachable under no scope at all. That is the honest reason the signature-send block carries the weight here, rather than any filter on what a document says.

## Choosing a region before the first contract is indexed

Region is set at organization creation and cannot be reasoned about later. The three options are `eu`, `us` and `apac`.

`eu` and `us` are hard residency, implemented as a Cloudflare Durable Object jurisdiction, so compute and storage both stay in that jurisdiction. `apac` is a placement hint only. It is best-effort, and not a residency guarantee. The region also selects which regional log instance the organization's audit trail lands in, which matters when the trail records counterparty names.

## When a legal team does not need any of this

One lawyer, one Ironclad login, read-only rights on that login, and no reviewer asking who did what. In that case a restriction plane is overhead, and the client's own connector is enough. The threshold arguments are in [when an MCP gateway is still premature](/blog/when-you-dont-need-an-mcp-gateway/) and in [the comparison with native AI connectors](/blog/elaichi-vs-native-ai-connectors/).

The picture changes when a second client appears, when the Ironclad account has send rights, or when somebody has to produce an attributable record. It also changes if the alternative is running MCP servers yourself, which is costed out in [self-hosted MCP servers versus a control plane](/blog/self-hosted-mcp-servers-vs-control-plane/). For the same playbook in another team, read [how a sales team gets governed Salesforce access from ChatGPT](/blog/sales-team-chatgpt-salesforce-accounts/). More governance writing sits under [governance](/blog/category/governance/), the 450+ connectable accounts are listed in the [connector catalog](/connectors/), and the per-team starting points are on [use cases](/use-cases/).

## FAQ

### Can a legal team read Ironclad through ChatGPT without being able to send contracts for signature?

Yes. In Elaichi, a restriction names the connector and the individual tools a role or user may reach, so the send-for-signature and workflow-approval operations can be blocked while search and read stay open. Express the refusal as a block rather than as the absence of an allow: a block matches on the tool name or the pinned operation, while an allow matches the pinned operation only. Restriction targets are role or user; restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything, and the organization default is the absence of any rule, which allows everything.

### How long does an Ironclad tool restriction take to take effect?

about two minutes. Role membership and restrictions in Elaichi resolve through a 60 second cache plus edge propagation, and that applies on the MCP endpoint, in the console and over REST. Only three changes are effective on the next call: grant revocation, member removal and suspension, because removing or suspending a member revokes every live grant in the same transaction as the membership change.

### Does a compliance reviewer need a paid seat to read the audit log?

No. Auditor is a free, read-only seat in Elaichi, and it is excluded from the billable seat count along with Guest and Billing Admin. An Auditor lacks the tool:execute permission that gates the whole MCP endpoint, so tools/list comes back empty for that member and a tool call returns an in-band error naming the missing permission. Gold is $15 per user per month or $120 per user per year for billable seats.

### Does the audit log show which Ironclad workspace an agent wrote to?

Yes. Elaichi writes one entry per tool-call attempt, succeeded or failed, and both name the account actually reached, taken from the execution rather than from the intent. Each record carries the operation and tool, the connection, the classification, whether the call was approved, the outcome and an error code only. Argument names and counts are logged; argument values never are, so contract text passed as an argument does not land in the log.

### Is an MCP endpoint protected against instructions hidden in contract text?

No, and it cannot be, because an MCP server never sees a user prompt. The prompt-injection write gate lives in the Elaichi agent window and does not apply to a raw tool call. What does hold on the endpoint is RBAC per operation, the forbidden classification, output redaction, OAuth scope limits and full audit logging. For contract workflows, the control you rely on is a block on the operations that send or approve, not a filter on what a document says.

### What happens to a lawyer's personal Ironclad connection when they leave?

Elaichi runs a preflight before removal. A personal connection referenced by a toolbox entry must be transferred to the organization, a team or another member, or deleted, otherwise the removal is refused. Unreferenced personal connections are cleaned up. A private connection is not transferable at all, because a credential only its owner could ever use does not become someone else's when its owner leaves.

## Read next

- [NetSuite MCP access for finance team in Claude](/blog/finance-team-claude-netsuite-ledger/) — NetSuite MCP access for finance team work: read-only analysts, journal posting behind a user override, and an audit entry naming the subsidiary account reached.
- [HubSpot MCP access for marketing team, safely](/blog/marketing-team-chatgpt-hubspot-campaigns/) — How to set up HubSpot MCP access for marketing team use in ChatGPT: reads allowed, list deletion and bulk email send blocked, the portal frozen, every attempt logged.
- [Salesforce MCP access for sales team, done right](/blog/sales-team-chatgpt-salesforce-accounts/) — Salesforce MCP access for sales team, set up so reps see only their own accounts. Bulk update and mass delete are restricted at the operation, the owner field is frozen, and an audit query proves it.