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.
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.
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.
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.
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 and in the comparison with 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. For the same playbook in another team, read how a sales team gets governed Salesforce access from ChatGPT. More governance writing sits under governance, the 450+ connectable accounts are listed in the connector catalog, and the per-team starting points are on use cases.
