What can Legal do with Ironclad contracts in ChatGPT?
Legal can find and read Ironclad contracts in ChatGPT through Elaichi. With one block on the legal role, nothing asked there can push a contract toward signature. The first requests are reads: which vendor agreements are still in review, who launched the MSA for a given counterparty, how far along a renewal is. Elaichi's Ironclad connector answers them from Ironclad's workflows. The list_all_ironclad_workflows and get_single_ironclad_workflow_by_id tools return each contract's title, template, current step, status and the values entered for its fields.
The requests that arrive in week two are different in kind. Send this version out for signature. Approve the step so the deal closes today. Those change the world outside the company, because a counterparty receives the result. Elaichi's Ironclad connector has no tool that approves a step or sends a signature packet. It sits in the e-signature category, and its few writes are what Legal blocks.
MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. Elaichi serves every connected account through one organization-wide MCP endpoint, POST /mcp, and ChatGPT reaches Ironclad through it. In ChatGPT, full MCP support with write actions is a beta on Business, Enterprise and Edu plans (OpenAI's help article, as of October 2026). On those plans, an admin creates the app under Workspace settings > Apps and publishes it to the workspace. Pro users can connect with read and fetch permissions only, in developer mode. Each lawyer then signs in with their own grant, and connecting Elaichi to ChatGPT walks through the steps.
Why does the setup start with a rule, 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. In Elaichi, restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything.
Sharing Ironclad with Legal 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. Write the rules first and share the connection second.
Every lawyer's call through a shared connection reaches Ironclad as the connection's owner, so Ironclad scopes results to that one user and its own log names that user. Share it only if that user's Ironclad access fits all of Legal; otherwise have each lawyer connect their own account.
Learn precedence once before you write anything. A rule aimed at a member can only narrow what their role allows, and never replaces or loosens a role rule. Use the role rule for the team posture, and use a user rule only to narrow one person. A lawyer who needs a tool the role blocks files an access request instead, and an admin approves it for that person alone.
Which Ironclad tools should Legal block?
Block all four writes the connector carries: create_a_ironclad_workflow and create_a_ironclad_async_workflow, which launch a workflow, ironclad_workflows_cancel, which cancels one, and delete_a_ironclad_user_by_id, which deletes an Ironclad user. The reads stay open.
Launching is the one that matters for signing. In Ironclad, a workflow "consists of a contract and all the business processes needed to execute it, such as approvals and signatures" (Ironclad's help center). The same article says "Once all approvals have been collected, a signature packet is prepared". The connector cannot approve a step or send that packet, so through it, a launch is the only road from ChatGPT toward signature. Block the launch tools, and that road is closed.
Signing can also start outside Ironclad. If DocuSign is connected too, create_a_docusign_envelope can send an envelope the moment it creates one, and update_a_docusign_envelope_by_id can send a draft. Block both on the same legal role, and the promise holds across apps.
Two shapes are available. A block list names the few tools you refuse and lets new read tools keep working as the Ironclad connector gains them. The cost is that a write the connector gains later is open until someone blocks it. An allowlist names the reads you want and denies the rest, which is stricter and needs upkeep every time Legal asks for one more report. Within each layer, allow rules union, block rules union, and blocks always beat allows.
One trap catches people. In Elaichi, the allowlist stage engages on the presence of an allow rule, not its contents, so an allow rule that names nothing 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?
No. A block matches the name or the operation, and an allow matches the operation, so renaming a tool changes neither.
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. Whoever edits the connector's documentation can change a tool's advertised name, so the name is a token the governed party controls. Governance binds the operation, never the label.
For Legal the consequence is small and specific: write "do not launch" as a block, not as the absence of an allow. The full argument is in the case for matching blocks on names and allows on operations.
What does Legal see in ChatGPT once Ironclad is connected?
No Ironclad tool by name. In Elaichi, connected tools are never listed one by one, however few there are. ChatGPT finds an Ironclad tool with search_tools and calls it through execute_tool. Elaichi's own control-plane operations stay listed individually, and search_tools never returns one.
A restricted tool is withheld from the tool list and cannot be called. Once Legal's block is saved, a search for create_a_ironclad_workflow names it, flagged restricted, with no schema.
Search also has a relevance floor, so a lawyer looking for a clause tool gets nothing rather than something from an unrelated app. The reasoning is in the relevance floor in search_tools.
Which Ironclad arguments should Legal freeze?
Often none, while Legal only reads. Frozen parameters matter the day you open a write. They are a per-entry map over a tool's flattened argument space, set on a toolbox entry (one tool tied to one connected account). A frozen key is removed from the schema ChatGPT is shown. A frozen value is merged over the caller's arguments at execution, so passing the key cannot un-freeze it.
Suppose legal ops wants ChatGPT to start NDAs and nothing else. Build a toolbox with the reads and create_a_ironclad_workflow, and freeze that entry's template argument to your NDA template. Ironclad's API calls that field "The identifier of the workflow template" (Ironclad's API reference), and the template identifiers come from list_all_ironclad_workflow_schemas. The lock binds only calls made through the entry. Share the toolbox with Legal in place of the Ironclad connection, and only then lift the block on create_a_ironclad_workflow, keeping the one on the async launch. That reopens one road toward signature, through Ironclad's own Review step and the reviewers your administrator configured, so decide it on purpose.
Where does the Ironclad credential live?
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.
Ironclad is one of the connectors where you bring the OAuth app. The Ironclad connector page asks an admin, once, for the client ID and secret of an app registered in Ironclad. 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 anything shaped like an endpoint is unrepresentable. It is gated on connector:manage, not connection:manage, so everyone who can delete a connection does not quietly gain the power 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 use 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 allow the tool.
A working lawyer sits on Member and sees only what they own or what was explicitly shared with them. Billable seats are active memberships, with Guest, Billing Admin and Auditor excluded. Gold lists at $15 per user per month in USD, or $120 per user per year, and the pricing page shows the price in your region.
What does the audit trail show after an unexpected change?
The trail holds one entry for each connected-tool call that reaches execution (a call refused earlier writes none). Every entry records the Ironclad account the call reached, taken from what executed rather than from what was asked.
The actor_kind field is recorded, not inferred. Its values include user, system, scim, api_token and ai_assistant, which marks only the Elaichi Agent. A call from ChatGPT is recorded under the person who signed in, with surface mcp and the OAuth client named, and ChatGPT is marked verified. Each record also carries the operation and tool, the connection, the classification and whether the call was approved, with its outcome and an error code only.
The trail logs the one path argument that names the object, as the target id, and nothing else about the arguments, so clause text a lawyer pushed through a tool does not reach the log pipe. The error text it stores is never derived from Ironclad's response either, because audit records are visible across the organization and readable by the in-product assistant.
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. The trail inside Elaichi is on Gold. Beyond the in-app trail, export to your own Datadog comes with the Black plan, which is launching soon. Elaichi accepts Splunk HEC and Microsoft Sentinel as destinations but delivers events only to Datadog.
How fast do changes land, and what happens when a lawyer leaves?
A role or restriction change in Elaichi takes effect within about two minutes, on the MCP endpoint, the console and REST alike.
Grant revocation, member removal and suspension take effect on the next call instead. In Elaichi, 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. Adding a lawyer to the legal group in your identity provider then 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. It lists every Ironclad connection the departing lawyer owns, private and shared alike. A private connection that a shared toolbox still relies on blocks the removal until it is transferred to another active member, never to the admin running the removal. A private connection nothing else depends on cannot be transferred and is deleted with the lawyer. A shared connection Legal still depends on is left untouched unless the admin deletes it, so transfer it to a lawyer who is staying and every grant on it stays as it was. The same sequence for short-term staff is in contractor offboarding AI access.
Can a clause in a contract steer ChatGPT?
It can try, and the endpoint never sees the attempt. The prompt-injection write gate lives in the Elaichi agent window and does not apply to a raw tool call. An MCP server never sees a user prompt, so a clause drafted to read like an instruction is just text as far as the endpoint is concerned.
The endpoint does enforce role permissions per operation, redacted output, limits set by OAuth scopes, and an audit row for each call that reaches execution. A tool classified forbidden is reachable under no scope at all.
Client prompts are a second, weaker layer. The MCP specification says a person should always be able to deny a tool call (MCP specification). OpenAI's article adds that "For write or modify actions, ChatGPT may ask for confirmation" (OpenAI's help center). "May" is not a control you can show an auditor. The block on launching is, which is why it carries the weight here rather than any filter on what a document says.
Which region should Legal choose before the first contract?
Choose before you create the organization, because the region is fixed then. Elaichi has three regions, EU, US and APAC. For EU and US, the organization's data store and the execution of its org-scoped requests and tool calls stay in that jurisdiction. APAC uses best-effort placement and is not a residency guarantee. The audit trail is stored in one EU log instance for every region. Pick the region that matches where your contracts and your counsel sit.
Why not use Ironclad's own MCP server?
Ironclad's own MCP is the simpler path if Ironclad is the one app Legal will query. Ironclad says it "now connects with ChatGPT, Claude, and Slackbot via MCP" (Ironclad's MCP announcement, checked October 2026). Its page adds that "Results are scoped to each user's permissions". That is Ironclad's own permission model applied per user, with no second vendor in the path.
Elaichi's case is the rest of Legal's stack. One address serves Ironclad, DocuSign and Salesforce, in ChatGPT, Claude and Cursor alike. The block on launching and on sending envelopes is written once for the legal role and covers every app it names. A frozen argument, such as a fixed template, holds a value the model cannot change. One audit trail spans every app Legal reaches, and one removal ends a departing lawyer's access through Elaichi to all of them. Their accounts inside each app are a separate step. Ironclad's page does not describe those cross-app controls, and they are what a second vendor has to earn.
When does a legal team not need any of this?
One lawyer, one Ironclad login, read-only rights on that login, and no reviewer asking who did what. Then a restriction layer is overhead, and Ironclad's own MCP or the client's built-in 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 can launch workflows, 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 600+ connectors are in the connector catalog, and the per-team starting points are on use cases.
