The owner of a small business hears about AI every week. The sales lead wants it for follow-ups. The office manager wants it for invoices. Somebody suggests hiring an AI consultant. The hard part is telling a consultant who will change how the week runs from one who will deliver a slide deck and leave.

What should an AI consultant for small business actually do?

Some AI consultants stop at a plan. A useful AI consultant for small business goes further: it learns how your team works, picks one job for AI, sets it up in the apps you already use, and stays until your team uses it. The deliverable is a working setup in your own accounts, not a report.

Most small firms are still at the start. The U.S. Census Bureau found that less than 20% of firms with four or fewer employees reported using AI, against 37% of firms with at least 250 employees. One likely reason is capacity. Large firms often have people whose job is to connect new tools to old systems. A small firm usually has an owner, an ops lead and a few team leads, all busy with the real work.

So a consultant for a small or mid-size business has a different job from one who advises a large enterprise. Strategy matters less. Setup, testing and handover matter more. Judge the consultant by the jobs that AI does for your team three months later.

How do you pick the first job for AI?

Pick a job that repeats every week, lives in apps you already use, and is easy to check. A good first job saves hours, and a person can see in one glance if the AI got it right.

Use three tests:

• It repeats. The same steps happen every day or every week, such as copying data from one app to another.
• It lives in your apps. The facts the AI needs are already in your CRM (the app that holds your customer records), your accounting software, your support desk or your HR app.
• It is easy to check. A person can review the result quickly before it goes anywhere important.

Good first jobs look different by team. Sales can get a short brief before each call, built from the CRM and past emails. Support can get a draft reply that a person checks before it is sent. Finance can match invoices to orders and flag what is overdue. Operations can track orders and suppliers across apps and flag late ones. HR can answer common questions from the HR app and set up new hires across tools.

The industry changes the apps, not the method. A distributor might start with dealer questions about stock. A law or accounting firm might start with time tracking and client updates. An online store might start with returns and order questions. Leave payroll changes and payments for later, when your team trusts the setup.

What should you prepare before the first call?

Prepare a short list of the jobs that eat the week, the apps each job touches, and the names of two people. One person does the work every day. The other is an admin who can connect your apps and approve a plan.

For each job, write down three things. How often does it happen? How long does it take? What goes wrong when it is late or wrong? Rough numbers are fine. They help the consultant rank the jobs, and they give you a baseline to measure against later.

List every app the job touches, including spreadsheets and shared inboxes. Note who has admin access to each app. Many projects slow down in week one because nobody can approve an app connection.

Also note the AI assistant your company already pays for, if any. A setup that ignores it means a second subscription and a second place for people to work.

What does a good first engagement look like?

A good first engagement has five steps: learn the work, write a one-page plan, set it up in your real apps, test it with the people who do the work, and hand over with a written guide. Each step has something you can see and approve.

1. Learn the work. The consultant talks to the people who do the job, not only the owner. They ask what takes the most time and what an error costs.
2. Write a one-page plan. The plan says which jobs the AI takes over, which apps it needs, who can use it, and how you will know it works. You approve it before any setup starts.
3. Set it up in your real apps. The consultant connects your actual CRM, support desk or accounting software, not a copy or a demo account. The AI gets only the access the plan names.
4. Test with the people who do the work. Your team runs real tasks and reports what is wrong. The consultant fixes it and tests again.
5. Hand over with a written guide. The guide covers how to add people and apps, change who can do what, and check what the AI did.

The plan in step 2 protects you. It turns a vague goal into a scope you can check. If a consultant wants to skip it, the scope will drift and so will the cost.

Which questions should you ask an AI consultant?

Ask four questions, and expect clear written answers. Who owns what is built? Where is our data stored? Does it work with the AI assistant we already pay for? What happens after handover?

Who owns what is built? The instructions, the app connections and the results should live in accounts you control. If they live in the consultant's own tools, you rent your own process.

Where is our data stored, and who can see it? Ask which region holds your data and which companies process it for the consultant. When a consultant handles personal data for you, it is usually a processor under data protection law. The UK regulator's guidance lists what a controller and processor contract must include, such as acting only on your documented instructions and deleting or returning the data when the contract ends. Ask for those terms in writing.

Does it work with the AI assistant we already pay for? Many AI assistants can connect to other apps. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. A setup built on that open standard keeps working if you change assistants later.

What happens after handover? Your admins should be able to add a person, remove a person and check the activity log without a call to the consultant. Ask to see the written guide from a past project.

What are the red flags in an AI consultant?

The main red flags are a plan with no named job, a demo built on sample data, and a setup that only the consultant can run. Any one of these means the AI is unlikely to reach daily use.

Watch for these signs:

• The proposal talks about "AI strategy" for pages and names no job, no app and no person.
• The demo uses made-up data, and the consultant avoids a test in your real apps.
• The AI gets admin access to every app, when the job needs only one or two.
• Nobody can tell you what the AI did last Tuesday, because nothing is logged.
• The work lives in the consultant's accounts, and leaving means starting over.
• The handover is a meeting, not a document.

Unapproved AI use is a related risk. A Federal Reserve note says "shadow AI", meaning use without approval, may still be a substantive problem for organizations. A consultant who sets up approved access with clear limits gives your team a safe path instead of a workaround.

When do you not need an AI consultant?

You may not need an AI consultant if the job is small, one person does it, and that person is comfortable setting up tools. Many AI assistants can already draft emails or summarize documents with no setup at all.

A consultant also fits poorly if you only want a strategy report. In that case, a strategy consultant is the better choice, and you can decide on setup later. The comparison of AI consultants and automation agencies covers which option fits which need.

Bring in help when the job crosses several apps, touches customer or employee data, or needs to keep running after the person who set it up moves on. That is where most do-it-yourself pilots stall.

Where does Elaichi Services fit?

Elaichi Services is AI consulting, automation and integration delivered by Elaichi's forward deployed engineers, who work directly with your team instead of from a distance. They follow the same steps and hand over a setup that you own.

The engineers connect AI to the apps you already use, from a catalog of 700+ apps covering CRM, accounting, support, HR and project tools. If you use an app Elaichi does not support, they add it. The setup works with any AI assistant that supports MCP, so you keep the assistant you already pay for. Elaichi never sees your conversations with the AI.

The AI can only use the apps and actions you allow for each person. The actions it runs are recorded in your activity log. When you sign up, you pick EU, US or APAC for your company's Elaichi data, and for EU and US the data store stays in that region, and the security page explains what is stored where. The setup, the instructions written for your AI, and everything it produces live in your own Elaichi account and apps. After handover, you remove the engineers' access.

To see example jobs by team before a call, browse the use cases or check your apps in the connector catalog. The full plan is on the page about AI consulting and automation services, and you can read why AI pilots stall after the demo.

FAQ

What does an AI consultant do for a small business?

A good AI consultant for a small business finds one repetitive job, such as copying orders between apps or answering the same customer questions, and sets up AI to do it inside the apps the business already uses. The consultant then tests it with the people who do that job and hands over a written guide, so the business can run it without the consultant.

How do I choose the first task to automate with AI?

Choose a task that repeats every week, lives in apps you already use, and has a result a person can check in a minute. Examples are drafting replies to common support tickets, flagging overdue invoices, or writing a short brief before a sales call. Avoid a first task where one mistake is costly or hard to spot.

What questions should I ask an AI consultant before hiring one?

Ask four things. Who owns what you build? Where is our data stored, and who can see it? Will it work with the AI assistant we already pay for? What happens after you hand over? Clear, written answers to all four are a good sign. Vague answers to any of them are a reason to keep looking.

Who owns the AI setup that a consultant builds?

The business should own it. The instructions, the app connections and everything the AI produces should live in accounts the business controls, not in the consultant's own tools. With Elaichi Services, the setup lives in the customer's own Elaichi account and apps, and the customer owns it.

AI consultant vs AI automation agency: what is the difference?

An AI consultant tells you what AI should do in your business, and an AI automation agency builds specific automations for you. That is the short answer to AI consultant vs AI automation agency, but most business owners actually face four choices, not two.

Picture the situation. Your team copies data from one app to another by hand. The same customer questions arrive every week. Someone rebuilds the same report every Monday. You want AI to take that work off their plate, and you are not sure who to call.

The four options are an AI consultant, an AI automation agency, automation software your own staff set up, and forward deployed engineers. A forward deployed engineer (FDE) is an engineer who works directly with your team and builds inside the apps you already use. Each option fits a different need, and each one has a weak spot.

What does each option actually give you?

Each option leaves you with something different at the end: a plan, a set of automations, a tool, or a working setup. The table compares them on the questions a business owner usually asks first.

Costs vary by scope for all four. Compare them on what you hold at the end, not only on the first quote.

When does hiring an AI consultant make sense?

An AI consultant is the right hire when you do not yet know what AI should do in your business. A good consultant talks to your leaders, looks across the company, and writes a plan: which jobs to start with, which risks to manage, and what to measure.

That plan has real value when the stakes are high or the leaders disagree. A board asking for an AI strategy, or a merger that changes every system, needs thinking before building.

The weak spot is what happens next. A plan does not answer a customer or close a ticket. Someone still has to build what it describes, connect it to your apps, and get your team to use it. Ask any consultant who will do that work, and when it starts.

When does an AI automation agency make sense?

An AI automation agency fits when you already know the tasks you want automated and want them done quickly. The agency builds each automation, tests it, and hands it back, usually as a short project.

This works well for a few clear, separate tasks. Think of a web form that should create a record in your CRM, or a weekly report that should build itself.

Watch three things. First, where each automation lives. Some agencies build on their own accounts and tools, so the work can leave with them. Second, what happens when one of your apps changes and an automation breaks. Third, who can see and change what each automation does. Ask for the work to sit in accounts your company owns, and for a list of every app login the agency used.

When should you buy automation software and build it yourself?

Building it yourself makes sense when you have technical people with real time to spare. Automation software gives your team the building blocks. Your staff connect the apps, design each step, and fix things when they break.

The benefit is control. Nothing depends on an outside firm, and your own people learn the tools.

The cost is time, and it does not stop after launch. Apps change, people leave, and someone has to own every automation. Building alone is also harder than it looks. MIT's NANDA initiative found that buying from specialized vendors and partners succeeded about 67% of the time, while internal builds succeeded about one-third as often (Fortune).

When do forward deployed engineers make sense?

Forward deployed engineers fit when you want advice and a working result together, and you do not want to hire an AI team. They learn the work with your people, then build inside your real apps.

The role comes from software companies with complex products. Palantir describes its forward deployed software engineer as someone who "embeds directly with our customers" (Palantir). In a 2025 essay, the venture firm a16z said forward deployed teams exist "to operationalize the model into a real-world solution" (a16z). In plain words, they turn AI into something your team uses every day.

Elaichi Services works this way. Elaichi's engineers start with a call with the people who do the work. They write a one-page plan, and you approve it before they start. Then they connect your apps, teach the AI how your team does each job, and decide who can use what. Elaichi connects to 700+ apps, and if you use one it does not support, the engineers add it. Your team tests the setup on real work, the engineers fix what is off, and your admins get a written guide.

The setup works with whichever AI assistant your company has chosen. If you switch assistants later, the work comes with you.

The weak spot is your time. Someone who does the work every day has to join the calls, and an admin has to connect your apps and approve the plan.

Why do so many AI projects stall after the demo?

Most AI projects stall because the AI never gets into the daily work, not because the model is weak. The numbers are blunt.

Gartner predicted that at least 30% of generative AI projects would be abandoned after proof of concept by the end of 2025 (Gartner). Gartner named poor data quality, weak risk controls, rising costs and unclear business value as the causes.

This matters for your choice. A plan alone does not close that gap, and neither does an automation nobody looks after. Whoever you hire, ask three questions. How will the AI reach the apps where the work happens? Why will your team trust it with company data? Who looks after it once the demo is over? The longer answer is in why AI pilots stall before daily use.

What should you check before you hire anyone?

Four checks protect you whichever option you pick: ownership, access, records and handover. Ask about each one in the first meeting.

• Ownership. What gets built should live in your accounts and your apps, not the provider's.
• Access. The AI should use only the apps and actions you allow for each person.
• Records. Every action the AI takes should land in an activity log, a record of who did what and when, that you can read later.
• Handover. When the project ends, you should be able to remove the provider's access and keep running.

Elaichi Services answers each check the same way. The customer owns the setup, the instructions written for its AI, and everything the AI produces. The AI can only use the apps and actions you allow for each person. The actions it runs are recorded in the activity log, including the engineers' own work, and you remove their access at handover. Pick EU, US or APAC when you sign up. For EU and US, Elaichi's data store for your company stays in that region. The security page has the details.

How do you decide in five minutes?

Answer three questions in order, and stop at the first yes. Each yes points to one option.

1. Do you still need to decide what AI should do across the company? Hire an AI consultant.
2. Do you have technical people with time to build and maintain automations? Buy automation software and build it yourself.
3. Do you want a few clear, one-off automations, built once? An AI automation agency fits.

If all three answers are no, you want AI doing ongoing work in several apps, without an AI team of your own. That is the case forward deployed engineers are built for. A small business weighing this for the first time can also read what an AI consultant does for a small business.

When is Elaichi Services not the right choice?

Elaichi Services is the wrong choice when you only want a strategy report. If the thing you need is a document for your board, hire a consultant. Elaichi's engineers set up working AI in your apps, so a plan on its own is not what they deliver.

Elaichi Services is also a poor fit when nobody can give the project time. The engineers need someone who does the work every day and an admin who can connect your apps. If neither person is free, wait until one is.

Two more cases point elsewhere. If your own technical team has time and wants to own every step, automation software may suit you better. If your work does not live in apps at all, AI in your apps will not help much.

When the work does live in apps, start with the jobs teams already hand to AI on the use cases page, check your apps in the connector catalog, and see how a CRM fits in connecting AI to your CRM.

FAQ

What is the difference between an AI consultant and an AI automation agency?

An AI consultant gives you advice and a written plan for where AI fits in your business, and usually stops there. An AI automation agency builds specific automations for you, often as a short project. Pick a consultant when you do not yet know what AI should do. Pick an agency when you already know the tasks and want them built quickly.

What is a forward deployed engineer (FDE)?

A forward deployed engineer is an engineer who works directly with a customer's team instead of from a distance. The engineer learns how the work is done, builds the solution inside the customer's own apps, tests it on real work, and stays until the team uses it. The role started at software companies with complex products and is now common in AI work.

Should a small business build AI automations itself?

Only if it has technical people with real time to spare. Automation software gives a team the building blocks, but the team has to connect the apps, design each step, and fix things when an app changes. A small business without that capacity usually gets further by bringing in outside help that builds in its own accounts and then hands over.

Who should own the automations an outside firm builds?

Your company should. Ask for every automation to live in accounts and apps your company controls, for a list of every app login the firm used, and for a written guide at handover. Then remove the firm's access when the project ends. Work that lives in a provider's own accounts can leave when the provider does.

Your platform team put an AI gateway in front of OpenAI and Anthropic last quarter. Every model call from the company's own apps now passes through it, with a budget per team and a log of each prompt. Then support asks for Claude with access to Zendesk, and finance asks for ChatGPT with access to Xero. The first thought is that the gateway already handles AI traffic. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps.

The AI gateway vs MCP gateway question comes down to which traffic each one sees. An AI gateway sees prompts on their way to a model. An MCP gateway sees tool calls on their way to an app. A company that builds on models and also rolls out AI clients to staff has both kinds of traffic, and each gateway answers a different question about it.

AI gateway vs MCP gateway: what is the difference?

An AI gateway sits between your applications and the model providers they call. An MCP gateway sits between AI clients, such as Claude, ChatGPT and Cursor, and the tools those clients call in other apps. One governs the request for an answer. The other governs the action taken after it.

An AI gateway, also called an LLM gateway (LLM is short for large language model), answers questions about models. Which model got this prompt, what did it cost, and is the team over budget? An MCP gateway answers questions about people and tools. Which apps may this person's agent reach, whose account does a call run on, and what did each call touch? An agent here is an AI client acting for a person.

What does an AI gateway control?

An AI gateway controls traffic from your code to model providers: routing, caching, rate limits, spend and logs. Its user is usually a developer whose application sends prompts.

Cloudflare's AI Gateway overview (checked October 2026) describes visibility and control over AI apps. It lists caching, rate limiting, request retries and model fallback, and its analytics count requests, tokens and cost. Cloudflare's logging page says each log can include the prompt, the response, token usage and cost.

Other products share the shape. The LiteLLM AI Gateway is a self-hosted server that gives applications one OpenAI-compatible endpoint across model providers. Each user, team or project gets a virtual key with its own models, budgets and rate limits, and the gateway records the cost of each request. Portkey's AI Gateway docs, which carry the name Prisma AIRS AI Gateway as of October 2026, list budget limits on cost or tokens, rate limits on requests or tokens, caching, and fallbacks between providers. Both pages were checked October 2026.

Look at what all of them key on: an application, a key, a model and a token count. The caller is code you wrote, holding a key you issued.

What does an MCP gateway control?

An MCP gateway controls what an AI client may do in other apps once the model decides to act. It signs each person in, decides which tools that person may reach, attaches the right account's credential, and records the call.

The traffic is different in kind. Under the MCP specification, a client runs a tool with a tools/call request, the MCP message that runs one tool, which carries the tool's name and its arguments. There is no model choice to route, no prompt to cache and no token bill to count. What there is to govern is a person, a tool and an account.

That gives an MCP gateway three questions to answer on every call:

1. Which apps and tools may this person's agent reach?
2. Whose credentials does the call run on: the person's own account, or one shared with them?
3. What is the record afterwards: who called which tool, on which account, and did it work?

Products answer those three in different ways, and the four shapes of MCP gateway sorts them by who runs the servers and who writes the connectors.

What does each gateway see, control and record?

Each gateway sees one kind of request, and its controls and records follow from that. The AI gateway column follows Cloudflare's AI Gateway docs and LiteLLM's docs, checked October 2026.

Read the last row as the test. If the question after an incident is about a model bill, it is an AI gateway question. If it is about a changed record in Salesforce, it is an MCP gateway question.

Why can an AI gateway not see an employee's tool calls?

Because the tool call does not pass through it. An AI gateway sees the model requests pointed at it. A tool call is a separate request, and it goes to an MCP server, not to a model provider.

Claude is a clear case. Anthropic's custom connector guide (checked October 2026) says Claude connects to a remote MCP server from Anthropic's cloud, on every Claude client, the desktop and mobile apps included. That request leaves Anthropic and lands at the MCP server. A model gateway in front of your own apps is not on that path.

The blind spot runs the other way too. An MCP gateway never sees the person's prompt, because a tools/call request does not carry it. Elaichi's MCP endpoint, for example, reads only a tool name and arguments from each call. Prompt logging and spend tracking belong on the model side. Each gateway is blind to the other's traffic, so one does not replace the other.

Can one product be both an AI gateway and an MCP gateway?

Yes. Several products cover both kinds of traffic, but they still answer two separate sets of questions. Buying one product does not merge the jobs.

Kong's AI Gateway documentation (checked October 2026) describes one control plane for LLM, MCP and agent-to-agent traffic, with a single endpoint you can define for any of the three. The LiteLLM AI Gateway also gives access to MCP tools, with the same keys and spend records as model calls. Portkey documents a separate MCP Gateway that proxies between MCP clients and MCP servers, and handles authentication, access control and logging. Both of those pages were checked October 2026.

A combined product suits a platform team that already runs it for model traffic and wants one system to operate. Before you count it as your MCP gateway, put the three tool questions to it. Who writes and maintains the tools for each SaaS app? Does a call carry a named person, or a key? Which account at the app did the call actually reach? The Kong and Cloudflare comparison works through those answers for two vendors. For gateways that put MCP on top of existing APIs, read API gateways with MCP against MCP-native servers.

Where does Elaichi fit: AI gateway or MCP gateway?

Elaichi is an MCP gateway, not an AI gateway. It is a governed MCP control plane and hosted MCP gateway. Every call from an AI client passes through it and is checked against the caller's access, and every call that reaches execution is written to the audit log. It does not sit between your code and a model provider, and its endpoint receives tool calls, never the person's prompt.

Claude, ChatGPT, Cursor or any MCP client signs in to one endpoint, https://api.elaichi.ai/mcp. An endpoint is the one address every client points at, and Elaichi's is the same for every organization. Each person approves their own OAuth grant, the sign-in record that lets a client act as one named person. Every call then acts as that person. Behind the address sit 600+ connectors. Elaichi authors and runs most of them, governs vendors' own MCP servers for the rest, and lets a team bring its own remote MCP server under the same rules.

Elaichi's answers to the three tool questions are specific. Restrictions, rules set on a role or on one member, decide which connectors and which individual tools a target may reach. A call runs on one connection: the person's own account, or a shared one, which runs on its owner's account. Credentials sit in a separate credential service, and the AI client holds only an Elaichi token. Each call that reaches execution is written to the audit log, the append-only record of calls. The entry names the person, the tool, the connector, the account the call actually reached, the MCP client and the outcome.

Changes in Elaichi land on a known schedule. A role or restriction change takes about two minutes to apply. Removal is faster. In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change, so the person's AI clients fail on the next call.

When does a company only need an AI gateway?

When AI at the company means your own software calling models, and no one's AI client acts in company apps. In that case an MCP gateway has no traffic to govern.

Picture a product team that ships a summary feature and a support chatbot inside its own app. The code calls OpenAI and Anthropic. The tools the model uses are functions in the same codebase, called by the team's own code. Staff do not connect Claude or ChatGPT to Salesforce or Zendesk. That team needs routing, fallback, budgets and prompt logs. An AI gateway covers all of it, and Elaichi would add nothing.

The answer changes when staff start connecting AI clients to company apps. A second client arrives, two people share one app account, or someone leaves while their AI client still holds access. When an MCP gateway is premature lists those signals in full.

When do you need both, and how do you split them?

You need both when you build on models and also give staff AI clients that act in company apps. Split by traffic, not by team: model calls go through the AI gateway, and tool calls go through the MCP gateway.

Here is a common split. Jake Morgan's platform team keeps an AI gateway in front of the models its product calls, with a budget per team. Emily Carter in IT rolls out Claude and ChatGPT to support and finance through an MCP gateway. Each person signs in with their own grant, and each app call is recorded. Neither gateway needs to know about the other.

Keep each control in one place. Spend caps live on the model side. Which apps a person may reach lives on the tool side. A rule set in both places drifts, and the copy that gets updated is the one somebody remembers. To see which apps the tool side already covers, browse the connector catalog or the team rollouts.

FAQ

What is the difference between an AI gateway and an MCP gateway?

An AI gateway, also called an LLM gateway, sits between applications and model providers. It routes prompts to models, caches responses, rate-limits requests, tracks token spend and logs prompts. An MCP gateway sits between AI clients such as Claude, ChatGPT and Cursor and the apps they act in. It decides which tools each person may reach and which account a call runs on, and it records each tool call. A company that builds on models and also gives staff AI clients needs both.

Can an AI gateway control which tools an AI agent can use?

Only for traffic that passes through it. An AI gateway sees the model requests pointed at it. When an employee's Claude or ChatGPT calls a tool in Salesforce or Zendesk, that call goes to an MCP server, not to a model provider. Some products, such as Kong AI Gateway (https://developer.konghq.com/ai-gateway/), LiteLLM (https://docs.litellm.ai/docs/simple_proxy) and Portkey (https://portkey.ai/docs/product/mcp-gateway), also handle MCP traffic (vendor docs checked October 2026). Ask each one which person and which app account a tool call runs as.

Is Elaichi an AI gateway or an MCP gateway?

Elaichi is a governed MCP control plane and hosted MCP gateway, not an AI gateway. Claude, ChatGPT, Cursor or any MCP client signs in to one address, https://api.elaichi.ai/mcp, and each call acts as the person who approved the grant. Elaichi serves 600+ connectors, checks each call against the person's access, and writes each executed call to an audit log that names the account it reached. It receives tool calls, never the person's prompt.

Do we need an MCP gateway if we already run an AI gateway?

Only if staff connect AI clients to company apps. If AI at your company is your own code calling models, an AI gateway covers routing, budgets and logs, and an MCP gateway has nothing to govern. Once people use Claude, ChatGPT or Cursor to act in apps such as Salesforce or Zendesk, the questions become which tools each person may reach and on whose account. A model gateway does not answer those.

Composio vs Zapier MCP: what is the real difference?

Composio vs Zapier MCP comes down to what each product extends. Composio extends an agent platform with a gateway that companies can put in front of their staff. Zapier MCP extends a person's Zapier account into their AI client. The two differ on the billing unit, on who holds the app credentials, and on what one person's access looks like.

An IT lead is asked to let sales, support and finance use Claude and ChatGPT with the company's apps. Two names come up first. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. Both Composio and Zapier MCP speak it, so the question is how each one fits a company rollout, and where a different design fits.

The Composio column follows Composio's own pages and the Zapier MCP column follows Zapier's own docs, all checked October 2026. Each cell links the page it comes from, such as composio.dev/enterprise and Zapier MCP security.

What are Composio and Zapier MCP each built for?

Composio is built first for people who build agents, and Zapier MCP is built for people who already work in Zapier. Composio's homepage speaks to two audiences. One wants Claude or ChatGPT to act in their apps; the other builds agents on the Composio Platform (composio.dev, checked October 2026).

Composio Connect is a shared MCP URL, connect.composio.dev/mcp, that reaches its apps through 7 meta-tools. When an agent first needs an app, the person approves an OAuth link in the browser (Composio Connect docs, checked October 2026). The company-facing piece is the MCP Gateway. The gateway has an endpoint of its own, and each team gets one scoped to the tools it may use. SSO (one company login for every app) verifies the user before any tool resolves (Composio MCP Gateway, checked October 2026).

Zapier's help article describes Zapier MCP as the link between a person's MCP client and their Zapier account. Its tools run on the same app connections and actions that the person's Zaps use (What is Zapier MCP, checked October 2026). Zapier's own comparison page frames the split the same way. It calls Zapier a "no-code AI orchestration platform" and Composio a "developer-first integration and authentication layer" (Zapier vs. Composio, checked October 2026).

How do Composio and Zapier MCP charge for usage?

Composio charges for tool calls, and Zapier MCP spends tasks from a Zapier plan. Composio's pricing page counts each tool execution once and leaves meta tools such as tool search free. Trigger events, premium tools and usage-based add-ons are billed as well (Composio pricing, checked October 2026).

The same Composio page lists three plans (checked October 2026):

• Hobby: $0, with 100,000 tool calls, 50,000 triggers and 3 team members a month (pricing).
• Pro: $29 a month, with a $29 usage credit that expires at the end of each billing month, and unlimited team members (pricing).
• Enterprise: custom terms. SSO, SCIM and customer-managed keys sit here, not on Hobby or Pro (pricing).

Zapier MCP has no separate MCP bill. It runs on the person's existing Zapier plan, and each successful tool call uses two tasks at a fixed rate. Failed calls use none (Zapier MCP usage and billing, checked October 2026). A call that finds a HubSpot contact and a second call that emails them through Gmail use four tasks between them.

Both bills move with how much the AI does. Elaichi's bill moves with headcount instead, and the trade-offs of each meter are set out in the per-seat and per-call pricing breakdown.

Who keeps the app credentials in Composio and Zapier MCP?

In both products the vendor keeps the app credentials, so the AI client never holds a third-party API key. Zapier says it holds the app credentials for Zapier MCP. On the OAuth path, the MCP client stores and refreshes its own OAuth token (how Zapier MCP connections work, checked October 2026).

The case to watch in Zapier MCP is the connection token. A client off Zapier's supported list, or a person's own code, connects with one instead. Zapier describes it as long-lived and bound to one server, and anyone holding it can run that server's tools. Zapier's docs say to treat it like a password (Zapier connections page, checked October 2026).

Composio's Enterprise page says credentials are stored AES-256 encrypted and decrypted inside Composio's execution layer. Developers do not handle raw credentials, and the model does not see them (composio.dev/enterprise, checked October 2026). A deeper read is in the Composio security review.

Elaichi keeps app credentials in a separate credential service, encrypted at rest with AES-256-GCM. It fetches them into memory only for the call that needs them. The MCP address carries no credential, and the AI client holds only an Elaichi token, sent in a header.

How does each person get access in Composio and Zapier MCP?

Zapier MCP gives each person their own servers, while Composio's gateway gives each team its own endpoint alongside the gateway's own. In Zapier MCP every client uses the same endpoint. Each person owns their own servers on the Zapier account, usually one per named MCP client (Zapier connections, checked October 2026).

An organization rollout lets an admin make Zapier available in the MCP client. Each member still signs in to Zapier and runs tool calls as themselves (Zapier MCP rollout, checked October 2026). Sharing a server with teammates needs a Team or Enterprise plan. It lets them review or manage its tools, not run them as the owner (Zapier server access, checked October 2026).

What happens to a member's servers when they leave is not documented on Zapier's MCP security, server access or usage pages (checked October 2026). Put that question to Zapier before a rollout.

Composio's MCP Gateway page lists SAML or OIDC single sign-on and SCIM 2.0 (automatic user provisioning from a directory). SCIM maps directory groups to teams and revokes access at offboarding (Composio MCP Gateway, checked October 2026). Composio's pricing page lists shared connection tool calls as a metered add-on. In those, other users reuse one connected account (Composio pricing, checked October 2026).

What can an admin restrict and review in each one?

Composio documents permissions per user and per role, and Zapier MCP inherits Zapier's account-wide restrictions. Composio's Enterprise page says admins set permissions down to a single action. The rules are checked in the request path, before the model is involved. Each call is logged with the user, team, tool, action and outcome, including calls that policy denied (composio.dev/enterprise, checked October 2026).

The Composio gateway adds two details. Members can ask for tools they cannot reach, and admins approve or deny centrally. Tool-call payloads are not stored, and audit records hold metadata, kept for 7 days to 1 year (Composio MCP Gateway, checked October 2026). Elaichi's audit log has one limit to compare: it writes a row for each call that reaches execution, succeeded or failed, and a call refused before that point, for example for a tool a restriction withholds, writes no row.

Zapier MCP enforces app and action restrictions set at the Zapier account level. Those restrictions cannot be set for Zapier MCP alone; they apply across every Zapier feature. With Zapier Workspaces, admins can allow or restrict Zapier MCP for specific users and set task quotas per workspace. The History tab shows tool calls per user, and superadmins can review any user's. MCP events also reach the account audit log (Zapier MCP security, checked October 2026).

What is the third option for a company-wide rollout?

The third option is a governed MCP control plane: one hosted MCP gateway that every employee's AI client signs in to. Elaichi is built that way. Every person connects Claude, ChatGPT, Cursor or any MCP client to one address, https://api.elaichi.ai/mcp. They sign in over OAuth, the standard flow that hands a client a token instead of a password. Each person approves their own grant, the record that ties one client to one person. Every call then acts as that person.

Elaichi serves 600+ connectors. It authors and runs most of them itself. The rest are native MCP connectors, where the app's vendor builds and runs its own MCP server and Elaichi handles sign-in, access and audit. A team on Gold can also add its own remote MCP server under the same rules. In Elaichi, connected tools are never listed one by one, however few there are. The model finds a tool with search_tools and runs it with execute_tool.

Admins restrict whole connectors or single tools for a role or for one member, and a block always beats an allow. A role or restriction change takes effect within about two minutes. In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change, so a removed or suspended member's clients stop on their next call. A member who needs a restricted tool can file an access request from the client, and an admin decides it in the console.

Every call that reaches execution writes one audit row, succeeded or failed. A call refused earlier, for example for a tool a restriction withholds, writes no row. Everyone can see their own activity in the audit log. People with the audit permission see the whole organization, and the read-only Auditor role does not take a billable seat. Gold lists at $15 per user per month in USD, or $10 billed annually. The pricing page lists SAML or OIDC SSO and SCIM on Gold. Gold starts with a 14-day trial and needs no card to begin.

When is Composio or Zapier MCP the right answer?

Composio fits when seats do not map to your employees, for example when the tool users are your own customers. Zapier MCP fits when your team already runs on Zapier. Composio's Enterprise page says it maps an agent and its end user to a connected account. That account may belong to an employee or to the customer's own customer (composio.dev/enterprise, checked October 2026). That fits a product team putting tool access inside something it sells.

Choose Composio when:

• You are building an agent into your own product, and seats do not map to employees.
• You need an app that Composio lists and the Elaichi catalog lacks.
• You want a separate endpoint per team, or self-hosting, which Composio's Enterprise page offers (composio.dev/enterprise, checked October 2026).

Choose Zapier MCP when:

• Your team already builds Zaps, and the apps it needs are already connected in Zapier.
• Each person signs in to Zapier themselves, and Zapier's restrictions and History answer your reviewer.
• Your task allowance absorbs two tasks per successful call at the volume you expect.

Elaichi assumes a workforce. Roles, seats and SCIM describe employees and contractors, not your end users. It has no per-team endpoint. Every new grant needs a person to approve a consent screen, so it does not suit an agent that runs unattended in a build pipeline. Three people with one read-only app may need nothing at all, as the post on skipping a gateway for now argues.

Which one should a company pick?

Pick by who uses the tools and who has to answer for them. Three questions sort most cases in one meeting:

1. Who holds the sessions? Your customers point to Composio. Your employees point to Composio's gateway, Zapier MCP or Elaichi.
2. Where are the apps connected now? If they are already connected in Zapier, Zapier MCP reuses that work. If not, check your five most-used apps against the connector catalog and both vendors' lists.
3. Who answers the security reviewer? One admin may have to say what a role can reach, cut off a leaver and show each call that ran. Test exactly that in a pilot on each product.

Each pairing has a fuller head-to-head. The connector authorship and endpoint questions are in Elaichi compared with Composio. The per-member server model is in the Zapier MCP alternative guide. For the category itself, start with what an MCP gateway does.

FAQ

What is the difference between Composio and Zapier MCP?

Composio is an agent tool platform: its MCP Gateway gives the company a gateway endpoint and each team its own, admins set permissions per user and per role, and pricing meters tool calls (https://composio.dev/mcp-gateway and https://composio.dev/pricing, checked October 2026). Zapier MCP connects a person's MCP client to their Zapier account, runs on the app connections their Zaps already use, and each successful tool call uses two tasks from the Zapier plan (https://docs.zapier.com/mcp/overview/usage, checked October 2026). Composio leans toward teams that build agents; Zapier MCP leans toward teams that already automate in Zapier.

How does Composio pricing compare with Zapier MCP pricing?

Composio meters tool calls. Its Hobby plan is $0 with 100,000 tool calls and 3 team members a month, Pro is $29 a month with a $29 usage credit, and Enterprise is custom (https://composio.dev/pricing, checked October 2026). Zapier MCP has no separate MCP bill: each successful tool call uses two tasks from the Zapier plan's allowance, and failed calls use none (https://docs.zapier.com/mcp/overview/usage, checked October 2026). Elaichi prices by seat instead: Gold lists at $15 per user per month in USD, whatever the call volume.

Does Zapier MCP give each employee their own access?

Yes. In Zapier MCP the per-person unit is the MCP server: each member creates their own servers on the Zapier account, usually one per named MCP client, while every client uses the same endpoint. An organization rollout changes what members can reach, but each member still signs in and runs tool calls as themselves (https://docs.zapier.com/mcp/overview/how-connections-work and https://docs.zapier.com/mcp/get-started/rollout/overview, checked October 2026).

Where does Elaichi fit next to Composio and Zapier MCP?

Elaichi is a governed MCP control plane and hosted MCP gateway for a company's own staff. Every person connects Claude, ChatGPT, Cursor or any MCP client to one address, https://api.elaichi.ai/mcp, and approves their own OAuth grant. Admins restrict connectors and single tools per role or per member, tool calls are recorded in one audit log, and Gold lists at $15 per user per month in USD with SSO and SCIM included.

A sales lead at a 40-person company asks her AI assistant which deals to chase this week. It gives a careful answer about pipeline habits in general. It cannot see her pipeline. The deals live in the CRM, the unpaid invoices live in the accounting app, and the open complaints live in the support desk. Each one is a tab the assistant cannot open.

This guide is for the owner or sales lead who wants to connect AI to CRM data without hiring engineers. It covers what changes once the assistant can see the CRM, the four ways to set it up, and what to get right before it writes anything. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. The project's own site calls it an open-source standard for connecting AI applications to external systems.

What can your AI assistant do once it can see your CRM?

It can take on some of the non-selling work that fills a rep's week. Salesforce's sixth State of Sales survey found reps spend 70% of their time on non-selling tasks (Salesforce).

Four jobs usually come first:

• Prioritize leads. Ask which new leads look like your best customers. The assistant reads the records and returns a short, ranked list.
• Brief before a call. Ask for a one-page brief on the account. With the accounting app connected, the brief shows the overdue invoice. With the support desk connected, it shows the open ticket.
• Find quiet deals. Ask which open deals have had no activity for three weeks. The assistant lists them and drafts a follow-up for each owner.
• Update records. After a call, ask it to log the notes, move the stage and set the next task. This is the first job that writes, so it needs the most care.

Clean records matter here. In the same survey, only 35% of sales professionals said they completely trust the accuracy of their company's data (Salesforce).

The apps around the CRM matter as much as the CRM. A brief that misses an unpaid invoice can embarrass the rep on the call. Elaichi connects one assistant to HubSpot, Salesforce, Pipedrive, QuickBooks, Xero, Zendesk and 700+ apps in all through one connection.

What are the ways to connect AI to a CRM?

There are four, and each suits a different company. The right one depends on how many apps the work touches and how many people will use it.

Per-person add-ons are now common. HubSpot's remote MCP server is generally available to all HubSpot accounts, and it can read CRM records and activity history and create or update contacts, companies, deals and tickets (HubSpot developer changelog, checked October 2026). HubSpot says all actions respect the user's existing HubSpot permissions. For Salesforce, the guide to each rep's own Salesforce access covers its hosted option.

A shared layer works differently. Elaichi gives every company the same address, https://api.elaichi.ai/mcp. Each person adds it to their assistant once and signs in as themselves. Apps are connected once in Elaichi, and the access rules and the activity log cover all of them. Under the default choice at sign-in, an app connected later needs no new step in the assistant.

When is the CRM's own built-in AI enough?

It is enough when the work starts and ends inside the CRM. If your team wants a summary of a deal's emails or a draft follow-up from one record, the AI built into your CRM may be all you need. You skip a second vendor, a second login and a second set of rules.

The same goes for one person and one app. If a founder wants HubSpot in their assistant and nothing else, HubSpot's own MCP server covers it. Elaichi is not needed there.

The case changes when a job crosses apps, or when many people use AI on the same data. A call brief that needs the CRM, the invoices and the tickets reaches past any one vendor's AI. So does one list of who may do what across all three apps, and one log of what the assistant did. That is the point where a shared layer earns its place.

Should each person's AI see only what that person can see?

Yes, and this is the rule to get right first. A shared admin login gives every person's assistant the admin's reach. A new rep could then read every deal, including the ones the CRM hides from them.

In Elaichi, every call runs as the person who signed in, in the organization they picked. Where the CRM should see the person, each person connects the CRM under their own login. The CRM then applies the access its admin already set, such as territories, record owners and private deals. Elaichi decides who may use a connection, and the CRM decides which records that login can read.

Some connections should be shared, such as a reporting account. Share each one only with the people who need it, because a shared connection runs on its owner's login to the app.

People leave, too. When someone is removed from Elaichi, their assistant's next call through Elaichi is refused. Their CRM user is a separate step inside the CRM.

Should the AI only read your CRM, or also write to it?

Start with reads, then add writes one job at a time. Most of the value is in reading: ranking leads, writing briefs and finding quiet deals all read. Most of the risk is in writing, because a wrong stage or a merged contact changes what everyone else sees.

In Elaichi, the sign-in screen has a box called "Run your connected tools". It covers reading and changing data in connected apps, so on its own it does not make the assistant read-only. To hold an assistant to reads, pick toolboxes of read tools at sign-in, or block the write tools with a restriction. A toolbox is a named set of tools. A restriction is a rule that allows or blocks apps and single tools for a role or for one person.

Add writes in small steps. Logging a call note or creating a task is low risk. Changing a deal's owner or amount is not. Let the team use reads for two weeks, check the activity log, and then turn on the first write job.

Which CRM actions should you restrict?

Restrict anything that deletes, merges, works in bulk or changes who can see what. One bad call there reaches many records, and none of the four common jobs needs those actions.

A short list to start from:

• Deletes of contacts, companies or deals.
• Merges of duplicate records.
• Bulk updates, and catch-all tools that can change any kind of record.
• Changes to users, roles and permissions inside the CRM.

In Elaichi, a restriction names whole apps or single tools, for a role or for one person. A block always beats an allow. A restricted tool cannot be run. If the assistant searches for it, it sees only the name, flagged as restricted. A delete tool also needs a separate box at sign-in, "Delete data and remove access", which is never ticked by default.

A new rule takes about two minutes to reach everyone. Set the rules before people start, then test them as an ordinary member.

What should the activity log and data storage look like?

What the assistant does should land in a log you can read, and you should know where your data is kept. Without a log, nobody can say what the assistant changed last Tuesday, or for whom.

Elaichi writes one entry for each connected-tool call that reaches execution (a call refused earlier writes none). Each entry names the person, the app, the account the call reached and the assistant that made it. Every member can read their own entries. An admin, or a read-only Auditor, can read the whole organization's log.

For storage, Elaichi has three regions, EU, US and APAC, chosen when the organization is created and fixed after that. For EU or US, the organization's data store stays in that region. APAC uses best-effort placement and is not a residency guarantee. The activity log for every region is kept in the EU, as the privacy policy says. Elaichi does not see your conversations with the assistant; it sees only the action the assistant asks to run. The security overview has the rest.

How do you connect AI to CRM without an engineering team?

Pick one job, connect the apps it needs, set the rules, then test with one person. An admin and one person who does the work every day can do it together.

1. Pick one job, such as the brief before a call, and list the apps it reads.
2. Connect the CRM and those apps in Elaichi. Each rep connects the CRM under their own login.
3. Write restrictions on the sales role: reads first, with deletes, merges and bulk tools blocked.
4. Add https://api.elaichi.ai/mcp to your assistant's connector settings. Each person signs in once.
5. Run the job as one rep, then read the activity log and check each entry.
6. After two weeks, add the next job or the first write.

The technical walkthrough for IT has the details of step 4. Many AI projects stall between the demo and daily use, and why AI pilots stall looks at that gap.

If nobody has the time, Elaichi's forward deployed engineers do this with you. They learn how your team works, write a plan you approve, set it up in your own apps, test it on real work and hand over a written guide. You own everything they build. The services process is described step by step, and the use cases page shows the same pattern for other teams.

FAQ

Can I connect AI to my CRM without a developer?

Yes. With Elaichi, an admin connects the CRM once, sets which actions each role may take, and adds one address to the company's AI assistant. Each person then signs in once. If nobody has the time, Elaichi's forward deployed engineers do the setup with the team and hand it over.

Is it safe to let an AI assistant update CRM records?

It is safe when writes are added on purpose. Start the assistant on reading only, block deletes, merges and bulk updates, and turn on one write job at a time, such as logging call notes. Keep an activity log so that any change can be traced to a person and an app.

Will the AI see every record in our CRM?

Not if each person connects the CRM under their own login. The assistant then reads only what that person's CRM account can read, under the territories and record owners the CRM admin already set. A shared admin login would give every person's assistant the admin's reach.

Do I need Elaichi if my CRM already has built-in AI?

Not always. If the work starts and ends inside the CRM, the CRM's own AI may be enough. Elaichi is for work that crosses apps, such as a call brief that needs the CRM, the accounting app and the support desk, and for one set of access rules and one log across all of them.

Which CRMs can an AI assistant connect to through Elaichi?

Elaichi's catalog includes HubSpot, Salesforce and Pipedrive, along with accounting apps such as QuickBooks and Xero and support desks such as Zendesk. Elaichi connects to 700+ apps in all, through one address that any AI assistant supporting MCP can use.

An engineer, Emily Carter, adds an MCP server to Claude Desktop on a Friday. It takes a few lines in a config file and a personal API token. By Monday it saves her an hour a day. Then sales asks for the same thing, and so do finance and support. Enterprise MCP is MCP run for a whole company instead of one laptop: each person signs in as themselves, a role decides which tools they reach, and each call that runs is recorded. It is the name for what has to change before a whole company can do what Emily did on her own laptop.

MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. On one laptop, the person, the credential and the record are the same machine. Across a company they come apart, and each needs an owner. This guide is the buyer's view. It walks an enterprise AI platform buyer through seven decisions, shows where a governed control plane fits, and covers the case where a company does not need one yet. The rule model behind those decisions, with restrictions, credentials, the record and offboarding in detail, is in MCP governance.

What changes when MCP moves from a laptop to a company?

Identity, the address, the rules, the credentials and the record all move from the person to the organization. On a laptop, the MCP authorization specification makes sign-in optional. It tells servers on the local stdio transport to read credentials from the environment instead.

A local server lives in a file on each machine. Claude Desktop keeps its list in claude_desktop_config.json, per the MCP guide to local servers. That works for one person. Nobody else can see the file, revoke the token or read what ran.

Does each person sign in to MCP as themselves?

They should, because a shared token makes every call look like one person. OAuth, the standard for delegated sign-in that never hands the client a password, gives each person their own grant.

In Elaichi, each person connects their AI client once and approves their own grant on a consent screen. Every call made with that grant acts as that person, in the organization they picked. Their permissions are looked up on each request, not stored in the token.

SSO (single sign-on through the company's identity provider) sits in front of that. Elaichi supports SAML and OIDC. An admin can enforce SSO for a verified domain, so an email-code or social sign-in for an address on it is refused. What the consent screen asks, and which boxes start ticked, is covered in the MCP security review checklist.

Should you run one MCP endpoint or a server per team?

One endpoint is simpler, as long as it knows who is calling. A server per person or per team multiplies configs, tokens and logs. With one address, the person's grant decides the rest.

Elaichi has one address for every organization, https://api.elaichi.ai/mcp. The grant behind the token, not the URL, decides the organization and the person. Every client points at that same string. In Claude Team and Enterprise, an Owner adds a custom connector for the organization, and users then connect to it individually, per Anthropic's help article on remote MCP connectors (checked October 2026). The cost of each shape at 200 people is worked out in one endpoint versus one per team.

Behind the address sits one governed catalog of 600+ connectors. Elaichi authors and runs most of them. The rest are native MCP connectors: the vendor builds and runs its own MCP server, and Elaichi handles sign-in, access and audit. An organization on Gold can also bring its own remote MCP server under the same rules.

How do you give each role different MCP tools?

With roles and restrictions enforced on the server, not instructions to the model. OWASP's guidance on excessive agency says to limit an extension's permissions in other systems "to the minimum necessary".

In Elaichi, each member holds exactly one role. Every organization starts with eight system roles, and custom roles are available on Gold. A restriction is an allow or block rule. It targets a role or one member, and names whole connectors or single tools. A block always beats an allow. So support can keep its ticketing tools while finance reads the accounting app and cannot write to it, from the same address.

A role or restriction change takes effect within about two minutes. Removing a person takes effect on the next call. Starting roles per department are in the guide to rolling out Claude and ChatGPT. What each AI client's own admin console controls is compared in IT admin controls for MCP connectors.

Who holds the app credentials when nobody pastes a token?

A vault the gateway reads for each call, not the person and not the AI client. On a laptop, the API key sits in plain text beside the server config.

In Elaichi, a separate credential service holds every connected account's secrets. They are encrypted at rest with AES-256-GCM, and the key can be rotated. Elaichi fetches a credential into memory only for the call that needs it. The AI client holds only an Elaichi token: an access token that lasts one hour and a refresh token that rotates on every use. The MCP endpoint accepts nothing else, so a pasted API key does not work there.

One trade-off belongs in the design. A connection someone shares runs on its owner's sign-in to the app, so every caller acts with that owner's app permissions. Where the app should see each person, each person connects their own account. Moving off personal API keys covers the switch.

What should an MCP audit record show?

Who made the call, from which client, against which account, and whether it worked. In Elaichi, every connected-tool call that reaches execution writes a row. The row names the person, the connector, the connection the call actually reached, the MCP client, how the call was approved and the outcome. It records no argument values beyond the one path argument that names the object.

Every member sees their own activity. People with the audit permission see the whole organization. That includes the Auditor role, a free, read-only seat for compliance reviewers. Elaichi keeps 90 days of history, and export to your own Datadog comes with the Black plan, which is launching soon.

Note one limit in your control description. A call refused at the OAuth scope check, before any tool runs, writes no row. The full field list is in what an AI audit log must capture.

What happens to MCP access when someone leaves?

The identity provider should end it, and the next call should fail: in Elaichi, a SCIM deprovision (SCIM is the protocol an identity provider uses to create and remove accounts in other services) suspends the member, which revokes every MCP grant they hold. MCP governance covers the rest of the offboarding rules, and offboarding when the agent holds access gives the order of steps.

Where does enterprise MCP data live?

In a region the company picks, with the exceptions written down. Elaichi has three regions, EU, US and APAC, picked when the organization is created and fixed after that. For EU and US organizations, the organization's data store stays in that region. So does the execution of its requests and tool calls. An APAC organization gets no such guarantee.

Some things sit outside the region. User accounts and SSO settings are not pinned to one. Files stored from tool results go to the EU for every organization. Elaichi's privacy policy says its audit-log store is one EU instance serving all regions. For key custody, customer-managed keys in AWS KMS come with the Black plan, which is launching soon. The GDPR side is covered in EU data residency for AI agents.

Where does a governed MCP control plane fit?

Between the AI clients and the apps, as the one place where identity, rules, credentials and records meet. Elaichi is a governed MCP control plane and hosted MCP gateway. Every call from Claude, ChatGPT, Cursor or any MCP client passes through it. Each call is checked against the caller's access, and each call that reaches execution is written to the audit log. That holds whether the tool is a catalog connector Elaichi runs or an MCP server behind it.

Hosted means the company does not run an MCP server to use Elaichi. Gold includes the MCP endpoint, custom roles, restrictions, SSO, SCIM and group-to-role mappings. Gold lists at $15 per user per month in USD, and pricing shows the local price. The category itself is set out in what an MCP control plane is.

Elaichi has one limit to state plainly. Its MCP endpoint never receives the person's prompt, only the tool call the client's model wrote. So it has nothing to judge a call against, and defense against prompt injection belongs to the client. Least privilege, enforced by roles and restrictions, limits the damage. Whether a client asks before each write is that client's own setting.

What to ask any vendor, and how Elaichi answers

Ask about each decision in writing, then test the answers in a trial. The table pairs each question with why it matters and with Elaichi's answer.

Security teams ask a deeper set of questions about tokens, consent and evidence. Send them the ten-question security review alongside this table.

When does a company not need enterprise MCP tooling yet?

When MCP is still one person's tool, or one app's. A developer running local servers against their own files needs none of this. The risk sits on their laptop, and endpoint controls cover it, not a gateway.

A company where one team uses one app may be fine for a while too, if that app's vendor runs its own MCP server. The vendor's own permissions apply. The same holds while no AI client can write to a system of record.

The case changes at the second app, the second client or the first write. Then one set of rules and one trail start to matter. When you don't need an MCP gateway lists the signals to watch. When they arrive, start from the connector catalog.

FAQ

What is enterprise MCP?

Enterprise MCP is the Model Context Protocol run for a whole company rather than on one person's laptop. It adds what a single user never needed: each person signs in through the company's identity provider, their role decides which tools they can reach, app credentials sit in a vault instead of config files, every tool call that runs leaves an audit record, and access ends when the identity provider removes the person. Products that provide this are usually called MCP gateways or MCP control planes.

Do we need SSO and SCIM to roll out MCP?

SSO decides who can sign in, and SCIM keeps membership in step with the identity provider, so both matter once more than a handful of people use MCP. Neither decides which tools a person can reach; roles and restrictions do that. In Elaichi, SSO (SAML or OIDC) and SCIM are on the Gold plan. A SCIM deprovision suspends the member, which revokes their MCP grants, so their AI client fails on its next call.

Does each team need its own MCP server?

Not when the endpoint knows who is calling. With Elaichi, everyone in every organization uses the same address, https://api.elaichi.ai/mcp. The OAuth grant behind each person's token decides the organization and the person, and their role and restrictions decide the tools. Each person still connects their AI client once and approves their own grant.

How long does Elaichi keep the MCP audit log?

Elaichi keeps 90 days of audit history. Every member can see their own activity, and people with the audit permission, including the free, read-only Auditor role, see the whole organization. For a longer history, export to your own Datadog comes with the Black plan, which is launching soon.

Is Elaichi a self-hosted MCP gateway?

No. Elaichi is a governed MCP control plane and hosted MCP gateway, so a company does not need to run an MCP server to use it. A company that does run a remote MCP server, reachable over public HTTPS, can add it to Elaichi as its own connector on the Gold plan, and calls through it follow the same roles, restrictions and audit log as every other connector.

Hosted MCP gateway or self-hosted: which one should carry your AI tool calls?

Choose hosted unless a policy or network rule forces the gateway onto your hosts. Elaichi is a governed MCP control plane and hosted MCP gateway, so weigh the trade-offs with that in mind.

A hosted MCP gateway and a self-hosted one do the same job. The difference is who runs it. The request usually reaches IT as a security requirement: every AI tool call must pass through one checkpoint that checks access and records the call. The platform team offers to run one. A vendor offers to run it for you.

MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. An MCP gateway is the layer between AI clients and the tools they call. It signs each person in, decides which tools that person may reach, and writes down what happened. The four shapes the name covers are set out separately. This post takes one question only: should that layer sit on your infrastructure or on someone else's?

What does a self-hosted MCP gateway put on your servers?

It puts the gateway's data plane, the part that handles each call, and usually the MCP servers behind it, on infrastructure you operate. Some of these products are managed through a vendor's console; the traffic still runs on your hosts. Your team installs the data plane, upgrades it and keeps it up.

Three products show the range of gateways whose data plane runs on your infrastructure. Docker calls its MCP Gateway an "open source solution for orchestrating Model Context Protocol (MCP) servers". It "runs MCP servers in isolated Docker containers", and with Docker Desktop's MCP Toolkit enabled it runs in the background (Docker docs, checked October 2026). Docker's docs tag the whole MCP Catalog and Toolkit section Beta (same page, checked October 2026). The Docker gateway comparison covers it in depth.

Kong AI Gateway is managed through Kong's Konnect, while its data plane nodes "run in your environment (self-hosted, cloud, or Kubernetes)" (Kong docs, checked October 2026). Kong's AI MCP Proxy plugin supports per-tool access lists for its Consumers and Consumer Groups. All access attempts, allowed or denied, go to the plugin's audit log, and the plugin is part of Kong's AI Gateway Enterprise offering (Kong plugin docs, checked October 2026).

Lunar.dev presents MCPX as an enterprise MCP gateway, and its FAQ says MCPX is fully self hosted, running entirely inside your infrastructure (lunar.dev, checked October 2026). Counting servers before choosing MCPX goes further on that product.

Each of these is built for a team that already runs services and wants policy in front of them.

What do you run and patch on each side?

Self-hosted, you run the gateway and everything it depends on. Hosted, you run nothing for the gateway itself.

On the self-hosted side the list is concrete. There is the gateway binary or containers, the hosts under them, TLS certificates, the sign-in wiring to your identity provider, and each MCP server behind the gateway. Every one has its own release cycle. The cost of running MCP servers yourself prices the servers line by line, so this post does not repeat it.

On the hosted side, Elaichi hosts the one MCP endpoint and the catalog connectors behind it. A company does not need to run an MCP server to use Elaichi. Running one is a choice. What stays with you is configuration: who holds which role, which tools each role may reach, and which accounts are connected.

Where do the app credentials live?

With a self-hosted gateway, they live in your secret store. With Elaichi, they live in a separate credential service that Elaichi runs.

Someone has to hold them. The MCP authorization spec says an MCP server must only accept tokens valid for its own resources and "MUST NOT accept or transit any other tokens". The token used at the upstream app is a separate one. So the gateway, or the servers behind it, hold every app's credential. Docker describes its gateway as a proxy that manages configuration, credentials and access control (Docker docs, checked October 2026). On a self-hosted gateway, that store, its encryption and its key rotation are yours.

Elaichi keeps connector credentials out of its main data. A separate credential service holds them, encrypted at rest with AES-256-GCM, and the key can be rotated without re-encrypting old rows. Elaichi fetches a credential into memory only for the call that needs it. The AI client holds only an Elaichi token. Elaichi never forwards that token to a remote MCP server, so a server sees only tokens its own authorization server issued.

The trade is custody. You trust the hosted vendor's handling instead of your own. For key custody, customer-managed keys in AWS KMS come with the Black plan, which is launching soon.

Who writes the connectors behind the gateway?

A self-hosted gateway governs servers that already exist. A hosted MCP gateway like Elaichi also serves the connectors, most of which it writes.

A gateway in front of servers adds a door, not apps. Kong's route is to turn existing APIs into tools an agent can call over MCP, which suits a company whose APIs already sit behind Kong (Kong docs, checked October 2026). For SaaS apps, the servers come from your team, the app vendor or the community.

Elaichi's catalog holds 600+ connectors of two kinds. Elaichi authors and runs most of them itself, so an app's API change is Elaichi's to fix. The rest are native MCP connectors: the vendor builds and runs its own MCP server, and Elaichi handles sign-in, access and audit in front of it. Datadog and Linear are there that way. How vendor MCP servers run through Elaichi covers that path.

A company can also bring its own server. On Gold, an Org Owner or Org Admin adds a remote MCP server as the organization's own connector. It must speak MCP over Streamable HTTP, the transport that sends each message as an HTTP request, and be reachable over public HTTPS. Restrictions and OAuth scopes, the permissions a person approves on the consent screen, are checked before a call leaves Elaichi, and only a tool on that connection's own active list can run.

How many addresses do AI clients point at?

With a self-hosted gateway, as many as you deploy. With Elaichi, one.

A self-hosted gateway's address count follows your topology. One gateway per laptop, one per team or one shared cluster are all possible, and each is a configuration someone keeps in step across Claude, ChatGPT, Cursor or any MCP client.

Elaichi serves every organization at https://api.elaichi.ai/mcp. The OAuth grant behind each token, not the URL, decides the organization and the person. OAuth is the sign-in standard that lets a client act as a named person without holding that person's password. Each member still connects their client once and approves their own grant. No URL carries a token, and there is no per-team or per-toolbox address to hand out or take back. Per-team and org-wide endpoints compares the two models.

Who carries upgrades, uptime and the pager?

Self-hosted, your team does, on its own schedule. Hosted, the vendor does, on the vendor's schedule.

Running the gateway yourself means you choose when to upgrade. You can hold a version through a busy quarter, test a release in staging first, and read the code before it runs. It also means the pager. A gateway outage stops every tool call routed through it, so it needs monitoring, failover and someone on call.

Elaichi patches the endpoint and the connectors it authors. For a native MCP connector, the vendor maintains its own server's tools. You give up control of timing: a change lands when Elaichi ships it. Ask any hosted vendor, Elaichi included, for its uptime commitment in writing before a rollout depends on it.

Changes you make yourself have timing too. In Elaichi a role or restriction change takes about two minutes to reach every surface. Removing or suspending a member revokes every live grant, so their AI clients fail on the next call.

Where does the data sit with a hosted MCP gateway?

With a self-hosted gateway, it sits where you put it. With Elaichi, an EU or US organization is pinned to its region, APAC carries no residency guarantee, and a few things sit outside the region.

Self-hosting gives the most control over placement. The gateway's logs, config and secrets stay on your hosts. Calls to SaaS apps still leave your network, because the apps live elsewhere.

Elaichi has three regions, EU, US and APAC. The organization picks one at creation, and it cannot change later. For an EU or US organization, the data store (the per-organization store that holds most organization data) and the execution of its requests and tool calls are pinned to that region. For an APAC organization, region is not a residency guarantee.

Some things sit outside the region. User accounts and SSO settings are not pinned to one. Files stored from tool results go to the EU for every organization. Elaichi's privacy policy says its audit-log store is one EU instance serving all regions, so a US or APAC organization should not expect its audit trail to stay in its region. Elaichi keeps 90 days of audit history. Data residency for AI agents in the EU goes deeper.

How do the two compare, question by question?

Self-hosting keeps control and work in-house. A hosted MCP gateway moves both to a vendor.

When is self-hosting the MCP gateway the right call?

Self-host when the servers or the policy require your own network. In these cases Elaichi is the wrong fit, and saying so saves a pilot.

• The servers cannot be exposed. Elaichi's remote MCP connector needs public HTTPS. A server on an internal hostname, an IP address or localhost cannot be added, so a gateway inside the network fits.
• Policy says the checkpoint runs on your hosts. Some security programs require every gateway to sit in infrastructure the company operates. Elaichi is hosted only.
• The tools are local. A filesystem or browser tool on a developer's machine belongs in a local container, which is where Docker's gateway runs.
• Your MCP traffic is your own APIs. If those APIs already sit behind Kong, exposing them as MCP tools is configuration, not a new vendor.
• You need to hold upgrades or read the code. Docker's gateway is MIT-licensed open source in the docker/mcp-gateway repository, checked October 2026.
• The audit trail or the data must stay in your region. Elaichi's privacy policy says its audit-log store is one EU instance serving all regions, so a US or APAC organization should not expect its audit trail to stay in its region (privacy policy). For APAC, the region is not a residency guarantee.

With one app, one client and a few engineers, no gateway is needed yet.

Can you run a self-hosted gateway and a hosted one together?

Yes. Split them by where the server lives. Internal and local tools stay behind the gateway you run. Company SaaS accounts go through Elaichi, where each person signs in once.

Keep each app on one path only. If Salesforce is reachable through both, Elaichi's restrictions and audit log miss the calls that took the other route. Shortlisting MCP gateways by shape lays out the vendors on each side. The connector catalog shows which apps Elaichi already serves, and team-by-team use cases show where a rollout usually starts.

FAQ

What is a hosted MCP gateway?

A hosted MCP gateway is a checkpoint for AI tool calls that a vendor runs for you. Claude, ChatGPT, Cursor or any MCP client points at the vendor's address, each person signs in, each call is checked against that person's access, and each call that runs is recorded. A self-hosted gateway does the same job on servers your own team runs and patches. Elaichi is a hosted MCP gateway with one address, https://api.elaichi.ai/mcp, for every organization.

Can Elaichi be self-hosted inside our own network?

No. Elaichi is a hosted service only. The location control it offers is the region, EU, US or APAC, picked when the organization is created and fixed after that. An EU or US organization has its data store and request execution pinned to its region; an APAC organization gets no residency guarantee. If your policy says the gateway must run inside your own network, a self-hosted MCP gateway, where the data plane runs on your own infrastructure, is the better fit.

Can a hosted MCP gateway govern an MCP server we run ourselves?

Elaichi can, if the server speaks MCP over Streamable HTTP (the MCP transport that sends each message as an HTTP request) and is reachable over public HTTPS. An Org Owner or Org Admin on the Gold plan adds it as the organization's own remote MCP connector. Restrictions and OAuth scopes (the permissions a person approves when connecting a client) are then checked before a call leaves Elaichi, and every call that runs is written to the audit log. A server on localhost, an IP address or an internal hostname cannot be added.

Where does a hosted MCP gateway keep the app credentials?

In Elaichi, connector credentials sit in a separate credential service, not in the main data store. They are encrypted at rest with AES-256-GCM and fetched into memory only for the call that needs them. The AI client holds only an Elaichi token, never the app's credential. Elaichi also never forwards its own access token to a remote MCP server.

What does MCP governance cover?

MCP governance is the set of rules for what AI assistants may do in company apps. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. The rules answer five questions: who may connect which app, which tools each role may call, whose credentials a call runs on, what is recorded, and how access ends when someone leaves.

One developer connects Cursor to Jira with a personal token, and it works. Six months later, support uses Claude against Zendesk, and finance uses ChatGPT against QuickBooks. Emily Carter in sales has connected two Salesforce accounts. Then security asks: when Jake Morgan leaves on Friday, what can his assistant still reach? Nobody can answer it from one place.

This post is the rule model: restrictions, credentials, the record and offboarding. The buyer's view, with data regions and a vendor question table, is in enterprise MCP: a buyer's guide.

The protocol leaves these decisions to you. The MCP authorization spec makes authorization optional. The spec's tools section wants a human who can deny tool calls, and asks clients to log tool use for audit. It does not say who that human is, which tools they may allow, or where the log lives. That gap is the governance layer.

Why do AI governance programs miss the tool call?

Frameworks such as the NIST AI Risk Management Framework and ISO/IEC 42001 work at the level of policy, risk and management systems. They do not decide what one person's assistant may do in one app right now. MCP governance does, and it names who answers for it.

The frameworks show the altitude. The NIST AI Risk Management Framework aims to bring trustworthiness into the design, development, use and evaluation of AI products and systems. ISO/IEC 42001 sets requirements for an AI management system: the policies, objectives and processes an organization keeps for responsible AI. Neither tells you whether the support team's assistant may close tickets in Zendesk.

The risk lists come closer. OWASP's entry on excessive agency names three usual root causes: excessive functionality, excessive permissions and excessive autonomy. It advises acting in the context of the specific user, with least privilege, and enforcing authorization in downstream systems rather than in the model. A policy can state those rules. Something on the path of every call has to enforce them.

Who may connect which app?

An admin decides which apps each role may reach, and members connect their own accounts inside that list. In Elaichi, the rule that sets this is a restriction. A restriction is an allow or block rule that targets a role or one member and names whole connectors or single tools.

With no rule in place, a Member can connect any catalog connector with their own account. For a shorter list per role, write allow rules that name whole connectors. Once a role carries any allow rule, every connector those rules do not name is restricted for that role. Watch for one trap: an allow rule that names nothing restricts everything for its target. It is a lockout, not a placeholder.

The same check runs everywhere a member meets a connector: the catalog, the connect step, the tool list their AI client sees, the call itself and the outbound request. A rule written for one member can only narrow what their role allows. It never loosens it.

Adding a new app is a separate decision. Creating a custom connector needs the connector:create permission, and among the built-in roles only Org Owner and Org Admin hold it. The console tags it "High trust". A restriction binds a connector's identity, not the host it calls, so a new connector aimed at a restricted API slips past the old restriction. Approved AI tools per team walks through these rules for a real rollout.

Which tools can each role call?

Tool-level rules decide which tools of an approved app a role may call. In Elaichi, a block always beats an allow.

An allow rule that names a few read tools holds the role to those tools on that app. The role then also needs allow rules for each other app it uses; otherwise those apps are restricted. A layer with only block rules has no allowlist, so every tool it does not name stays reachable. Three block rules on write tools leave the fourth write tool open. Allow rules also match a tool by the operation it performs, not by its label, so renaming a tool cannot widen access. The reasoning is in why a block matches the name and an allow matches the operation. Choosing between one tool and the whole app is covered in six restriction cases.

The role also has to permit tool use at all. Running any connected tool over MCP needs the tool:execute permission. Guest, Billing Admin and Auditor do not hold it. A compliance reviewer can read the record without being able to act.

The person adds one more limit when they connect a client. Elaichi's consent screen lists what the client may do. "Run your connected tools" lets it read and change data in connected apps. Deleting there also needs "Delete data and remove access", which is never ticked by default. The person can also limit the client to toolboxes they pick (a toolbox is a named set of tools).

A change to a role or a restriction reaches every client within about two minutes, so plan pilots around that window.

Whose credentials does each call run on?

Every call runs as one named person, on the account behind the connection it uses. Elaichi never runs a connected-tool call as the organization at large.

Over MCP, the person comes from the OAuth grant behind the client's token. OAuth is the sign-in standard MCP clients use, and a grant is the access one person approves for one client. Each member connects their client once and approves their own grant. The account comes from the connection. A connection a member made with their own login carries their own permissions in that app. A connection shared with a team runs every caller's call on its owner's sign-in.

Picking one is a governance decision. Use per-person connections when the app should see who is asking, such as a CRM with record-level sharing. Use one shared connection when a fixed permission set is the point, such as a read-only reporting account. A toolbox shared with a team runs each entry on the connection pinned into it, not on each member's own account. The longer argument is in AI agents with employee permissions.

The AI client holds only an Elaichi token, never the app credential. Connector secrets sit in a separate credential service, encrypted at rest with AES-256-GCM. Elaichi fetches them into memory only for the call that needs them.

What should the record show for each AI tool call?

Each call that runs should leave a row naming the person, the client, the account reached and the outcome. Elaichi writes that row for every connected-tool call that reaches execution, whether it succeeds or fails.

The row records the acting person, the MCP client, the connector, the connection the call actually reached, the toolbox and the tool. It records whether the call was a read, a write or a delete, how it was approved, how it ended, an error code on failure, and what the call touched. It keeps no argument values beyond the id of the object a call names. A call refused earlier, for example for a missing scope, writes no row.

Everyone can read their own activity in the audit log. People with the audit:view permission, which Org Owner, Org Admin and Auditor hold, see the whole organization. Elaichi keeps 90 days of audit history. Beyond the in-app trail, export to your own Datadog comes with the Black plan, which is launching soon. The field-by-field case is in what an AI agent audit log must capture.

How does AI access end when someone leaves?

Removing or suspending a member ends their AI access on their client's next request. In Elaichi, removal and suspension revoke the person's MCP grants, and every MCP request reads the grant again.

Identity providers follow the same path. SCIM is the standard an identity provider uses to add and remove users in other apps. A SCIM deprovision suspends the member rather than deleting them, and suspension revokes their grants and API tokens. Reactivation does not restore the grants, so they connect again.

What the person built is the harder part. Elaichi's offboarding preview lists their connections, toolboxes, templates, synthetic tools and custom connectors, plus toolbox entries elsewhere that rely on them. Transfer each shared connection to someone staying as part of the removal. Left in place, it stays owned by the departed member, and nobody can transfer it afterwards. Toolbox entries the leaver pinned stop working for everyone until someone re-pins them.

Removing someone from Elaichi does not deactivate their accounts inside the connected apps. Deprovision those in each app or through your identity provider. The full last-day sequence is in offboarding AI access, contractors included.

Where does a hosted MCP gateway fit?

A hosted MCP gateway puts every AI tool call through one place where these rules are checked and recorded. Elaichi is a governed MCP control plane and hosted MCP gateway: Claude, ChatGPT, Cursor or any MCP client signs in to https://api.elaichi.ai/mcp, the same address for every organization, and one restriction applies to all of them. Each client's own settings, such as Claude's per-tool permissions (Always allow, Needs approval or Blocked) and ChatGPT Business's admin-only custom MCP apps, govern that one client only (both checked October 2026). The buying questions are in enterprise MCP: a buyer's guide.

What can an MCP gateway not govern?

A gateway governs the calls that pass through it, and only those. Four limits apply to Elaichi.

• Direct calls. A call a client makes straight to a vendor's own MCP server, outside Elaichi, is not governed by Elaichi. On Gold, an Org Owner or Org Admin can add that server as a remote MCP connector, if it is reachable over public HTTPS, to bring it under the same rules.
• Per-call approval. Over MCP, Elaichi does not ask before each call. The consent screen is the approval, and any per-call prompt a person sees comes from their own client.
• Injected instructions. Elaichi does not scan tool results sent to MCP clients for prompt injection, the trick of hiding instructions for the model inside data. That defense belongs to the client.
• Client-side tool rules. Claude's per-tool permissions see all of Elaichi's connected tools as a single tool, so they cannot tell one app from another. Write per-app rules in Elaichi instead.

When can a team skip MCP governance for now?

A team with one developer, one client, one app and read-only access does not need a governance layer yet. The app's own permissions and the client's own settings cover that case. A gateway there adds a bill and a sign-in step, and its log has nobody to read it.

The answer changes when any one of four signals appears. A second client or team arrives. There are more accounts than people. A leaver's assistant still holds access. Someone outside the team has to answer for what an assistant did. The signals are spelled out in when you don't need an MCP gateway yet.

When they show up, start with what an MCP control plane is and who needs one. Then check that your apps are in the connector catalog, and compare plans on the pricing page.

FAQ

What is MCP governance?

MCP governance is the set of rules that controls what AI assistants may do in company apps through the Model Context Protocol. It covers who may connect which app, which tools each role may call, whose credentials each call runs on, what is recorded, and how access ends when someone leaves. Elaichi enforces these rules at one hosted MCP endpoint that Claude, ChatGPT, Cursor or any MCP client signs into.

How is MCP governance different from AI governance?

AI governance programs, such as ones built on the NIST AI Risk Management Framework or ISO/IEC 42001, deal with AI systems, risk and policy across the organization. MCP governance deals with single tool calls: which person's assistant may run which tool in which app, on whose account, and with what record. Most companies need both. The second is the one a policy document cannot enforce by itself.

Do the admin settings in Claude or ChatGPT replace an MCP gateway?

They govern one client each. On Claude's Team plan, only Owners and Primary Owners add custom connectors, and on ChatGPT Business only admins and owners deploy a custom MCP app (https://support.claude.com/en/articles/11175166-get-started-with-custom-connectors-using-remote-mcp and https://help.openai.com/en/articles/12584461-developer-mode-and-mcp-apps-in-chatgpt, checked October 2026). A hosted MCP gateway such as Elaichi applies one set of roles, restrictions and audit records to every client that signs in, so one rule covers Claude, ChatGPT and Cursor together.

How fast does an access change take effect in Elaichi?

A change to a role, a restriction or a team takes effect within about two minutes. Removing or suspending a member, disconnecting a client's grant or revoking a share takes effect on the next call, because Elaichi reads those again on every request.

The demo went well. The AI wrote a clean reply to a customer, or built a sales summary in seconds, and the room was impressed. Six weeks later, almost nobody on the team opens it. This is the most common end for a company AI pilot (a small trial run before a full rollout), and the reasons why AI pilots fail are usually plain ones. They are about access, trust, design, ownership and measurement, not about how clever the AI is. Each one has a plain fix.

Why AI pilots fail: the five causes

AI pilots fail mostly because the pilot never touches the real work. The AI model is rarely the problem.

The numbers say this is common. Gartner predicted that at least 30% of generative AI projects would be abandoned after proof of concept by the end of 2025, citing poor data quality, weak risk controls, rising costs or unclear business value (Gartner, July 2024). A proof of concept is a small test that shows an idea can work. In a survey of more than 1,000 companies, S&P Global Market Intelligence found 42% had abandoned most of their AI initiatives in 2025, up from 17% a year earlier (CIO Dive). MIT's NANDA report "The GenAI Divide" found that only about 5% of AI pilots reached fast revenue growth, while most had little or no measurable effect on profit and loss (Fortune). "Fail" there means no measurable financial result, not a broken tool.

Five causes show up again and again. Each has its own fix.

Cause one: the AI cannot reach the apps where work happens

When the AI cannot open the CRM, the help desk or the accounting app, people must copy data in and copy answers out. That extra step kills daily use.

Take a support team at an online store. The pilot AI writes good replies, but it cannot see the customer's orders or past tickets. So an agent opens three apps, copies the details into the chat, then pastes the reply back. After a week, the agent decides it is faster to write the reply alone.

The fix is to connect the AI to the apps the team already uses, so it reads and acts there. Elaichi connects an AI assistant to 700+ apps, which you can browse in the connector catalog. A CRM is the usual first example: see connecting AI to your CRM. The rule of thumb is simple. If a job needs three apps, the AI needs all three before the pilot starts.

Cause two: nobody trusts the AI with company data

A pilot stalls when IT, legal or the team leads do not know what the AI can see or change. Without clear limits, the safe answer is "do not use it."

A finance team at an accounting firm is a good example. The partners like the idea of AI that matches invoices to payments. But nobody can say whether it could also see payroll, or send a payment by mistake. So the pilot stays on sample data, and sample data never becomes daily work.

The fix is limits that are set before people start. With Elaichi, the AI can only use the apps and actions you allow for each person. An admin can restrict a tool or a whole app for a role or for one member, and that change takes effect within about two minutes. Each action the AI runs goes into an activity log (a record of who did what, and when). The customer picks EU, US or APAC when the organization is created. For EU and US, the company's Elaichi data store and the execution of its org-scoped requests stay in that jurisdiction. APAC uses best-effort placement and is not a residency guarantee. The security page has the details.

Cause three: the pilot was built for a demo, not for the job

A demo pilot shows what the AI can do on a good day. A daily-use pilot fits how one team does one job, including the dull steps and the exceptions.

Picture a sales team at a software company. The pilot answers clever questions about the market, which looks good in a meeting. What the reps actually need is a short brief before each call and a list of deals that have gone quiet. Nobody asked them, so they never use what was built.

The fix is to start with the people who do the job. Sit with them for an hour. Write down the steps they repeat every day and the ones they hate. Pick one job, then build the AI around that job and nothing else. Elaichi's use cases show this job-first approach for sales, support, finance, HR and IT.

Cause four: nobody owns the AI after the pilot

Pilots often belong to a project, and projects end. When nobody owns the AI afterward, it breaks quietly and people stop trusting it.

A logistics firm runs a pilot that helps dispatch see shipments and jobs in one place. The outside team that built it leaves. Then a new hire needs access, an app changes, and a step stops working. Nobody knows who to ask. Within a month, dispatch is back to spreadsheets.

The fix is to name an owner inside the company before the pilot starts. That person adds people, changes who can do what, and checks the activity log. They also need a written guide, not a memory of a meeting. When Elaichi's engineers hand over, the customer's admins run everything from Elaichi with a written guide. The customer also owns what was built: the setup, the instructions for the AI and everything it produces stay in its own account and apps.

Cause five: nobody defined what "working" means

If nobody says what success looks like, every pilot ends with "it was interesting." Interesting is not a reason to change how a team works.

An HR team pilots AI for new-hire setup. It seems to help. But nobody counted how long setup took before, or how many steps were missed. So when the budget review comes, there is nothing to show, and the pilot ends.

The fix is to write down two or three measures before the pilot starts. Keep them about the job: time per task, number of missed steps, or how many items the team clears in a week. Measure them on real work, before and after. Agree on them with the person who owns the job, not only with the person who bought the tool.

What does daily use of AI look like?

Daily use means people reach for the AI as part of the job, without a reminder. It also means the AI stays inside each person's access, and its actions are on record.

Three signals tell you a pilot has become daily work:

• People use it without being reminded. Nobody sends a message asking the team to "try the AI." Usage holds steady after the launch week ends.
• It acts only within each person's access. A sales rep's AI sees what the rep can see, and an intern's AI sees less. When someone changes role, the AI changes with them.
• Its actions are recorded. Anyone who needs to can check what the AI did, for whom, and in which app.

Elaichi's activity log keeps one entry for each connected-tool call that reaches execution (a call refused earlier writes none), so the third signal is a report you read rather than a guess. The post on what an AI audit log must capture covers what a useful record holds.

When should an AI pilot stop?

A pilot should stop when the job does not suit AI, and stopping then is a good result. It frees the team to try a job that does suit it.

Stop when the job happens too rarely to be worth the setup. Stop when the AI's mistakes take longer to fix than the work it saves. Stop when the data the job depends on is wrong or missing, because AI makes bad data move faster. And stop when the people who do the job, after a fair trial on real work, do not want it.

Some jobs need a person to decide every time. For those, the AI can prepare the work and a person approves it, as the post on human approval for AI actions explains. If even that adds no value, end the pilot and write down why.

How Elaichi's engineers take a pilot to daily use

Elaichi Services is AI consulting, automation and integration delivered by forward deployed engineers. These are engineers who work directly with your team, build in your real apps, and stay until the AI is in daily use.

They learn the work with the people who do it. They write a plan that says which jobs the AI takes over, which apps it needs, who can use it, and how everyone will know it works. The company approves the plan first. Then they connect the apps, set the access rules, test on real work, fix what is off, and hand over a written guide. Each step is laid out on the page for Elaichi's AI consulting, automation and integration service.

FAQ

Why do most AI pilots fail?

Most AI pilots fail for reasons that have little to do with the AI model. The AI cannot reach the apps where the work happens, so people copy and paste. Nobody trusts it with company data. It was built to impress in a demo, not for the people who do the job. Nobody owns it after the pilot ends. And nobody wrote down what "working" would look like.

How do you measure whether an AI pilot worked?

Measure use, not impressions. Check whether people use the AI for the job without being reminded, whether it acts only within each person's own access, and whether its actions in your apps are recorded. Then compare the time the job took before and after on the same real work. Decide these measures before the pilot starts, with the person who owns the job.

When should a company stop an AI pilot?

Stop when the job is too rare to be worth it, when the AI's mistakes cost more to fix than the work it saves, or when the data it needs is not reliable. Also stop when the people who do the job do not want it after a fair trial on real work. Stopping a pilot that does not fit is a good result, because it frees time for one that does.

How long should an AI pilot run?

Long enough for the people who do the job to use it on real work through a normal cycle, such as a week of support tickets or one month-end close. A pilot that ends before a normal cycle ends tells you how the demo went, not how the work goes.

What do vendor MCP servers change for IT?

Vendor MCP servers move the tool code to the app's own vendor. The open question becomes where the calls go, and who is allowed to make them.

Linear, Datadog, GitLab and PostHog each run an MCP server of their own. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. An engineer can paste one of those server addresses into Claude this afternoon, and it will work. Then support wants Linear in ChatGPT, and finance wants another app in Cursor. Each request is reasonable on its own. Together they become a list of servers, clients and sign-ins that nobody owns.

This post covers one choice for each of those servers. You can point every AI client at the vendor's server directly, or connect it once through Elaichi as a native MCP connector. Elaichi's catalog holds two kinds of connector. Most are connectors Elaichi writes and runs itself. A native MCP connector is the vendor's own server: the vendor builds and runs it, and Elaichi handles sign-in, access and audit in front of it.

What happens when each AI client connects to the vendor directly?

Each client becomes its own setup, with its own rules and its own record. Calls a client makes to a vendor's server directly do not pass through Elaichi, so Elaichi does not govern them.

The setup work repeats for every client. On Claude Team and Enterprise plans, an Owner adds a remote MCP server as a custom connector, and each member then clicks Connect to sign in (Anthropic, checked October 2026). In ChatGPT, an admin or owner creates a custom MCP app, gives the server's endpoint and sign-in method, and scans its tools (OpenAI, checked October 2026). Cursor reads servers from an mcp.json file in a project or in each person's home directory (Cursor docs, checked October 2026).

Three vendor servers across three clients can mean nine separate setups. Each one keeps its own idea of which tools are allowed. Claude sets tool permissions per connector, per group of tools or per tool, but only inside Claude (Anthropic, checked October 2026). None of those settings follows a person into another client. When someone leaves, the offboarding list includes every client where they signed in to a vendor's server.

What does Elaichi add in front of a vendor's MCP server?

Elaichi puts the vendor's server behind the same address, sign-in, rules and audit log as every other connector. The vendor's tools still run on the vendor's server.

One address. Claude, ChatGPT and Cursor all sign into https://api.elaichi.ai/mcp with OAuth, the standard way an app gets scoped access without a password. Tools from every connected app come through that one address, whichever vendor makes the app. A model finds a connected tool with search_tools and runs it with execute_tool. Elaichi staff already publish Linear's server in the catalog, so nobody adds it to each client: each member connects it once.

Each person signs in as themselves. Each person signs in to Elaichi as themselves. Members connect with their own sign-in at the vendor, and a connection someone shares runs on its owner's account. For an OAuth server, that runs through an OAuth client Elaichi set up. Elaichi's separate credential service keeps the credential and fetches it for each call. The AI client holds only its Elaichi token. Elaichi never forwards that token to the vendor's server, which sees only a token its own authorization server issued.

Rules checked before the call leaves. A restriction is a rule that blocks or allows connectors and tools. It can name the whole connector or a single tool. In Elaichi, restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything. Every check runs before a call leaves Elaichi for the vendor's server. By default, a tool the vendor does not label read-only or non-destructive counts as destructive. Over MCP it needs the "Delete data and remove access" consent, which is never ticked by default.

One audit log. The audit log is the record of who did what. Each call that runs is recorded with the person, the tool, the connector, the connection it reached and the AI client that sent it. A Linear call from Claude and a Datadog call from Cursor land in the same log. Everyone can see their own activity there, and people with the audit permission see the whole organization.

One offboarding step. A grant is the approval a person gives one AI client to act for them in Elaichi. In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change. The person's next call fails in every client at once, whichever vendor's server it was headed for.

What stays with the vendor?

The vendor owns the server and every tool on it. Elaichi governs the calls, and its staff do not write or curate the tools.

By default, the tools a member can call are the ones the vendor's server lists to the connection they use. Elaichi reads that list when the connection becomes active, when someone refreshes it, once a day, and when a call names a tool the list lacks. Different connections can see different tools, because each list comes from that connection's own account.

When an automatic refresh adds, changes or re-tiers a tool, Elaichi writes an audit entry with the counts, naming up to 20 of the added and re-tiered tools. A vendor changing what its server offers is therefore on the record, not just in the vendor's release notes.

Tool issues go to the vendor. Each native MCP connector page names the vendor's support contact, an email address or a link, as on the Linear connector page. Someone who can manage the connector can still turn a single tool off for everyone while the vendor looks into it. A restriction can block it for one role instead, and a restriction change takes effect within about two minutes. If Elaichi unpublishes a server, its connections are kept and show as unavailable, and they work again if it is published again.

What does routing through Elaichi cost you?

It adds a hop, some limits and one more party in the path. Name these before you route every vendor server through Elaichi.

• A second party in every call. A call passes through Elaichi and then the vendor. Elaichi does not run the vendor's server, so an outage or a faulty tool there is the vendor's to resolve.
• Limits per call. Elaichi gives the vendor's server 30 seconds per operation and 60 seconds per call, retries included. It caps one tool result at 4 MiB, and one connection at 500 tools.
• Coarser switches in the client. Behind Elaichi, a client sees execute_tool rather than each vendor's tools. A Claude permission set on execute_tool covers every connected app at once, so tool-level rules belong in Elaichi.
• No per-call approval over MCP. Once a person's grant holds the delete consent, a tool that deletes runs without a per-call approval. Without that consent, the call is refused.

When is a direct connection enough?

A direct connection is enough when one team uses one vendor's server from one client, and that client's own controls cover the risk. Elaichi adds little in that case.

A five-person engineering team using Linear's server only in Claude can manage it from Claude's console. Claude's per-tool settings can block a tool or require approval for it (Anthropic, checked October 2026). The case for Elaichi starts when a second client or a second team appears. It also starts when someone asks for one record of what every AI did, across every app.

The same logic covers a server that is not in Elaichi's catalog. An Org Owner or Org Admin on Gold, or on Black once it launches, can add a remote MCP server reachable over public HTTPS as the organization's own connector. Its calls then follow the same rules and land in the same audit log. A server on a private network or a laptop cannot be added that way, and stays a direct connection.

How does a native MCP connector differ from one Elaichi writes?

The difference is who writes and runs the tools. The address, the rules and the audit log are the same for both kinds.

Both kinds sit side by side in the connector catalog, where a native MCP connector carries the MCP mark beside its name. Datadog and PostHog are native, and Salesforce is one Elaichi writes. For the model underneath, read what an MCP control plane is. For what each client's own console can and cannot do, see the admin controls in Claude, ChatGPT and Cursor.

FAQ

Can I connect a vendor's MCP server to Claude directly instead of through Elaichi?

Yes. On Claude Team and Enterprise plans an Owner adds the server as a custom connector, and each member connects it (Anthropic's help center, checked October 2026). Calls made that way go straight to the vendor's server and do not pass through Elaichi, so Elaichi's restrictions and audit log do not apply to them. Each other client then needs its own setup for the same server.

Who fixes a broken tool on a native MCP connector in Elaichi?

The app's vendor builds and runs a native MCP connector's server and tools, and Elaichi staff do not curate them. Report the problem to the vendor through the support contact on the connector's page. Inside Elaichi, someone who can manage the connector can turn that tool off for everyone, or a restriction can block it for one role.

Do Elaichi's restrictions apply to a vendor's own MCP server?

Yes, for every call made through Elaichi. A restriction can block the whole connector or a single tool for a role or one person, and it is checked before the call leaves Elaichi for the vendor's server. By default, a tool the vendor does not label read-only or non-destructive counts as destructive, so over MCP it also needs the "Delete data and remove access" consent.

Does the AI client hold my credential for the vendor's app?

No. The AI client signs in to Elaichi with OAuth and holds only an Elaichi token. The credential for the vendor's app is kept by Elaichi's separate credential service and fetched for each call. Elaichi never forwards its own token to the vendor's server, which sees only a token its own authorization server issued.

Why a shared service account fails the first access review

A finance analyst asks Claude for last quarter's unpaid invoices. The call has to reach the accounting app as somebody. Most first builds answer that with a service account: one API key, one bot user, wired in for everyone. The alternative is AI agents with employee permissions, where each call runs on the grant of the person who asked.

A service account is one identity holding the union of everyone's access. Three failures follow from that single sentence, and each one surfaces in a different room.

Reach. The bot has to cover the widest user of the app, so it carries records and fields the narrowest user should never see. Everyone who can prompt the assistant inherits that reach by default. A support rep asks the assistant to "check this customer's account". That call is routed through a credential that can also see payroll data, refund limits, and every other customer record the app holds. The bot's single API key was provisioned for whoever on the team needed the broadest access.

Attribution. The SaaS app's own log shows the bot, not the person. A deal stage changes in Salesforce. The audit log answer to "who changed this" is the same service-account name for every person in the company, every time. An investigator cannot tell whether a CFO or a first-week hire triggered a sensitive export. The app's native logging has no way to distinguish them, because as far as that app is concerned, there's only one user.

Revocation. Removing a person from the identity provider touches nothing the bot holds. The API key lives in a config file or environment variable outside the IdP's reach. So offboarding a person through Okta or Entra does nothing to the credential. The key keeps working for whoever else still points at it. Rotating it is a single change that breaks every integration built on that key at once, not a per-person revocation.

A key sitting in a client config has further problems of its own. Credential sprawl follows across every client that stores it. There is no scoping per use case, and no expiry tied to employment status. OAuth or API keys for AI agents works through them in detail.

The three patterns compared:

What does it take to run AI agents with employee permissions?

The AI client becomes an MCP client on one organization-wide endpoint, and each employee signs in once with their own OAuth grant. No shared key exists, so no identity holds the union.

MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. In Elaichi the address is POST https://api.elaichi.ai/mcp, the same for every organization. Standard MCP over Streamable HTTP, JSON-RPC 2.0, stateless, behind OAuth. It follows the MCP authorization specification's model of per-client, per-user grants rather than a single server-held credential. There are no per-toolbox URLs and no embedded tokens, so there is no server to create or revoke per person. The grant is what varies.

An admin adds that address once where the client allows it. A custom connector in Claude Team or Enterprise, a custom app in ChatGPT Business, a shared server in Cursor. Each member then connects and signs in themselves. That is one browser step per person, not zero. The tradeoff for eliminating the shared key is that every new employee has an onboarding action instead of inheriting a pre-wired bot.

The client registers itself through OAuth dynamic client registration, so there is no client ID or secret to type. The person lands on Elaichi's consent screen, picks the organization if they belong to more than one, and ticks scopes. Every scope the client asked for is pre-ticked except delete, which is never pre-ticked by default. The asymmetry is deliberate, since over-granting read access is recoverable and over-granting delete is not.

After that, each call is checked three ways, every time, not just at sign-in:

1. Role check. The person's role must carry tool:execute, or the tool list comes back empty.
2. Scope check. The grant's scopes gate what the endpoint will advertise and run.
3. Restriction check. Restrictions are rules naming which connectors and tools a target may reach, written per whole app or per single tool. They are enforced against the same resolver at every place a member can reach a connector or tool, including listing, connecting, advertising, executing, the final outbound-request check and opening a stored tool file. In Elaichi, restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything.

A rule aimed at a member can only narrow what their role allows, and never replaces or loosens a role rule.

Freshness is the part people get wrong. A permission model that only checks at OAuth consent time is a permission model that's wrong the moment someone's role changes. In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change. A role or restriction change is different in kind from a full grant revocation, and takes effect within about two minutes.

When should the app itself see the person, not a shared account?

Whenever the record ought to carry a name. The way to get that is a template each person stamps onto their own connection. A shared connection runs on its owner's credential regardless of who triggers it.

The distinction is worth being exact about, because the two look similar and behave very differently:

• A toolbox shared at use runs on the connection pinned in its entries, which belongs to the owner. Every grantee's call reaches the app as that one account, and the app's log names the owner rather than the person who asked. This is correct for the named-service-identity pattern below and wrong for everything else.
• A template holds a tool list with renames, defaults, and frozen parameters, and never holds a connection. Share it at use, and each member stamps their own toolbox from it. Stamping fills each entry from connections that person already has permission to use, so the resulting toolbox runs on their own account. An entry with no usable connection is left as "needs connection" until they connect one themselves.

So never pair "each person connects their own account" with "share one toolbox with the team". That combination silently collapses into the owner's identity. Per-person connections need a shared template, not a shared toolbox. Stamping copies the template once, so editing the template later does not retroactively change a toolbox someone already stamped from it.

This is what makes the Salesforce or Zendesk record show the rep or the agent who asked, instead of a generic integration user. It also means a person's reach inside the app is exactly whatever their own account already had, nothing more. The app's own permission model still binds, and Elaichi narrows it further rather than widening it. A template or restriction can remove access the person's app account technically has. Nothing can grant access their account doesn't have.

What the audit trail says when an agent acts for someone

The person is the actor, not the client and not the organization. Elaichi writes one entry for each connected-tool call that reaches execution (a call refused earlier writes none), with actor_kind recorded at the point of action rather than inferred afterward from context.

For a call from Claude, ChatGPT, Cursor, or any other MCP client, actor_kind is user. The surface is mcp, and the OAuth client is named on the entry. The client's name is marked verified only when its redirect URIs prove it, which covers Claude, ChatGPT, and Cursor among others. A client signing in through a loopback address, such as Claude Code or Codex CLI, shows the name it registered with, marked unverified. The distinction matters because an unverified client name is the name the client registered with, not one its redirect URIs prove. The value ai_assistant marks the in-app Elaichi Agent only, so do not expect it on an MCP client's call.

Each entry names the connection actually reached, taken from the execution rather than from the intent expressed in the tool call. That answers the first question after an unexpected change. Which of the two Notion workspaces did it actually write to, not which one the prompt seemed to ask for.

The approval line is stated in plain words on the entry rather than left for someone to reconstruct from scope lists. For an MCP call it reads "Allowed by the access the client was granted," because over MCP the OAuth grant is the approval. There is no separate in-the-moment approval step the way there is for a chat-window write gate. The trail is append-only and eventually consistent, so a row may take a moment to appear after the call completes. What an AI agent audit log must capture goes field by field.

Where delegated sign-in stops

Three limits apply.

Sign-in needs a browser. Claude Code, or any client, running headless in CI or in a terminal with no browser cannot complete Elaichi's OAuth sign-in. Unattended jobs are not covered by the delegated pattern, so do not plan a nightly reconciliation job around it. That is what the named service identity pattern below is for.

An organization API token resolves to the member who created it, so it carries that member's permissions and no more. It is not a separate, broader credential. It is created only from a browser session with a step-up approval. It reaches less than a browser session does, because several routes are human-session-only by design.

The REST API has no route that runs a connected tool. Connected tools run over POST /mcp with a person's OAuth grant, or inside the Elaichi Agent, and a synthetic tool's execute route is owner-only. So "an agent with the employee's permissions" specifically means an MCP client holding that employee's own OAuth grant. It is not a long-lived token calling a REST endpoint on their behalf.

The prompt-injection write gate in the Elaichi Agent chat window does not apply to POST /mcp, and cannot. An MCP server never sees the user's prompt text. It only sees the tool call the client already decided to make. What holds on the endpoint instead is role checks per operation, the forbidden classification, output redaction, OAuth scope limits, and audit logging of each call that reaches execution. These are enforced regardless of what any client-side safety layer does or doesn't do.

When a named service identity is still the right answer

A job nobody is asking for in chat still needs an owner. Take a weekly team report, a recurring sync, or a workflow where one argument must never vary across runs. These are team-owned, not person-triggered. The honest shape for them is a named person who owns the connection. Not a bot account, and not a per-person grant, since there is no "person" triggering the call.

Set it up this way:

1. Pick an owner who is staying, not a departing employee, not a contractor near the end of an engagement.
2. The owner connects the account and leaves that connection unshared with the team.
3. The owner pins it into a toolbox entry with the arguments frozen. That strips those keys from the advertised schema and merges the frozen values over whatever the model passes. So the model literally cannot override the frozen argument, not just "isn't supposed to."
4. The owner shares the toolbox at use.

Grantees can now run the tool only through that entry. They cannot open, see, or share the underlying connection, and it is absent from their own tool set by design. One gap to watch: anyone who also independently holds use on that same connection can call the same tool unfrozen. That is exactly why the connection itself stays unshared rather than relying on a restriction to close the gap. A restriction will not help here. Restrictions resolve the called tool's identity at advertise and execute, toolbox entries included. So a block on the tool withholds the frozen entry too, defeating the point.

The owner vouches for the entry on every single call. If that person loses use, is removed, or is suspended through SCIM, the entry resolves as unmet for every grantee until someone re-pins it. The job doesn't silently fail open onto a different account, it stops. Offboarding is built around this. A private connection pinned by a toolbox its owner shared is marked as needing resolution. The person's removal is blocked until an administrator decides what happens to it. Lock AI agent tool arguments, like a wire's payee covers the freeze itself, and offboarding AI access covers the exit in full.

When you do not need this pattern at all

If three people use one app in one client, the app's own native MCP server is the shorter road. One exists for Notion, HubSpot and Slack among them. It runs under that app's own permission model, and each person signs in with their own account. There is no second vendor, no control plane, and no extra abstraction to buy or maintain. The pattern described in this post earns its keep specifically when the count rises on more than one axis at once. Several apps from several vendors. Several AI clients in use across the team. And a reviewer who wants one audit trail and one offboarding step instead of N separate ones per app.

It is also the wrong frame if the agent is a product you ship to customers rather than a tool your own employees use. Authorizing end users inside your own multi-tenant application is an authorization-library problem. Think an OAuth/OIDC provider plus a policy engine in your own stack, not a control-plane-for-internal-tools problem. When you don't need an MCP gateway yet draws that line more slowly.

For the architecture underneath all of this, start with the control plane explainer. For how one role per member shapes the permission layer, read designing roles for AI agents. The 600+ apps a person can connect their own account to are listed in the connector catalog.

FAQ

Can an AI agent use an employee's own permissions instead of a shared service account?

Yes, if the agent is an MCP client holding that employee's own OAuth grant. In Elaichi the AI client points at one organization-wide endpoint, the employee signs in once in a browser, and every call is then checked against that person's role, grant scopes and restrictions. No shared key exists, so no single identity holds the union of everyone's access.

What happens to an AI agent's access when the employee leaves?

In Elaichi, removal is the fast path: removing or suspending a member revokes every live grant in the same transaction as the membership change. A role or restriction change is slower, taking about two minutes. Removal ends access through Elaichi only; the person's account inside each SaaS app still has to be deprovisioned there.

Does a shared connection give each person their own access to the app?

No. A shared connection runs on its owner's credential, so every grantee's call reaches the app as that one account. To have the app see each person, share a template instead. Each member stamps their own toolbox from it, and stamping binds every entry to a connection that member can use, so the call runs on their own account.

Can an API token run a connected tool on a user's behalf?

No. In Elaichi the REST API has no route that runs a connected tool; connected tools run over the MCP endpoint with a person's OAuth grant, or inside the Elaichi Agent. An organization API token does resolve to the member who created it and carries that member's permissions, but it reaches less than a browser session does, because several routes are human-session-only.

How do unattended jobs work if sign-in needs a browser?

They do not use the delegated pattern. Any MCP client running headless in CI or in a terminal with no browser cannot complete Elaichi's OAuth sign-in. A recurring team-owned job instead needs a named owner who connects the account, leaves that connection unshared, pins it into a toolbox entry with frozen arguments, and shares the toolbox at use.

Where do you approve apps for Claude?

Finance asks for Xero in Claude. You switch something on. A month later somebody has connected a note-taking app nobody reviewed. There are two places you approve apps for Claude, and they answer different questions. Claude's own admin console decides which connectors exist in your Claude organization. Elaichi decides which company apps sit behind the one custom connector you added, and which tools inside them each role may reach.

MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. A connector in Claude is an MCP server Claude is allowed to talk to. An app in Elaichi is a connected account: one Zendesk workspace, one Salesforce org, one Xero company file. Approving a connector and approving an app are different units of control, which is why one surface does not replace the other:

This same two-surface pattern, client-level connector approval plus a server-side control plane for app-level and tool-level approval, applies to any MCP client, not just Claude. The specifics below are Claude's, but the pattern generalizes to ChatGPT, Cursor, or any other MCP-capable client pointed at the same custom connector.

Approving connectors inside Claude Team and Enterprise

In Claude Team and Enterprise, a connector stays off until an Owner adds it. Directory connectors are added by an Owner or Primary Owner at Organization settings, then Connectors, by browsing the directory and adding one to the team. Adding connects nobody. Each member still signs in to that connector with their own account (support.claude.com, checked October 2026).

On Team, members have an intake path. A member sees a Request button on a directory connector. Owners find the pending ones under "Requested by your team" in Organization settings, Connectors, and on the Requests tab in Notifications, then enable or dismiss them (claude.com/docs/connectors/directory, checked October 2026). Anthropic's page does not say Enterprise members get the same button, so do not plan a rollout around it.

Custom connectors are narrower. A custom connector is a remote MCP server you point Claude at, which is what Elaichi's endpoint is. Owners and Primary Owners add one. On Enterprise, so can a custom role carrying Libraries (Manage). Ordinary members cannot add one; they connect and enable what was already added, and a Free account is limited to a single custom connector (support.claude.com, checked October 2026).

Then there are tool permissions. Each connector's tools can be set to Always allow, Needs approval or Blocked, per tool or per group, set by Owners and binding on members. On Enterprise, custom roles narrow that further. Know one thing before planning per-app approval there: Elaichi's connected tools all run through a single tool called execute_tool, so a permission set on that one tool in Claude's console covers every connected app at once, undifferentiated. Claude's console cannot distinguish "allow Xero" from "allow Zendesk" once both sit behind the same custom connector. Per-app and per-tool approval for those apps has to happen in Elaichi, not in Claude's connector settings.

What Claude's connector controls do not reach

Anthropic is explicit about the edge of these controls. Its guidance on custom roles says connector tool permissions "don't govern connectors a member runs locally on their own machine" (support.claude.com, checked October 2026). A server an engineer installed in a local config file sits outside the console entirely, and no Owner setting reaches it. Shrinking that population is a separate job, covered in replacing personal MCP servers on laptops.

A second gap is worth putting to Anthropic directly. As of this writing, Anthropic's published docs do not state whether removing a connector revokes members' already-issued OAuth tokens for it or merely hides the connector from the UI going forward. Treat that as an open question, not a settled fact, until Anthropic documents it. Do not assume removal equals revocation. On the Elaichi side the behavior is written down. A person ends their own grant under Settings, then Connected apps. In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change.

Writing the approved-apps list in Elaichi

Behind the single custom connector, Elaichi starts permissive and you narrow it. Every organization uses one address, https://api.elaichi.ai/mcp, added once. A Member role holds connection:create, so with no restriction in place a member can connect any of the 600+ apps in the catalog using their own account. That is the right default for a pilot and the wrong one for a company of 300.

A restriction is a rule naming which connectors and which individual tools a target may reach. Targets are a role or a single user. There is no organization-level target, because the organization default is the absence of any rule, which means allow everything. So the approved-apps list is an allow rule written on the role. There is no separate "approved apps" object; the rule itself is the list.

Three properties decide whether the rule you write is the rule you meant:

• 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 easy to create by accident, for example by saving a rule before adding any entries to it.
• An allow rule naming a connector whole reaches all of that connector and denies everything else. That is how an approved-apps list is written.
• An allow rule naming a connector whole and some of its tools reaches all of that connector anyway. The tool entries grant nothing extra and read as tighter than they are. The API refuses that overlap on new rules, so it cannot be created going forward, but check existing rules for this pattern if they predate the validation.

Within a layer, blocks union with blocks, allows union with allows, and blocks always beat allows. A member is under two layers at once: the rules on their role and the rules aimed at them. A connector or tool is reachable only when both layers admit it. So a rule aimed at one person can only narrow what the role allows. The same resolver runs everywhere a member can reach a connector or tool. Four of its checks decide most cases:

1. Browse: what the member sees when listing available connectors and tools.
2. Connect: whether the member is permitted to link an account to a given app.
3. Advertise: whether the tool is included in the schema Claude's model actually sees.
4. Execute: whether a specific call is allowed to run.

A final check on the outbound URL runs independently of those four. A tool withheld at the advertise step is left out of the tool list and cannot be called. Search names it, flagged restricted, with no schema. For the split between allowing an app whole and allowing single tools, see restricting one tool or the whole app.

A role or restriction change takes effect within about two minutes. Plan a change window of a few minutes, then verify with a test account before telling the requester it's done.

Write blocks and allows knowing they match differently. A block matches the tool's advertised name or the operation pinned at write time. An allow matches the pinned operation only. A tool's advertised name can be changed by whoever edits the connector's documentation, so governance binds the operation, never the label. A rename should not silently reopen something you blocked. The reasoning is in why blocks match names and allows do not.

Whose account does an approved app run on?

Approving the app is half the decision. The other half is whose credential the calls run on. When each person connects their own account, the app's own permission model stays in play, and the audit trail inside that app names the right person. A shared connection runs on its owner's credential, so every call through it reaches the app as that one account, regardless of who initiated the call from Claude.

If one argument has to be fixed for a whole team, say a specific wire-transfer receiver, a specific Slack channel or a specific cost-center ID, a restriction is the wrong instrument, because a restriction only decides reachability, not argument values. Use frozen parameters on a toolbox entry instead. Frozen keys are stripped from the advertised schema, so the model cannot fill them in. It can see short frozen values in the tool description, but it cannot change them, and frozen values are merged over whatever the caller passes, after the fact. Precedence runs: entry defaults, then caller arguments, then frozen parameters. Frozen always wins last.

The freeze holds only on the path that runs through the entry. So the owner leaves the connection unshared, pins it into a toolbox entry with the frozen values, and shares the toolbox at use. Grantees run the tool only through that entry. Anyone who also holds use on the connection itself can still call the same tool unfrozen, through the raw connection. Closing that second path with a restriction does not work, because a block would withhold the frozen entry too, not just the raw path. The worked example is in locking an agent's tool arguments.

Access requests as the intake for the next app

Access requests are Elaichi's version of Claude's Request button, and they work across every connected app, not just directory ones. Any member can file one, with no permission needed to ask. Resolving one needs member:manage, and an admin cannot decide their own request. That is a hard rule, not a convention.

An admin decides a request in the console, under Governance, then Access requests, with a step-up check. Approving a request creates an access grant for that one person. The grant lifts exactly the approved connector or tool out of their role rules. Every other role rule still binds them, nobody else on the role changes, and no rule is written. The grant is standing, not a one-time pass. It lasts until the member is removed or an admin approves a replacement.

Two limits belong in your runbook. First, neither an MCP client nor the Elaichi Agent can approve or deny a request from inside a chat. Nobody approves their own request either. Second, when the request names an app Elaichi does not carry, such as GitHub, Datadog, Linear, or any app outside the catalog, the answer is different: either the app's own MCP server, or a custom connector pointed at it. Keep connector:create on roles you already gate carefully, because a custom connector can be pointed at any destination, including ones you did not intend.

The record of what was approved and used

The audit trail turns an approval into evidence. An audit log here is an append-only record of actions.

Elaichi writes one entry for each connected-tool call that reaches execution (a call refused earlier writes none), not just successful calls. The entry also records the surface the call came through and the OAuth client it came from, with the client's name marked verified only when its registered redirect URIs prove it. Claude is among the clients that verify.

Approval is stated in plain words on the entry. For example, "Allowed by the access Claude was granted" for a call over MCP, or "Didn't need approval because it only read data." That sentence, read next to your allow rule, is the before-and-after pair a reviewer wants: the rule as written, and the system's own statement of why a specific call was or wasn't let through. Give the reviewer the free read-only Auditor seat rather than an admin login. They need to read the trail, not change the rules. More on what belongs in those records: what an AI agent audit log must capture.

A checklist to run for each new app

Run this once per app request, in order. It takes a few minutes and it survives a change of admin.

1. Name the app and check the catalog. If Elaichi does not carry it, decide between the app's own MCP server and a custom connector before anything else.
2. Decide whose account it runs on. Per-person connections keep the app's own permissions in play. A shared connection reaches the app as its owner, for every caller.
3. Decide app-wide or tool-level. Allow the connector whole when the whole app is approved. Do not mix a whole-connector entry and tool entries in one allow rule. The API will reject the overlap.
4. Write the rule on the role. A rule aimed at one person can only narrow what their role allows. Use it to give one person less. Give one person more through an access request.
5. Verify what a member sees. Wait about two minutes for the change to take effect, then check the tool list from a test account on that role. A withheld tool is missing from the tool list, so there is no error to spot and you have to check directly. Search still names it, flagged restricted. The other reasons a tool goes missing are in the missing-tool checklist.
6. Leave access requests as the intake. The next app should arrive as a request you decide on, not as a connection you discover later in an audit log.
7. Name the reviewer. Decide who reads the audit trail each month, and give them the Auditor seat, not an admin login.

When one approval surface is enough

If your company runs Claude and nothing else, and the approved list is one or two SaaS tools that ship their own MCP servers, Anthropic's directory and tool permissions are the whole job. A second control plane buys you nothing yet. The case for a control plane like Elaichi starts when the same approval has to hold across Claude, ChatGPT and Cursor at once, when the number of approved apps is large enough that per-connector console toggles stop scaling, or when a leaver's access through the endpoint has to end for every connected app in one action. That threshold is argued in when you do not need an MCP gateway yet.

For the shape of the thing behind the single custom connector, read what an MCP control plane is. For the rollout order across clients, see how to roll out Claude and ChatGPT to employees, and for the setup itself, connecting Elaichi to Claude. To check which apps are already covered before you write the allow rule, browse the connector catalog and the team use cases.

FAQ

Who can add a custom connector in Claude Team and Enterprise?

Owners and Primary Owners add a custom connector, which is how a remote MCP server such as Elaichi's endpoint gets into a Claude organization. On Enterprise, a custom role carrying Libraries (Manage) can also add one. Ordinary members cannot add a custom connector; they connect to and enable what was already added (support.claude.com article 11175166, checked October 2026).

How do I stop employees connecting apps we have not approved?

In Elaichi, a member with no restriction in place can connect any app in the catalog with their own account. To limit that, write an allow rule on the member's role naming each approved connector whole. The presence of an allow rule turns on the allowlist, so everything not named is denied. The change takes effect within about two minutes.

What does an allow rule that names nothing do?

It denies everything. 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 easy to create by saving a rule before adding any entries to it.

How long does a restriction change take to apply?

Within about two minutes. Role changes and restriction changes in Elaichi resolve through a short cache, on every surface, so they are not immediate and not applied on the next call. Grant revocation, member removal and suspension are different: they take effect on the caller's very next request, as does revoking a share or disconnecting an account.

Do Claude's per-tool permissions control which company apps an employee can reach through Elaichi?

Not individually. Elaichi's connected tools are all called through a single tool named execute_tool, so a Claude tool permission set to Always allow, Needs approval or Blocked on that one tool applies to every connected app at once. Per-app and per-tool approval for those apps is written as a restriction in Elaichi instead.

Why does every team reach the whole catalog by default?

Because the absence of a rule means allow-all. A head of IT connects Elaichi and points Claude, ChatGPT and Cursor at one address. Sales, support, engineering and finance all sign in to the same place. With no restriction written, a member can connect any catalog app with their own account. Approved AI tools per team is therefore something you write down, not something you inherit.

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, and each member signs in there with their own OAuth grant. OAuth is the browser sign-in that issues a scoped token instead of handing over a password. The catalog behind that endpoint holds 600+ connectors. No team needs all of them. Four teams typically need four different slices of them. Sales needs CRM and email. Finance needs the accounting suite and nothing with write access to it. Engineering needs the issue tracker and source control. Support needs the helpdesk and nothing else.

The problem is not specific to Elaichi. Any shared endpoint that several teams sign in to needs a written rule before those teams reach different things. The rest of this post sets out the general framework, then how Elaichi implements it.

The general framework: enforcement and curation are two different jobs

This distinction holds regardless of which platform you're on:

• Enforcement is a restriction bound to an identity (a role or a user). It determines what is reachable at all.
• Curation is what a person picks from whatever enforcement left reachable. It determines what is convenient, not what is possible.

A restriction decides which connectors and which individual tools a target may reach. In Elaichi it is checked against the same resolver at every place a member can reach a connector or tool, including listing, connecting, advertising, executing, the final outbound-request check and opening a stored tool file. A tool a role cannot reach is withheld from the tool list and cannot be called. Search names it, flagged restricted, with no schema. That holds whichever client the person is using: Claude, ChatGPT, Cursor, or a custom agent.

Curation is softer by design. A template is a tool list someone assembled for a team. The consent-screen choice between "All my tools" and "Only the ones I pick" is the person's own scoping. Neither stops anybody from reaching something else they are already allowed to reach. Treat a curated toolbox as a control and the approved-apps plan stops being one. A toolbox changes what shows up in a menu, not what the model can call.

How to write approved AI tools per team as allow rules

A role's approved-apps list is its allow rules, and naming whole connectors is fine. Allow rules on the same role union, so one allow rule per app works. The role's allowlist is all of its allow rules together.

The trap: an allow rule is the target's whole allowlist, across every connector, not an incremental grant layered on top of some implicit baseline. Once the sales role holds an allow rule naming Salesforce, every connector and tool that role's rules do not name is denied for that role. That is the behavior you want from an approved-apps list, as long as you name every app the team uses. Miss one and the team loses it silently, with no error, because "not listed" and "denied" are the same state.

Worked example. Say the sales role needs Salesforce, Gmail, and Slack, and nothing else:

Three allow rules, unioned, form the complete list. Add a fourth app later and sales gains it within about two minutes of the rule being saved. Forget to add it and sales never sees it, with no visible error on either side.

Two more mechanics decide how the first rule behaves:

• An allow rule naming connector X whole, plus some of X's tools, reaches all of X. The tool entries grant nothing extra. The API refuses that overlap on new rules, so you can't accidentally create a rule that looks more specific than it is.
• An allow rule naming nothing denies everything. It is the strictest rule you can express.

Holding one app to its read tools is a different move once the role already has an approved-apps list. Allow rules on one role union. So if finance's allow rules name QuickBooks whole, a second allow rule naming only its read tools changes nothing. The union still reaches all of QuickBooks. To hold QuickBooks to reads, name its read tools in place of the whole connector, or keep the whole-connector allow and put blocks on its write tools. Blocks union with each other, and blocks always beat allows regardless of which rule was written first. Which writes to block is a question a pilot's own call record answers, and narrowing to the tools people actually used keeps that list honest.

The two rule types also match differently. A block matches on the tool name or on the operation pinned against the catalog at write time. An allow matches on the pinned operation only. Whoever edits a connector's documentation can change an advertised tool name. So allows bind the operation rather than the label, and a rename cannot widen what an allow reaches. Why blocks match tool names but allows do not covers that asymmetry, and restricting one tool against restricting the whole app works through six cases.

A rule aimed at a member can only narrow what their role allows, and never replaces or loosens a role rule.

Which identity-provider group maps to which role?

Map each team's group to its own role. The reason is that restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything. A SCIM group mapping can confer at most one role, and a member holds exactly one role, enforced by a unique index. SCIM (System for Cross-domain Identity Management) is the provisioning standard your identity provider uses to push users and groups into an application.

So the shape is one role per team persona: a sales role, a support role, an engineering role, a finance role. Each is a complete persona rather than a bolt-on, which is the point of the one-role-per-member rule. It is also the main design constraint to plan around. Custom roles are a Gold-tier feature, so check pricing before planning a role structure that depends on them.

Verified domains and SSO connections each carry a configurable default role, and domain, SSO and SCIM joins fall back to Member when none is set.

Team membership is set separately from role. SCIM and group mapping never set team membership. People who join by SCIM, domain or SSO are added to teams afterward, and invites can preset teams. Teams matter for sharing (templates, toolboxes), not for enforcement (allow/block rules). A SCIM deprovision suspends the member rather than removing them, which revokes every live grant immediately. Removal is a separate step an admin takes in Elaichi afterward. SCIM and AI agents covers where provisioning stops and manual admin action starts.

How does each person get a curated list on their own accounts?

Share a template with the team at use, and let each member stamp it. Stamping creates that person's own toolbox. Each entry is bound to a connection that person can use, with them recorded as the delegator. An entry with no usable connection is left as "needs connection" rather than failing silently.

Worked example. The sales lead builds a template called "Sales Outreach" with five Salesforce tools, three Gmail tools, and two Slack tools, each with sensible defaults. The lead shares it with the Sales team. Each rep stamps it:

1. Rep A has already connected their own Salesforce and Gmail accounts, so all ten entries bind to Rep A's own connections.
2. Rep B has connected Gmail but not Salesforce yet, so the five Salesforce entries sit as "needs connection" until Rep B connects.
3. The template itself never holds a connection; only each stamped copy does.

A template holds a tool list with renames, defaults and frozen parameters, and it never holds a connection itself. Stamping copies the list once, so editing the template later does not change a toolbox already stamped. Re-share and re-stamp when the list changes.

Do not pair "each person connects their own account" with "share one toolbox." A toolbox shared at use is the opposite arrangement. Every grantee's call runs on the connection pinned in its entries, which is the owner's account, not the grantee's. That's correct when one account should serve a whole team (a shared support inbox, a shared CRM user). It is wrong when each rep should reach only their own records.

A frozen argument inside a stamped toolbox is not a control over the person who stamped it. A freeze holds only on the path that runs through that entry. Anyone holding direct "use" on the underlying connection can call the same tool unfrozen. Locking an argument for a team requires an unshared connection, pinned into a toolbox by its owner and shared at use. Locking AI agent tool arguments sets out the mechanism, such as freezing a wire-transfer receiver account number so no rep can redirect funds.

On the consent screen, a member who ticks "Run your connected tools" gets a second step. "All my tools" is the default. It picks up accounts they connect later and connections shared with them later, so it is a live, expanding grant rather than a snapshot. "Only the ones I pick" narrows the grant to chosen toolboxes, up to 50. If none of those toolboxes resolves any more, say because the underlying connection was revoked, the client sees no connected tools. There is never a silent fallback to everything.

The consent checkboxes do not make a connected app read-only. For a connected app's tools, "run your connected tools" covers reads and writes alike; only a delete action costs an extra destructive-action scope. Read-only access to an app is achieved through a restriction (a block on write tools), not through consent-screen choices.

What happens when finance asks for an app outside the list?

It becomes an access request. Any member can file one with no permission needed; resolving one needs member:manage, the permission that covers managing people.

Approving a request creates an access grant for that one requester only. The grant lifts exactly the approved connector or tool out of their role rules. The role's other rules still bind them, and the rest of the team is unaffected. No rule is written, and the role is not edited. The grant lasts until the member is removed or an admin approves a replacement. An admin cannot approve their own request. The Elaichi Agent and MCP clients can neither approve nor deny a request. An admin decides it in the console, under Governance, then Access requests.

Human approval for AI agent actions sets out the other approval layers, such as per-call approval for destructive actions, independent of access requests.

Time it accordingly: an approval, like any restriction change, takes effect within about two minutes. A team membership change sits in the same bucket. Removal is faster. In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change.

When are Claude and ChatGPT approval lists enough on their own?

When you run exactly one AI client and its own approval settings give the granularity you need. Both vendors ship that natively, and it is less setup than a separate control plane. The trade-off is granularity and cross-client consistency.

Sources: Claude tool permissions (support.claude.com, checked October 2026); ChatGPT role-based access control (help.openai.com, checked October 2026); ChatGPT per-app read and write actions (help.openai.com, checked October 2026).

Two things change the moment a second AI client appears in the organization. First, approvals don't transfer. The same person reaches the same underlying data under two independently-configured lists, one per client. Keeping them in sync is manual. Second, to ChatGPT, a control plane like Elaichi looks like one custom app. Its tools are search_tools, execute_tool, and its own operations. So ChatGPT's per-action switches can toggle the control plane on or off as a whole. They cannot distinguish which catalog app behind it a call is targeting. Per-app and per-tool approval for the apps behind that single connector has to be written in the control plane itself, not in ChatGPT's admin panel.

For the client-side path on its own, without a control plane, there are standalone guides for approving apps in Claude and restricting ChatGPT Enterprise connectors.

The honest part: the role binds, not the team

Restrictions bind a role or a single user. They do not bind a team. A team is a sharing construct, which is why templates go to teams and allow rules go to roles.

That split has a practical consequence. If two people sit on the same team but hold different roles, they reach different apps. A shared template then stamps differently for each. One person's stamped entries might resolve to real connections, while the other's sit at "needs connection" because their role never granted that app. If one person needs a wider list than their role allows, the clean answer is an approved access request, which creates an access grant for that one person. A rule aimed at that person cannot help, because it can only narrow what their role allows. A second role is not an option, since a member holds exactly one role. Design the four roles first and the four teams second. Retrofitting roles after teams are already full of mixed-permission members is the harder order to untangle.

From here: the MCP control plane overview explains the endpoint these rules sit on. Designing roles for AI agents covers the one-role constraint in depth. The connector catalog is where you check that the apps a team wants are ones Elaichi already serves.

FAQ

Can an Elaichi restriction target a team?

No. In Elaichi, restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything. Because each member holds exactly one role, the usual pattern is to map each identity-provider group to its own role and write that role's approved-apps list as allow rules. Teams are used for sharing templates and connections, not for enforcement, and team membership is set separately from SCIM or group mapping.

How do you give one team read-only access to a single app?

It depends on whether the role already has allow rules. If the role has none, put block rules on that app's write tools, because an allow rule naming only its read tools would become the role's entire allowlist across every connector and the role would lose its other apps. If the role already has an approved-apps list of allow rules, name that app's read tools in place of the whole connector, or keep the whole connector and block its write tools. Blocks always beat allows.

How long does a restriction or role change take to apply in Elaichi?

Within about two minutes. Role membership, restrictions and team membership all resolve the same way, on MCP, the console and the REST API alike. Some changes are faster. In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change.

Should a team share one toolbox or one template?

Share a template when each person should run on their own connected account. A template holds a tool list and never holds a connection, and a member who holds use on it stamps their own toolbox, with each entry bound to a connection they can use. Share a toolbox instead when the team should run on one account: every grantee's call then runs on the connection pinned in that toolbox's entries, which belongs to its owner.

What happens when someone requests an app that their role does not allow?

They file an access request, which any member can do with no permission needed. Resolving it requires the member:manage permission, and an admin cannot decide their own request. Approving a request creates an access grant for that one requester. The grant lifts exactly the approved connector or tool out of their role rules. Every other role rule keeps applying, and nobody else on the role changes.

Why Confluence in ChatGPT takes a second step

Someone asks ChatGPT what the incident runbook says, and ChatGPT has nothing to read. Confluence is not one of ChatGPT's built-in synced sources: those are Google Drive, SharePoint and Teams only (help.openai.com, checked October 2026). To reach Confluence, ChatGPT has to go through MCP. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps.

Two routes implement that for Confluence. Atlassian runs its own remote MCP server, surfaced in ChatGPT as the "Atlassian Rovo" app. Elaichi serves a confluence connector through one organization-wide MCP endpoint, alongside the rest of a catalog of 600+ connectors. Both can preserve a person's own space permissions when configured correctly. They differ on how many apps and how many AI clients one setup covers, and on what a security team can see and restrict afterward. The comparison is laid out below.

The requirement that decides between them is blunt. A person with no access to the Security space must not read its pages through an assistant. That holds only when every call runs with that person's own Confluence identity, not a shared one.

How do Confluence space permissions survive the hop?

They survive when the connection is per person and the sign-in is OAuth. OAuth is the sign-in flow where someone approves an app in the browser and no password or API key is copied anywhere. Atlassian is explicit that OAuth 2.0 (3LO) apps act on a user's behalf, and that "Confluence permissions also control access to data and aren't overridden by scopes" (developer.atlassian.com, checked October 2026). A broad scope does not widen what someone can see. A call made with a person's own credentials sees what that person sees in the browser, and nothing else.

That matters because Confluence permissions are not flat. Space roles (Admin, Manager, Collaborator, Viewer, plus custom roles) decide who works in a space. A page-level view restriction hides a page even from people who hold space view (support.atlassian.com, checked October 2026). On Premium and Enterprise, an organization admin can still override page restrictions with an admin key. That is the one documented exception to "the viewer sees only their own permissions."

In Elaichi, per-person identity comes from a template, not from a shared toolbox. This is Elaichi-specific mechanics, not an Atlassian concept. A template holds a tool list with overrides and defaults, and never holds a connection itself. Share it with the team at use, and each member stamps their own toolbox from it. Stamping binds each entry to the stamper's own Confluence connection, so every call reaches Confluence as that member, under that member's space roles. The same pattern, applied to a CRM, is written out in the per-rep Salesforce rollout.

Sharing one toolbox does the opposite. A shared connection runs on its owner's credential, so every call lands as that single account, and space roles stop following the person. Elaichi's confluence connector also accepts OAuth client credentials, which sign in as one identity for everyone who uses it: useful for a scripted or scheduled job, wrong for a human reading team. Rule of thumb: client credentials for a scheduled job that should run as one service identity; per-person OAuth wherever space permissions should follow the person.

When is Atlassian's own MCP server enough?

It is enough when one AI client talks to Atlassian products and nothing else. Atlassian's remote MCP server sits at https://mcp.atlassian.com/v2/mcp and "never grants access beyond what the user already has" (developer.atlassian.com, checked October 2026). It has been generally available since 4 February 2026 (atlassian.com, checked October 2026). It names ChatGPT and Claude as supported clients (support.atlassian.com, checked October 2026). It is open to all Atlassian Cloud customers with hourly call limits by plan (atlassian.com, checked October 2026). It can create and update Confluence pages (support.atlassian.com, checked October 2026). Some search calls cost 1 to 10 Rovo credits each, while single-product lookups and writes are free (support.atlassian.com, checked October 2026).

The admin controls are real, not theoretical. Under Atlassian Administration, then Rovo, then Rovo MCP server, an admin allows or blocks Atlassian's default domain list as a whole, and that list includes chatgpt.com. Your own domains can be added, and API tokens turned on or off (support.atlassian.com, checked October 2026). A Permissions tab turns Read, Write and Search on or off per app, and overrides Connected apps settings (support.atlassian.com, checked October 2026). No documented single switch turns the whole server off.

Two broader Atlassian controls sit underneath that. "Block user apps," under Connected apps, is available on every plan, and user-installed apps are allowed by default (support.atlassian.com, checked October 2026). The policy now called "Marketplace and custom app access" blocks all apps on any plan, but choosing which specific apps to allow back in requires Atlassian Guard Standard or Premium (support.atlassian.com, checked October 2026). Budget for that licensing tier before planning an allowlist. It is a real cost of the "allow specific apps" path, not a footnote.

The decision point is concrete, not a matter of preference: if the tools in scope are only Confluence and Jira, and ChatGPT is the only client reading them, Atlassian's server plus its native Read/Write/Search toggle and domain allowlist are sufficient. There is no permission gap for an aggregator to close. The case for a second endpoint shows up once any of these is true: a second AI client is in play (Claude plus ChatGPT, say), the same team also needs Zendesk, Slack or Salesforce behind the same assistant, you want one restriction written per role instead of one per app's native console, or you want one audit query that spans tools instead of stitching logs from each vendor's admin panel by hand. Outside those conditions, a gateway you do not need yet adds an endpoint to secure without closing a gap that existed.

Which of the 18 Confluence tools should a reading team keep?

Keep the 15 reads and block the 3 writes. Elaichi's confluence connector carries 18 tools (live catalog, read October 2026). The reads cover pages, spaces, CQL search, attachments, labels, users, groups, a user's groups, accessible resources, the signed-in user, and list_all_confluence_audit_logs.

The writes are create_a_confluence_page, update_a_confluence_page_by_id and confluence_groups_remove_member. The update tool does more than edit text: it can move a page under another parent, transfer its owner, and restore a trashed page, any of which changes who can see what afterward. The group-removal tool is a delete that removes a user from a Confluence group, an admin-level action no ordinary reading role needs. The same shape of decision, applied to contracts, is worked through in the Ironclad playbook for legal.

Write this as blocks on a role, not as an allow rule. An allow rule is that role's entire allowlist across every connector the role touches, so naming only Confluence read tools in one would silently deny Zendesk, Slack and everything else the role uses, a side effect that is easy to miss until someone reports a missing tool weeks later. Blocks on the three writes leave the rest of the role's apps untouched. Blocks also match on the tool name or the pinned operation, which is why a block holds when a tool is renamed. The general choice between a tool-level block and an app-level block is laid out in six worked cases.

Do not try to get the same result from ChatGPT's own per-action switches. To ChatGPT, Elaichi is one custom app whose tools are search_tools, execute_tool and Elaichi's own operations, because connected tools are never listed one by one, however few there are. So ChatGPT's per-action switches cannot tell one connected app or tool behind it from another. The only place "read-only Confluence, except for this one admin" can be expressed precisely is inside Elaichi's restriction layer, not inside ChatGPT's settings.

Setting it up, in the order that works

Decide the Atlassian side first, then ChatGPT, then the restriction, then the people. Each step is short, and the order avoids a half-connected team where some members have stamped a template and others are still sharing one account.

1. Settle Atlassian's app controls. If you are allowing specific apps rather than blocking all of them, confirm you hold Atlassian Guard Standard or Premium before you plan the allowlist.
2. Add Elaichi in ChatGPT. An admin creates the custom app from the workspace admin console and publishes it; full MCP support is in beta on Business, Enterprise and Edu plans (help.openai.com, checked October 2026). The address is https://api.elaichi.ai/mcp, and the walkthrough is in the ChatGPT connection guide.
3. Write the restriction on the role that will read Confluence. Block the three write tools named above. A restriction change takes effect within about two minutes, on every surface: ChatGPT, Claude, or any other connected client.
4. Build the template from the Confluence tool list and share it with the team at use.
5. Each member connects their own Confluence account and stamps the template. The resulting toolbox runs on their connection, under their own space roles, not the admin's who built the template.
6. Each member signs in from ChatGPT. On Elaichi's consent screen they pick the organization and tick "Run your connected tools," then choose "Only the ones I pick" and select the Confluence toolbox. "Delete data and remove access" is never pre-ticked; leaving it off keeps the group-removal tool out of both the active toolset and search results.

A missed scope does not fail silently. The endpoint answers with an in-band tool error naming the checkbox and telling the person to reconnect and allow it. Reconnecting fixes it, as long as the client asked for that scope in the first place. If the client itself never requested the scope, reconnecting alone will not surface it.

One line worth putting in internal onboarding instructions: Elaichi's consent screen warns that anyone can register an app under any name and logo, and shows the redirect host. People should only continue from a sign-in they started themselves, not one they were sent a link for.

What the audit trail shows after a page edit

Elaichi writes one entry for each connected-tool call that reaches execution (a call refused earlier writes none). Each entry names the Confluence account actually reached, not a generic "ChatGPT" actor.

Audit events and application logs share one record shape, so a single query answers what happened instead of correlating two systems by eye. Each entry also records the surface and the OAuth client. ChatGPT is among the clients whose redirect URIs mark the client name as verified, so a Confluence page created from ChatGPT is attributable without guessing from a user-agent string. The approval line on an MCP call reads along the lines of "Allowed by the access ChatGPT was granted." A call from an MCP client is recorded with actor_kind user, not as an assistant, and the distinction matters for anyone reconstructing who actually approved a given write.

The trail is append-only, newest-first, filterable by actor, category and time, and eventually consistent, so a row can take a moment to appear after the call completes. A departed member renders as "Former member" rather than disappearing from historical rows. The audit trail inside Elaichi is included on the Gold plan. Forwarding it to your own Datadog comes with the Black plan, launching soon.

What this setup does not do

It does not change anything inside Atlassian. Removing someone in Elaichi ends their access through Elaichi only. In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change. Their Confluence account still exists, and it must be deprovisioned in Atlassian or through your identity provider separately. Elaichi offboarding and Atlassian offboarding are two different actions. Revoking a share or disconnecting an account takes effect on the caller's next request; role and restriction changes take effect within about two minutes.

It does not defend the endpoint against prompt injection. An MCP server never sees the user's prompt, so a prompt-level filter cannot exist at that layer by construction. What does hold at the endpoint: role permissions per operation, restrictions, OAuth scope limits, output redaction and audit logging of each call that reaches execution. If prompt injection is the threat model, the control has to sit somewhere else in the stack. This setup addresses permission scope, not prompt content.

It does not make per-person identity automatic. If somebody shares a Confluence connection instead of stamping the template, every call runs as that owner regardless of who is typing in ChatGPT. The only way to verify the setup is correct is to check the connections themselves, not to assume intent from how the template was distributed.

For the tool lists behind each app, see the connector catalog. The wider shape this sits inside is covered in the control plane explainer, the same per-person pattern for a different app is in the Salesforce rollout for sales, and the ChatGPT-side switches are compared in the Enterprise connector guide.

FAQ

Does ChatGPT have a Confluence connector?

No. ChatGPT's synced sources are Google Drive, SharePoint and Teams, and Confluence is not among them ([help.openai.com](https://help.openai.com/en/articles/10847137-administrator-managed-apps-with-sync-in-chatgpt), checked October 2026). Confluence reaches ChatGPT through an MCP server instead: either Atlassian's own remote MCP server, surfaced in ChatGPT as the "Atlassian Rovo" app, or a governed MCP endpoint such as Elaichi's, which serves a Confluence connector alongside other company apps.

Do Confluence space permissions still apply when ChatGPT reads a page?

Yes, provided the connection signs in as the person. Atlassian states that OAuth 2.0 (3LO) apps act on a user's behalf and that Confluence permissions are not overridden by scopes ([developer.atlassian.com](https://developer.atlassian.com/cloud/confluence/oauth-2-3lo-apps/), checked October 2026). Space roles and page view restrictions carry through. A connection that uses client credentials signs in as one identity for everyone who uses it, so permissions then follow that single account rather than the person asking.

How do you stop an AI assistant from editing Confluence pages?

Block the write tools for the role that should only read. Elaichi's Confluence connector carries 18 tools: 15 reads, plus create_a_confluence_page, update_a_confluence_page_by_id and confluence_groups_remove_member. Blocking those three leaves the reads intact and leaves the role's other apps untouched. A restricted tool is withheld from the tool list and cannot be called, and the change takes effect within about two minutes.

Do you need Atlassian Guard to allow ChatGPT on Atlassian's MCP server?

Blocking all apps works on any Atlassian plan, but choosing which specific apps to allow needs Atlassian Guard Standard or Premium, under the policy now called "Marketplace and custom app access" ([support.atlassian.com](https://support.atlassian.com/security-and-access-policies/docs/block-app-access/), checked October 2026). Separately, the Rovo MCP server settings let an admin allow or block Atlassian's default domain list as a whole, which includes chatgpt.com, and turn Read, Write and Search on or off per app.

What does a Confluence tool call look like in the audit trail?

Elaichi writes one entry for each connected-tool call that reaches execution (a call refused earlier writes none). Each entry names the Confluence account actually reached, the surface and the OAuth client, with ChatGPT among the clients marked verified.

Google Drive in Claude: the two shapes that work

Someone in finance asks for Claude to read the board folder. Someone in support asks for Claude to search whatever they can already open in Drive. Those are two different builds. Treating them as one request is how a connection ends up reaching every file in the company.

Google Drive access from an AI client reduces to two honest shapes, regardless of which vendor's connector you use:

1. Per-user OAuth: each person connects their own Google account, so their existing Drive permissions bound every call.
2. Dedicated account: one Google account, with only the target folders shared to it, draws the folder line, and the team shares that one connection.

These are not Elaichi inventions. They are the two access patterns any OAuth-based Drive integration can offer. A Drive call made with a person's OAuth token is bounded by that signed-in account. Elaichi serves both through one organization-wide MCP endpoint. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. Elaichi writes and runs most of its 600+ connectors, Drive among them. So Drive is served from Elaichi's infrastructure rather than a server someone on your team has to stand up and patch.

The same address answers ChatGPT and Cursor. The folder question does not change per client, and neither does the answer below.

Simplest case first. You just want Claude to read whatever one person can already open in Drive, with no folder boundary and no shared account. Shape 1 is it: connect your own Google account, done. The rest of this post is for the harder case. One version: the AI needs to see less than one person's full Drive. The other: the access needs to be shared across a team without multiplying individual logins.

How does each person keep their own Drive permissions?

Each member connects their own Google account (shape 1). The way to hand that out at team scale is a template, not a shared toolbox. This part is Elaichi-specific plumbing. It is described here because it's the mechanism, not because it's the only way to think about the problem.

A template holds a tool list with renames, defaults and frozen arguments, and never holds a connection. Share it with the team at use. Each member then stamps their own toolbox from it. Stamping binds every entry to a connection that person can use, so their own Google account runs the call. Stamping copies once, so a later template edit leaves already-stamped toolboxes alone. A member who has not connected Google yet sees that entry marked "needs connection" until they do.

Sharing a toolbox does the opposite: every grantee's call then runs on the connection pinned in its entries, which belongs to the owner. Never pair "each person connects their own account" with "share one toolbox with the team". That silently runs everyone's calls on the owner's own Google account, with the owner's full Drive access.

This part is universal, not vendor-specific: Google enforces access at the API layer, not the AI client. The Drive API bounds every call by the signed-in user. It returns 404 notFound where the person has no read access, and 403 where they have no write access (developers.google.com, checked October 2026). A support agent asking about a folder nobody shared with them gets nothing back, for the same reason they see nothing in Drive itself. The same per-person shape is what keeps each rep inside their own Salesforce sharing rules.

Can an OAuth scope limit Drive access to specific folders?

No. Stated flatly: no Google Drive OAuth scope confines an app to a folder.

• drive.file reaches only files the app created or opened, or that the user picked via Google Picker, a per-file consent pattern, not a folder boundary.
• drive, drive.readonly, and drive.metadata.readonly reach the user's entire Drive (and any shared drives they belong to).
• There is no drive.folder scope and no documented scope parameter that recurses into a folder tree.

(Source: developers.google.com, checked October 2026.)

A query such as 'FOLDER_ID' in parents and trashed = false narrows a search, and Google does not document it as recursive into subfolders. A search filter is not a permission, and a model calling the tool can omit or alter the filter on its own.

So the only real folder line is drawn at the account level, not the scope level: the Google account the connection signs in with. The working pattern is:

1. Create a dedicated Google account.
2. Share only the folders that team should reach, to that account, in Drive's own sharing UI.
3. Connect that account to the MCP server (Elaichi or otherwise).
4. Share that one connection with the team.

A shared connection runs on its owner's credential. So every call reaches Drive as that account and sees exactly what was shared to it, nothing more. The dedicated account itself has nothing more. Anthropic recommends the same dedicated-account pattern for Claude Tag's Google connection. The account starts at no access and gains specific folders one at a time (claude.com, checked October 2026). Before relying on the line, open Drive as that account and check what it can already see, such as files shared with your whole domain.

Two trade-offs come with this pattern:

• Ownership: the dedicated connection has an owner in Elaichi. Pick an owner who is staying, and transfer the connection during their offboarding. The credential is the dedicated Google account, not the owner's own, so a transfer keeps it working.
• Scope only narrows the connection it's on. A member who also connects their personal Google account reaches Drive under "All my tools" with their own full Drive access. That is shape 1 running beside shape 2, for that person only.

Which tools can the Google Drive connector actually run?

Elaichi's googledrive connector connects over OAuth and carries 28 tools; 25 of them read. Files, folders, shared drives, drive items, search, export, permissions, labels, revisions, comments and replies, Docs, Forms and the change log are all reads. Names run like list_all_googledrive_files and get_single_googledrive_file_by_id. The full list is on the Google Drive connector page.

The other three are create_a_googledrive_watch, create_a_googledrive_changes_watch and delete_a_googledrive_channel_by_id. The first two ask Google to post change notifications to an HTTPS address the caller supplies. The third stops a channel. None of the 28 creates, edits, shares, moves, or deletes a file.

A team that only reads blocks those three tools. Blocks, not allows, are the right instrument here, for a structural reason:

• An allow rule becomes that role's entire allowlist across every connector, so the role loses every other app it had.
• A block removes exactly the named tools and leaves everything else untouched. Three blocks leave 25 reads.

In Elaichi, restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything. A restriction change takes effect within about two minutes. Restrictions are applied before search, so a withheld tool stays out of the tool list and cannot be called. search_tools names it, flagged restricted, with no schema. The case-by-case version of this choice is in restrict one AI tool or the whole app.

One thing the OAuth consent screen does not do: leaving "Create and change data" unticked does not make a connected app read-only in Drive. That checkbox governs Elaichi's own internal operations, not what the Drive API will accept from the connected account. Read-only access to Drive is a restriction you apply explicitly (the three-tool block above), not a side effect of a consent checkbox. It is the same way QuickBooks has to be held to reads when the vendor ships no read-only scope.

What does a Google Workspace admin set before any of this?

The Workspace control is Manage App Access, under Security, then Access and data control, then API controls. An app, found by name or OAuth client ID, is set to Trusted, Limited, Specific Google data, or Blocked. Unconfigured apps fall under "Allow users to access any third-party apps" (knowledge.workspace.google.com, checked October 2026).

Order matters, and getting it backwards breaks working connections:

1. Mark the app Trusted first.
2. Restrict afterward (e.g., set Drive to Restricted for the org).

Setting Drive to Restricted before trusting the app revokes untrusted apps' tokens, including ones that were working that morning. Google's high-risk Drive scope list includes drive, drive.readonly, and drive.metadata.readonly, but does not include drive.file. Elaichi's console does not show which Google scopes its Drive connector requests. So find the app by name or OAuth client ID, rather than inferring it from the high-risk scope list.

Shared drives need a separate argument entirely. The Drive API returns shared-drive items only when a call sets supportsAllDrives=true and includeItemsFromAllDrives=true. The corpora argument takes one of user, domain, drive, or allDrives (developers.google.com, checked October 2026). Google also states admins have no control over individual folders inside users' My Drives. That is another reason the dedicated-account pattern, not a central Workspace policy, is how a folder boundary actually gets drawn. Per-tool arguments are on the Google Drive connector page.

Claude native connector vs. ChatGPT Drive app vs. an MCP endpoint

Sources: Anthropic states Claude "mirrors your existing permissions" (support.claude.com, checked October 2026). OpenAI documents live access for a personal connection, and admin-managed sync through a domain-wide delegation service account. Individually authorized sync is retired (help.openai.com, checked October 2026). Drive actions start off on Enterprise and Edu and on for Business (help.openai.com, checked October 2026).

When to just use Claude's native connector and stop. Drive is the only app the team needs. They need to upload, share, move, or trash files from the chat, not just read. Use it. It's on all plans; an Owner or Primary Owner enables it under Organization settings, Connectors. No folder or shared-drive restriction is documented for it, and each person connects their own Google account. So a folder boundary needs the dedicated-account pattern, through a connector that can share one connection.

The caveat on the Elaichi row: to ChatGPT, Elaichi presents as one custom app whose tools are search_tools, execute_tool and Elaichi's own operations. ChatGPT's own per-action approval switches therefore cannot distinguish Drive from any other app behind Elaichi. That granularity has to be enforced inside Elaichi's restrictions, not in ChatGPT's UI. The broader trade-off is in Claude and ChatGPT connectors vs one MCP endpoint.

Adding the endpoint, approving the scopes, and the record afterward

The address is https://api.elaichi.ai/mcp, the same for every organization. In Claude Team and Enterprise, an Owner adds it under Organization settings, Connectors, Add, Custom, Web. Members then connect it under Customize, Connectors (support.claude.com, checked October 2026). There is no client ID, secret, or header to type, because the client registers itself through OAuth dynamic client registration.

On Elaichi's consent screen the person picks the organization first. Then come the checkboxes: Read your organization's data, Create and change data, Run your connected tools, and Delete data and remove access. Delete is never pre-ticked. With "Run your connected tools" ticked, a second step asks for All my tools or only chosen toolboxes. For the dedicated-account shape, picking just the Drive toolbox is the tighter choice: All my tools also reaches every other connection that person holds personally.

Afterward, the record is plain. Elaichi writes one entry for each connected-tool call that reaches execution (a call refused earlier writes none). The record carries the one path argument that names the object as the target id, and no other argument value: no argument names and no count. So the log shows which object was acted on, not what was written to it. That answers the first question in an incident: who reached which Google account, through which client. The entry carries the surface (mcp), and the OAuth client it came through, marked verified for Claude, ChatGPT, and Cursor. The audit trail inside Elaichi is on the Gold plan; forwarding it to your own Datadog comes with the Black plan, launching soon.

If you're still deciding whether any of this machinery is warranted, start with what an MCP control plane is for. If you've decided, the Claude connection walkthrough covers sign-in, and the team use cases show what other teams set up next.

FAQ

Can you limit an AI assistant's Google Drive access to specific folders?

Not with an OAuth scope. Google publishes no Drive scope that confines an app to a folder, and an 'in parents' query is a search filter rather than a permission. The practical boundary is the Google account the connection signs in with: create a dedicated account, share only those folders to it, and connect that account. In Elaichi, sharing that connection at use means every call reaches Drive as that account, because a shared connection runs on its owner's credential.

Does Elaichi's Google Drive connector let an AI agent edit or delete files?

No. The connector carries 28 tools, 25 of which read files, folders, shared drives, search results, permissions, revisions, comments and the change log. The other three are create_a_googledrive_watch and create_a_googledrive_changes_watch, which ask Google to post change notifications to an HTTPS address the caller supplies, and delete_a_googledrive_channel_by_id, which stops a channel. None creates, edits, shares, moves or deletes a file, and a team that only reads blocks those three.

What happens when someone asks an AI assistant for a Drive file they cannot open?

Google answers the call, not the assistant. The Drive API bounds every request by the signed-in user and returns 404 notFound where that user has no read access, and 403 where they have no write access. So a connection made with a person's own Google account can never surface a document that person could not already open in Drive.

How quickly does a Google Drive restriction take effect in Elaichi?

A restriction or role change takes effect within about two minutes, on every surface. Revoking a share of a connection, or disconnecting the account, takes effect on the caller's very next request, because grants and connections are read fresh on every call. In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change.

Should a Google Workspace admin mark an app Trusted before restricting Drive?

Yes, and the order matters. In Manage App Access an app is set to Trusted, Limited, Specific Google data, or Blocked. Setting Drive to Restricted revokes the tokens of apps that are not trusted, so mark the app Trusted first and restrict afterward. Google's high-risk Drive scope list includes drive, drive.readonly and drive.metadata.readonly, and does not include drive.file.

Why SharePoint in Claude needs per-person OAuth

SharePoint in Claude stays inside each person's own permissions only when every call is delegated. That means each person signs in with their own Microsoft account. The app never acts beyond what that account can already see. Microsoft states the rule for delegated permissions directly: "the application can't access anything the signed-in user couldn't access" (learn.microsoft.com, checked October 2026). Site permissions, library permissions and item-level restrictions then do the work they already do. The MCP layer adds no new access; it inherits what Entra and SharePoint already enforce.

Elaichi's SharePoint connector accepts two connection modes:

A client-credentials connection signs in as one app identity. Everyone who reuses that connection reaches whatever the app was granted. That is not what they personally can open in a browser. For keeping SharePoint permissions, that is the wrong shape.

Graph permissions come in two forms, and the distinction decides whether an admin has to approve anything. Delegated Sites.Read.All and Files.Read.All need no admin consent; their application (app-only) equivalents do (learn.microsoft.com, checked October 2026). In delegated mode, Graph intersects the app's granted scopes with the signed-in user's actual permissions. The app's scope is a ceiling, and the user's access is the real limit. The lower of the two always wins.

Share a template, not a connection

The per-person shape in Elaichi is a template shared at use, never a shared connection. A template holds a tool list with overrides, defaults and frozen arguments, and never holds a connection itself. This is the mechanism that keeps one shared setup from collapsing into one shared identity.

Build a template from the SharePoint connector and share it with the team at use. Each member then stamps their own toolbox from it. Stamping binds every entry to the stamper's own connection, so each person's calls run on the Microsoft account they signed in with. An entry with no usable connection is left as "needs connection" until that person connects, so it fails visibly, not silently.

A shared connection works the opposite way. It runs on its owner's credential, so every call reaches SharePoint as the owner, regardless of who triggers it. A toolbox shared at use has the same effect, because every entry in it is pinned to the connection its owner chose at creation time. For permission parity across a team, the template is the only one of the two that preserves per-person boundaries. A shared connection or a shared toolbox both re-create the app-only problem, just with a human owner instead of a service principal. The same fork appears in drawing the folder line in Google Drive, where a dedicated account is sometimes the better of the two shapes.

What Elaichi's SharePoint connector carries

Elaichi's sharepoint connector carries 97 tools. 49 have names starting list_ or get_, and they read. Most of the other 48 create, update, publish, upload or delete pages, lists, list items and files, and five change who can see what.

Elaichi authors and serves this connector from its own infrastructure, one of the 600+ connectors in its catalog. So no third-party MCP server sits in the call path between Claude and Microsoft Graph. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps.

Two tools behave differently from the rest:

• list_all_sharepoint_search runs Microsoft Search under the hood and is classified other, not read. A rule written to match "all read tools" will not catch it by accident, and a rule meant to allow it must name it explicitly.
• list_all_sharepoint_get_all_sites requires an app-only token. On a delegated connection it returns HTTP 403. That 403 is the expected result of per-person auth working correctly, not a connector fault. If you see it on a delegated setup, the setup is doing what it is supposed to.

The full tool list is on the SharePoint connector page.

Writing the allow rule for a reading role

Hold a reading role with an allow rule that names the read tools it needs plus list_all_sharepoint_search explicitly, since it is not classified read. A block list fails open on a connector this size. Of 97 tools, roughly 48 write or act. Every one you forget to name in a block list stays reachable. The same arithmetic plays out on Intune's 198 tools, where six blocks are not enough. An allow list fails closed instead, so anything not named is denied. That is the direction you want on a document store. The cost of one missed write tool is a deleted or overwritten file.

For a reading role, name tools such as list_all_sharepoint_sites, get_single_sharepoint_site_by_id, list_all_sharepoint_drives, list_all_sharepoint_drive_items, get_single_sharepoint_drive_item_by_id, list_all_sharepoint_lists, list_all_sharepoint_list_items and list_all_sharepoint_search.

One property of restrictions catches people out: an allow rule is the target's entire allowlist across every connector, not only the app it names. Once a role holds one allow rule, every connector that rule does not mention is denied for that role. That includes connectors that had no restrictions before. A support role reading SharePoint and working in Jira needs the SharePoint allow rule plus a separate allow rule naming Jira whole. It cannot rely on Jira being unrestricted by omission once any allow rule exists on that role. Allow rules targeting the same role union together, so one rule per connector is the normal way to compose this, not one giant rule.

In Elaichi, restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything. A block rule matches the advertised tool name or the pinned operation it maps to. An allow rule matches the pinned operation only. The mechanics are covered in why blocks match names and allows do not. A restriction change takes effect within about two minutes.

The five tools that change who can see what

Five tools in the SharePoint connector edit SharePoint's own sharing model rather than its content:

These are the tools that can quietly widen the permission model everything else in this post assumes is stable. An invitation sent to the wrong address opens that item to someone outside the team until someone notices and revokes it. A reading role keeps all five out simply by never naming them in its allow rule. There is nothing to block, because anything the allowlist does not name is already denied.

A withheld tool is not merely disabled. It is absent from tools/list and cannot be called. Search names it, flagged restricted, with no schema.

Does Sites.Selected limit SharePoint to chosen sites?

Sites.Selected is Microsoft's mechanism for holding an application to sites it has been granted explicitly, rather than tenant-wide. An app consented for a Selected scope has zero access at first. Access starts once it is granted a role on a specific site through POST /sites/{siteId}/permissions. The role is set to read, write, owner or fullcontrol. Creating that grant itself requires Sites.FullControl.All, and in a delegated flow requires a caller with SharePoint Administrator role or higher (learn.microsoft.com, checked October 2026).

Do not assume every third-party connector draws the site line this way. Sites.Selected is one specific Graph mechanism, and a connector can be delegated (per-user) without also being Selected (per-site). In Elaichi, the site line is drawn by the Microsoft account each person signs in with and by the restriction on their role. Elaichi's console does not show which Graph scopes its SharePoint connector requests, so do not assume it uses Sites.Selected.

For comparison, two other Microsoft-adjacent AI products sit at different points on this same spectrum:

Claude's own Microsoft 365 connector does not support Sites.Selected. Its SharePoint search runs tenant-wide under Sites.Read.All, limited to each user's own permissions (support.claude.com, checked October 2026). Microsoft Copilot sits in a comparable place. It "only surfaces organizational data to which individual users have at least view permissions" (learn.microsoft.com, checked October 2026). Restricted Content Discovery can hide a site from organization-wide search and Copilot without changing its underlying permissions (learn.microsoft.com, checked October 2026). Whether Restricted Content Discovery also suppresses a site from third-party Graph-based search, including Elaichi's, is not documented by Microsoft. Do not plan a security boundary around it.

When Claude's own Microsoft 365 connector is the better choice

If SharePoint is the only system your team needs inside Claude, and read access is all that is required, the answer is simpler. Anthropic's native Microsoft 365 connector is genuinely less machinery to operate. It is available on all Claude plans and takes a one-time Entra Global Administrator consent. On Team and Enterprise plans an Owner can also enable it. It is read-only by default; enabling SharePoint writes requires turning on write tools plus granting Files.ReadWrite.All (support.claude.com, checked October 2026). For a single-app pilot with one connector and no cross-tool audit requirement, that is usually the right answer and adds no operational layer worth maintaining.

The trade-off shifts once a role needs more than one system, for example SharePoint plus Jira, Zendesk or Salesforce. The alternative is writing and maintaining access rules separately in each vendor's own console, instead of once per role in a single control plane. It shifts again where a single audit trail needs to cover all the tools a given actor touched, not just one connector's logs. Whether that trade-off is worth the added layer depends on how many connectors a role actually spans, and on how centralized the audit requirement is. It is not automatically the right call for every team.

Adding the endpoint and what each person consents to

The address is https://api.elaichi.ai/mcp for every organization: one URL, not one per team. In Claude Team or Enterprise, an Owner adds it under Organization settings, Connectors, Add, Custom, Web. Members then connect it individually under Customize, Connectors (support.claude.com, checked October 2026). The same URL also serves ChatGPT, Cursor, any MCP-compatible client, and the Elaichi Agent.

Each person signs in on Elaichi's own consent screen, picks one organization, and ticks what the client may do. Delete is never pre-ticked by default. With "Run your connected tools" ticked, a second step asks whether to grant all tools or only chosen toolboxes. The consent request itself lasts 30 minutes before expiring. That is long enough to stamp a template in a second tab. It does need to happen in one sitting.

One mechanical detail trips people up. For a connected app's tools, the general tools checkbox covers reads and writes together. Only a delete action costs a separate destructive-action scope. Leaving "Create and change data" unticked does not make SharePoint read-only by itself. Read-only access is enforced by the allow rule on the role, not by this checkbox. That is covered in restricting one tool or a whole app.

What the audit trail records, and what leaving ends

Elaichi writes one entry for each connected-tool call that reaches execution (a call refused earlier writes none). The raw error text Microsoft returns to the caller is never copied into the audit record itself. That keeps third-party response payloads out of the audit log pipeline. The entry records that a call failed and which tool and operation it was, not the verbatim upstream error body.

The entry records the surface as mcp and names the OAuth client that made the call. Claude is among the clients whose identity is marked verified by its registered redirect URIs. A call made through an MCP client is logged with an actor kind of user. The grant backing the call belongs to that person, not to the client application.

When someone leaves the organization, removing or suspending them in Elaichi is what ends their access through Elaichi. In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change. Offboarding runs a preflight first. It lists every connection the departing member owns, private and shared alike. A shared connection can be transferred to one active member. A private connection that a shared toolbox relies on blocks the removal until it is transferred to one member or deleted. A private connection that nothing else depends on cannot be transferred and is deleted with the member. Nothing is transferred to a team or the organization, and nothing is silently transferred to the admin running the removal, which would otherwise let one admin accumulate other people's connections during offboarding. The full sequence is set out in offboarding when the agent holds the access. Removal ends access through Elaichi specifically; the person's underlying Microsoft account still exists and must be deprovisioned separately in Entra or through your identity provider. These are two different revocation events and neither one substitutes for the other.

For the wider model, see what an MCP control plane is.

FAQ

Can Claude see SharePoint files a person cannot open?

Not when the connection is delegated. With per-person OAuth, every Microsoft Graph call runs as the signed-in user, and Microsoft states that an application with delegated permissions cannot access anything the signed-in user could not access ([learn.microsoft.com](https://learn.microsoft.com/en-us/graph/permissions-overview), checked October 2026). The risk comes from client-credentials connections, which sign in as one app identity for everyone who uses them, and from sharing a connection or a toolbox in Elaichi rather than a template.

Does unticking "Create and change data" on Elaichi's consent screen make SharePoint read-only?

No. For a connected app's tools, the "Run your connected tools" scope covers reads and writes alike, and only a tool whose method is a delete needs the destructive scope on top. The "Create and change data" box governs Elaichi's own control-plane operations. Read-only access to SharePoint is a restriction: an allow rule naming the read tools the role needs, plus allow rules naming its other apps whole.

What is Sites.Selected, and does it apply to an AI connector?

Sites.Selected is a Microsoft Graph scope that gives an application no SharePoint access until it is granted a role on a specific site through POST /sites/{siteId}/permissions, with read, write, owner or fullcontrol. Creating that grant needs Sites.FullControl.All and, in a delegated flow, a SharePoint Administrator ([learn.microsoft.com](https://learn.microsoft.com/en-us/graph/permissions-selected-overview), checked October 2026). Claude's own Microsoft 365 connector does not support it ([support.claude.com](https://support.claude.com/en/articles/12684923-microsoft-365-connector-security-guide), checked October 2026), so check the vendor's own page before assuming any connector draws a site line that way.

How long does a SharePoint restriction take to apply in Elaichi?

Within about two minutes. The change applies on the MCP endpoint, in the console and over the REST API alike. Removal is faster. In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change.

Why use an allow rule instead of blocking the SharePoint write tools?

Elaichi's SharePoint connector carries 97 tools, about 48 of which write or act, so a block list leaves every write it fails to name reachable. An allow rule fails closed: anything it does not name is denied for that role. The trade-off is that an allow rule is the role's whole allowlist across every connector, so the role also needs allow rules naming the other apps it uses.

Finance drafts in ChatGPT. Two engineers run Cursor. The HR agent your platform team built sits in Microsoft Teams. Each surface reaches a different company app, under a different rule, and leaves a different record. Copilot Studio vs MCP gateway is the choice underneath that spread. Build agents inside Microsoft's own channels, or govern the AI clients your people already opened. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. Both approaches speak it. They differ on where the rules live and how fine they go.

A note on sourcing before the comparison starts. Every Microsoft claim below links to the live docs page and carries the date it was last checked. Treat that date as a freshness marker for the specific paragraph, not a publication date for the post. Where a claim describes Elaichi's own product, it's marked as such and should be weighed as a vendor description, not independent documentation. Verify it against the pricing and docs pages linked inline.

Is Copilot Studio an MCP gateway?

No. Copilot Studio is a place to build agents. A gateway is a place to govern clients somebody else built. The distinction matters because the two solve different problems. One gives a maker a canvas and a publish button. The other gives an admin a single policy surface over tools nobody on the admin team built.

In Copilot Studio a maker designs the agent and attaches tools to it. MCP support has been generally available since 29 May 2025. A maker adds it through the onboarding wizard at Tools, Add a tool, New tool, Model Context Protocol. A Power Apps custom connector is the other route. Streamable transport only, with None, API key or OAuth 2.0 for auth; tools and resources work and prompts do not (checked October 2026, Microsoft Learn). The finished agent runs in Microsoft Copilot, Microsoft Teams and other Microsoft channels. Microsoft documents no way to expose a Copilot Studio agent to Claude, ChatGPT or Cursor as an MCP server (checked October 2026, Microsoft Learn).

An MCP control plane inverts the shape. Nobody builds an agent. Every SaaS account the company uses is connected once, and the tools those accounts expose are served through one organization-wide MCP endpoint. Clients point at that one address and sign in: Claude, ChatGPT, Cursor or any MCP client. There are no per-toolbox URLs and no embedded tokens to hand around. Elaichi serves 600+ connectors, most of them authored on its own infrastructure and the rest vendors' own MCP servers it governs, so the company runs no MCP servers of its own. An app outside the catalog is covered by a custom connector authored from JSON config, or by a fork of a public one.

How does Copilot Studio govern MCP servers?

Through Power Platform, at the environment level, by the server rather than by the tool.

Each tool runs on the end user's credentials by default, so the agent reaches only what that person can reach in the destination app. Maker-provided credentials are optional. An admin can forbid them per environment. That lockdown also breaks scheduled, autonomous and background agents, since those have no interactive user to authenticate as (checked October 2026, Microsoft Learn).

Policy sits on the connector layer. Data policies sort connectors into Business, Non-business and Blocked, and cover an MCP server's tools too. Changes usually apply within an hour and can take up to 24 (checked October 2026, Microsoft Learn). Advanced connector policies are a default-deny allowlist per environment or group. Microsoft states that per-tool MCP control is not available in them (checked October 2026, Microsoft Learn). The Microsoft 365 admin center approves, rejects and blocks MCP registrations under Agents, then Tools (checked October 2026, Microsoft Learn).

The practical consequence is one sentence long. A ticketing MCP server exposing a read tool and a delete tool is allowed whole or blocked whole at the policy layer. Makers can switch off single tools per agent at build time. That's a design choice inside one agent. It is not an administrative control an IT admin can apply across every agent that touches that server.

What does a governed MCP control plane enforce instead?

This section describes Elaichi's specific implementation, not an industry standard. It is one way to build the generic pattern of RBAC plus resource-level sharing plus explicit allow/deny rules, and other gateways implement that pattern differently.

Three layers, and the finest of them reaches one tool for one role. Role-based access control (RBAC) comes first. It is 58 action strings such as tool:execute, restriction:manage and audit:view, grouped into roles. There is exactly one role per member, no stacking and no union of multiple roles. Resource sharing is second, and it is strict. A member sees only what they own or what was explicitly shared with them. There is no implicit visibility from being in the same team or role. Restrictions are third, and they are the layer that differs most from Copilot Studio's model. A restriction names whole connectors, single tools, or both. In Elaichi, restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything. The default is allow, not deny: with no rule written, a tool is reachable by anyone who holds use on its connection.

So the ticketing case splits cleanly. A Support role carries an allow rule naming the read tools. The delete tool never reaches that role's list. A restricted tool is withheld from the tool list and cannot be called, and search names it, flagged restricted, with no schema. Choosing the grain matters, because whole-app rules are sometimes the honest and lower-maintenance answer. Per-tool restrictions multiply the number of rules an admin has to keep correct as tools get added or renamed upstream.

Write the timing down before a reviewer asks. A role or restriction change takes effect within about two minutes. In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change. A SCIM deprovision suspends the member. That revokes every live grant at once, rather than waiting for a session or token to expire on its own.

Arguments can be pinned as well as tools. The connection's owner keeps it unshared, pins it into a toolbox entry with frozen values, and shares that toolbox at use. Frozen keys are stripped from the advertised schema, so the model has no input to fill in for them. Frozen values are merged over whatever the caller sends, overriding rather than just defaulting. Pinning an argument holds on the path that runs through the entry. It does not help if the same tool is reachable through a different, unpinned entry. Close that other path by leaving the connection unshared, because a restriction on the tool would withhold the frozen entry too.

Calls land in one audit log. Elaichi writes one entry for each connected-tool call that reaches execution (a call refused earlier writes none).

Here is what this model does not do. It has no low-code canvas for building a new agent. There is no conversation designer, and no equivalent of Copilot Studio's topic and trigger authoring. It governs clients that already exist; it does not help a team build one from scratch.

Copilot Studio vs MCP gateway: a side-by-side table

The two architectures diverge on audience, credential model, blocking granularity and billing unit. Read the table as a description of what each product was built for, including where each one is weaker, not as a scorecard.

There is no free Elaichi plan: two plans, Gold and Black. Elaichi offers a 14-day trial, no credit card to start. Checkout does collect a card, and it sets the paid trial to the remaining days rather than granting a fresh 14, so it is one continuous trial rather than two.

Where does Microsoft Agent 365 fit?

Microsoft is building a cross-client gateway of its own. The part relevant here is still in preview. That matters if you're deciding whether to wait for it.

Agent 365 has been generally available since 1 May 2026. The price is $15 per user per month, or included in Microsoft 365 E7 (Microsoft, checked October 2026). Its tooling gateway for registered bring-your-own MCP servers is a preview feature within that product. Admins approve and block servers at runtime. The preview clients include Copilot Studio, VS Code, Claude Code and GitHub Copilot CLI. Tool-level blocking for those servers is planned but not shipped. Gateway tool calls can be hunted in Defender (checked October 2026, Microsoft Learn). Azure API Management is positioned separately, to expose and govern MCP servers for ChatGPT, Claude and GitHub Copilot (Microsoft Learn, checked October 2026).

If the plan is to wait for Microsoft's gateway, the question to settle is narrow and concrete. Does server-level approval, whole server with no per-tool block yet, cover the review you have to pass this quarter. Do you need per-tool control before Microsoft ships it. Nobody outside Microsoft has a date for that.

When Copilot Studio alone is the right answer

Plenty of companies do not need a second control plane, and should not buy one.

If your people only use Microsoft Copilot and Teams, Copilot Studio reaches the apps. Power Platform holds the policy, and Purview holds the record (Microsoft Learn, checked October 2026). Your admins already run those consoles. A second product would add a second place for the rules to be wrong, and a second audit trail to reconcile during a review. The same logic holds for one team using one assistant against one app. That app's own MCP server, under its own permission model, is less to carry and needs no extra vendor.

The boundary moves the moment a non-Microsoft client appears on a laptop. A Cursor install or a ChatGPT workspace sits outside Power Platform, and the rules written there do not follow it. Power Platform's policies do not reach a connection made directly from Cursor to a third-party MCP server.

Running both without the rules drifting apart

Most companies that use Microsoft will run both. Decide early which surface owns which rule, in writing. Do that before the second product is purchased rather than after.

Copilot Studio owns agents built for Teams and Microsoft Copilot, governed by Power Platform data policies and connector allowlists. The MCP control plane owns Claude, ChatGPT, Cursor and the rest. It is governed by one role per person, restrictions down to a tool, and a single audit trail. The two do not overlap by accident. Elaichi does not list Copilot Studio among the clients it connects with. Agents built there stay on Power Platform's side of the line. Name the owner of each half and the review cadence for each. Quarterly connector audits in Power Platform, for instance. A separate cadence covers restriction rules in the MCP control plane.

For the category definitions underneath all of this, what an MCP control plane is is the place to start. The four gateway shapes sorts the rest of the market.

FAQ

Can Copilot Studio block a single tool inside an MCP server?

Power Platform advanced connector policies act as a default-deny allowlist per environment or group and block a whole MCP server, and Microsoft states that per-tool MCP control is not available in them (checked October 2026). Makers can switch off individual tools when building a given agent, and tool-level control inside a server is rolling out for servers registered on Agent 365.

Can Claude, ChatGPT or Cursor use an agent built in Copilot Studio?

Microsoft documents no way to expose a Copilot Studio agent to Claude, ChatGPT or Cursor as an MCP server (checked October 2026). Reaching those clients means giving them an MCP endpoint of their own to sign into, which is what a governed MCP control plane such as Elaichi provides.

How is Microsoft Agent 365 different from Copilot Studio?

Copilot Studio is an environment for building agents that run in Microsoft channels. Agent 365 is marketed as a control plane for agents, generally available since 1 May 2026 at $15 per user per month or included in Microsoft 365 E7; its tooling gateway for registered bring-your-own MCP servers is a preview in which admins approve and block whole servers at runtime (checked October 2026).

How quickly does a restriction change take effect in Elaichi?

A role or restriction change in Elaichi takes effect within about two minutes. Revoking an OAuth grant, removing a member or suspending one is effective on that person's next call, and so is revoking a share or disconnecting a connected account.

Do AI clients need separate credentials with an MCP control plane?

No. With Elaichi, every client points at the same organization-wide MCP endpoint and each person signs in over OAuth, picking scopes on a consent screen. There are no per-toolbox URLs and no embedded tokens to distribute to clients or employees.

How do you set up ClickUp in ChatGPT for a team?

Two decisions, then menu paths. Whose ClickUp account each call runs on, and which ClickUp tools the model can reach at all. Both are instances of a general MCP governance problem, not something specific to ClickUp. Any time you connect a chat client to a multi-user app through MCP, you have to decide two things. First, identity resolution: which backend credential a given call executes under. Second, tool surface: which of the connector's available operations are reachable at all. Setting up ClickUp in ChatGPT for a whole team is a governance question before it is a configuration one.

The situation is familiar. A customer success team runs client onboarding in ClickUp, one space or folder per account. The CSMs want to ask ChatGPT what is overdue on the Acme rollout. They also want it to update a task status, and to draft the weekly summary from the list. One person can do that today by signing in to ClickUp's own hosted server. Doing it for eight CSMs, with client data sitting in those spaces, is where the shape changes. Identity resolution and tool surface now have to hold across eight people instead of one.

This playbook uses Elaichi, a governed MCP control plane, as the worked example. 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 endpoint, POST https://api.elaichi.ai/mcp, behind OAuth. OAuth is the browser sign-in flow that issues a client a standing, revocable permission to call on a person's behalf. A static API key, by contrast, has no per-person revocation and no expiry tied to a session. ClickUp is one of the 600+ connectors in the catalog.

The order of work: write the restriction first, build and share a template second. Then let each CSM connect ClickUp, and add the endpoint in ChatGPT last. Skipping ahead and connecting accounts before the restriction exists leaves an unrestricted delete tool live in production before anyone notices.

Whose ClickUp account does each call run on?

Whichever connection the call resolves to. A connection shared with the team runs on its owner's credential, so every grantee's call reaches ClickUp as that one account. Get it wrong and permissions widen for everyone downstream of the share.

That matters more in ClickUp than in most apps, because ClickUp spaces are usually where client separation lives. If one ops lead connects ClickUp and shares the connection with the customer success team, ClickUp evaluates the ops lead's permissions on every call. A CSM who cannot open the Acme space in ClickUp can read it through that connection, in ChatGPT, with nothing misconfigured. The share is working as designed. The failure is in the sharing decision, not the software.

For a customer success team, pick the other shape:

• Per-person connection (recommended for this case). Each CSM connects ClickUp in Elaichi with their own ClickUp account. The Member role already holds connection:create, so nobody waits on an admin. ClickUp's own sharing then decides what each call can see, per person, with no second permission model to keep in step.
• Shared connection (correct only for a deliberate single view). A single reporting account that sees every client space, shared at use for a weekly rollup, is a reasonable thing to own. It should be a named decision with a named owner, not the default because it was the first thing someone set up.

Rule of thumb: some apps already enforce per-record access control, such as ClickUp spaces, Zendesk ticket permissions and Salesforce sharing rules per rep. Default to per-person connections there, and let that app's permission model do the work. Only use a shared connection when you want a view that deliberately ignores those boundaries.

Which ClickUp tools should a customer success role never reach?

The destructive ones and the access-granting ones. Block ClickUp's delete tools for tasks, lists, folders and spaces, plus the tools that create, update or remove guests and users.

The deletes are the obvious half of the table. The guest tools are the half teams forget. "Add a guest to this task" reads exactly like "update this task", in both the UI and in a model's tool-call log. There is no visual or semantic marker that distinguishes a data operation from an access-grant operation unless you block it explicitly.

A restriction is the rule for which connectors and 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. Write the block against the role the customer success team holds, which on the Gold plan can be a custom role. A block beats an allow. A block matches the tool's advertised name, or the operation pinned against the catalog when the rule was written. An allow matches the pinned operation only. That asymmetry has its own writeup in why blocks match names and allows do not.

A restricted tool is withheld from the tool list and cannot be called. Search names it, flagged as restricted, with no schema. The model has no description or schema to reason around, and no way to run it. A role or restriction change takes effect within about two minutes.

Resist the urge to write an allowlist instead, unless you mean it. The allowlist stage activates on the presence of an allow rule, not its contents. So an allow rule naming nothing denies everything, which locks the role out of every tool. For a team whose work is open-ended across client spaces, a short block list ages better than a long allow list. A long allow list runs to dozens of entries, one per permitted operation, and needs updating every time the connector adds a tool. The cases where one or the other wins are set out in restricting one tool or the whole app.

Why share a template instead of one toolbox?

Because a template carries no connection and a toolbox does. Share a template at use and each CSM stamps their own toolbox, bound to their own ClickUp account. Share one toolbox at use and every call runs on the connection pinned in its entries, which belongs to the owner, not the grantee.

A template in Elaichi is a tool list with renames, defaults and frozen parameters, and no connection anywhere in it. Build one holding the ClickUp reads a CSM needs, plus task and comment create and update. Share it with the customer success team at use.

When a CSM stamps it, the new toolbox belongs to them. Each entry is filled from connections that person can use, with them recorded as the delegator. An entry with no usable connection sits as "needs connection", exactly what a CSM who has not connected ClickUp yet will see. The fix is to connect ClickUp and re-pin.

The trade-off is real: stamping copies the template once, at that moment. A later edit to the template never reaches a toolbox already stamped. Adding a tool for the team means editing each toolbox individually or asking people to re-stamp. For an 8-person team, that is 8 manual touches per template change, a real maintenance cost, not a hypothetical one. That is the price of per-person connections. For a team handling client data it is usually worth paying, against an alternative of one shared connection and zero per-person isolation.

How does an admin add the endpoint in ChatGPT?

One URL, added once, then each CSM signs in and gets their own OAuth grant. Nobody types a token and nobody gets a personal URL.

As of this writing, full MCP support including write actions in ChatGPT is in beta for Business, Enterprise and Edu plans. On Business, only admins can enable developer mode (source: OpenAI's help center, "Developer mode and MCP apps in ChatGPT"). Check that page directly before rollout, since OpenAI states the feature, UI, and permission model may change. The admin creates the app under Workspace settings, then Apps, then Create, provides the endpoint, clicks Scan Tools, completes the OAuth prompt, and publishes it. It then appears in members' Apps settings labeled "custom."

The endpoint is https://api.elaichi.ai/mcp, typed exactly. With a trailing slash it answers 404 and never starts sign-in.

Each CSM then signs in and lands on Elaichi's consent screen with four checkboxes:

1. Read your organization's data
2. Create and change data
3. Run your connected tools
4. Delete data and remove access

Delete is never pre-ticked, and for this team it should stay unticked. There is no legitimate case for a CSM's ChatGPT session to need delete-and-revoke permission. With "run your connected tools" ticked, a second step asks which toolboxes to expose. Choose "only the ones I pick" and select the stamped ClickUp toolbox, rather than "all my tools". All my tools would expose every toolbox the person has access to, including ones unrelated to this rollout.

One behavior to flag in advance: connected tools are never listed in tools/list, however few there are. The model finds a ClickUp tool with search_tools and runs it with execute_tool. A CSM may open the app list, see no ClickUp tools listed, and file a support ticket. That is normal behavior, not a broken connection. The step-by-step walkthrough is in connecting Elaichi to ChatGPT, and the sign-in failures worth recognizing are listed in fixing OAuth errors.

Who can reach a ClickUp connection once it is in use?

Everyone the connection itself is shared with, plus everyone holding use on a toolbox that pins it. A member sees only what they own or what was explicitly shared with them. No organization-level permission widens that listing, owners and admins included. This is a deliberate design choice. Visibility into a connection and capability to use it are separated, so granting the latter never silently grants the former.

The second clause is the one that surprises people. Pinning a connection into a toolbox and sharing the toolbox hands out the capability without handing out the connection. The grantee runs the entry and cannot open, see, or share the connection underneath it. The call still reaches ClickUp as the owner's account. They just cannot inspect or redirect it.

So for a per-person setup, the rule is short: each CSM leaves their own ClickUp connection unshared. If someone shares theirs with the whole team, every teammate's "all my tools" grant picks it up. That includes connections shared after the grant was originally made, since the resolution happens at call time, not grant time.

Each toolbox entry also records who pinned it, re-checked on every call. Worked example: a CSM pins their ClickUp connection into a shared toolbox, then goes on leave and is suspended via SCIM. From that point, every grantee's call against that entry resolves as unmet until someone currently present re-pins it with their own connection. The toolbox does not silently fail over to another account. Offboarding surfaces these as a non-blocking warning. A private connection pinned by a toolbox its owner shared blocks removal, until an administrator decides what happens to it.

Timing differs by layer. In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change. A role or restriction change takes effect within about two minutes.

What does the audit trail show after a task changes?

Elaichi writes one entry for each connected-tool call that reaches execution (a call refused earlier writes none), naming the ClickUp account actually reached. The recorded connection comes from the execution, not from the intent. So "which workspace did it write to" has a verifiable answer rather than an inferred one.

Concretely: you can prove that a CSM's ChatGPT session updated a specific task on their own ClickUp account. It happened at a specific timestamp, via a specific tool call. You cannot read the comment text out of the audit trail. The log records that a write happened and to what object, not the content written, by design.

A call arriving from ChatGPT is recorded with the surface mcp and the OAuth client named. ChatGPT's client identity is marked verified, because its redirect URIs prove it. The ai_assistant actor kind marks the in-app Elaichi Agent only. Do not expect to find it on ChatGPT-originated rows. The approval line reads "allowed by the access ChatGPT was granted." Over MCP, the grant the person approved during OAuth consent is the human decision being referenced, not a per-call approval.

A restricted tool is never advertised, so the audit signal for "deletes are off" is absence rather than a stream of denied attempts. The evidence is the restriction itself, plus the absence of any delete in the trail. A compliance reviewer can hold the free read-only Auditor seat to check both the restriction and the trail. That is the shape described in proving AI actions in access review evidence.

When is ClickUp's own MCP server enough?

When ClickUp is the only system your team needs inside ChatGPT, and per-user ClickUp permissions are the whole access control you want. In that case, connect ClickUp's server directly and stop here. Adding a control plane buys you nothing in a single-app, single-permission-model setup.

ClickUp hosts a server at https://mcp.clickup.com/mcp, connected via OAuth. ClickUp's developer docs list the supported clients. They name Claude, ChatGPT, Cursor, VS Code, Windsurf and Microsoft Copilot Studio (ClickUp developer docs, "Connect an AI assistant to ClickUp's MCP server", checked October 2026). Per ClickUp's own guide, checked October 2026, it is available on all plans including Free Forever. Calls stay within the account's existing permissions. Personal API keys and access tokens are not accepted as credentials. Without the Everything AI add-on, daily call volume is capped by plan. The cap runs from 100 calls/24h on Free Forever to 5,000 calls/24h on Enterprise (ClickUp blog, "How to use ClickUp's MCP server"). Verify current caps and plan terms directly with ClickUp before relying on these numbers. Usage limits are the kind of detail vendors change without much notice.

Be precise about that last row: removing someone in Elaichi ends their access through Elaichi. Their ClickUp account still exists and still needs to be deprovisioned in ClickUp or through your identity provider. A control plane does not replace offboarding discipline; it adds a layer that also needs clearing.

For the wider picture of what sits between AI clients and company apps, start with what an MCP control plane is. For the same two decisions made in a support queue, read how a support team gets Zendesk without bulk deletes. The apps on offer are listed in the connector catalog, and the team-by-team shapes are on use cases.

FAQ

Can each person use their own ClickUp account when ClickUp is connected to ChatGPT through Elaichi?

Yes. Each person connects ClickUp in Elaichi with their own ClickUp account, and an admin shares a template, a tool list that carries no connection, with the team at use. Each person stamps their own toolbox from that template, and stamping binds every entry to a connection that person can use. A toolbox shared directly is the opposite case: every grantee's call runs on the connection pinned in its entries, which belongs to the owner.

How do you stop ChatGPT from deleting ClickUp tasks?

Write a restriction on the role the team holds that blocks the ClickUp delete tools, such as delete_a_clickup_task_by_id, delete_a_clickup_list_by_id, delete_a_clickup_folder_by_id and delete_a_clickup_space_by_id. In Elaichi a restricted tool is withheld from the tool list and cannot be run. If the assistant searches for it, it sees only the name, flagged as restricted. Restrictions target a role or a user, and a change takes effect within about two minutes.

Why block ClickUp's guest tools for a customer success team?

Adding a guest to a task shares client work outside the company, which is an access decision rather than a project update. Blocking create_a_clickup_guest, clickup_guests_add_to_task, create_a_clickup_user and their update and delete counterparts keeps that decision with whoever administers the ClickUp workspace, instead of putting it one sentence away in a chat window.

Does ClickUp have its own MCP server, and when is it enough?

Yes. ClickUp hosts a server at https://mcp.clickup.com/mcp, connected with OAuth, and its own guide dated 8 September 2026, checked October 2026, says it is available on all plans including Free Forever and that what an AI client does stays within your account's existing permissions. It is enough when ClickUp is the only system your team needs in ChatGPT and per-user ClickUp permissions are the only control you want. A control plane adds one address across apps from different vendors, restrictions written once for a role across those apps, and one audit trail across them.

What does Elaichi's audit trail record for a ClickUp call made from ChatGPT?

Elaichi writes one entry for each connected-tool call that reaches execution (a call refused earlier writes none), naming the ClickUp account actually reached, taken from the execution rather than the intent. The entry holds the operation and tool, the connection, the classification, whether it was approved, the outcome and an error code only. It holds no argument values, with one exception: the one path argument that names the object is recorded as the target id. The entry records the surface as mcp and names the OAuth client, and ChatGPT's name is marked verified because its redirect URIs prove it.

Why QuickBooks read-only cannot come from the OAuth scope

A controller wants the monthly profit and loss inside Claude, and nobody wants an AI client editing an invoice. QuickBooks read-only is not a setting you can turn on in QuickBooks. QuickBooks Online has exactly one accounting OAuth scope, com.intuit.quickbooks.accounting, and it covers reads and writes together. There is no read-only variant. Intuit's own developer documentation on scopes confirms this (developer.intuit.com). Intuit Developer Support's answer to "how do I make my app read-only" is that the app itself should only issue GET requests (help.developer.intuit.com, checked October 2026). The restraint has to sit in whatever calls the API, not in anything Intuit issues at authorization time.

The person who connects does not impose it either. Whoever authorizes the app grants the whole accounting scope to that app, for that company file, full stop. There is no per-user scope narrowing in QuickBooks' OAuth implementation. So a QuickBooks connection carries admin-level read/write reach regardless of who is asking the resulting question through an AI client.

The consent screen does not impose it. On Elaichi's screen, ticking "Run your connected tools" enables a connected app's read and write tools alike. The checkbox does not distinguish by HTTP verb. Only a tool whose underlying method is a delete requires the separate "Delete data and remove access" box, which is never pre-ticked. "Create and change data" governs Elaichi's own control-plane operations (Elaichi's own records, such as connections and toolboxes). It has nothing to do with what the QuickBooks tools themselves can do. Do not tell a finance team that leaving a box unticked made their books read-only; it did not.

What does impose it is a restriction in Elaichi, the governed MCP control plane your clients call. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. A restriction is a rule naming which connectors and which individual tools a role or a person may reach. It is checked at every place a member can reach a connector or tool, including listing, connecting, advertising, executing, the final outbound-request check and opening a stored tool file. This is the only layer in the stack where a read/write distinction can be enforced per person or per role. It sits ahead of QuickBooks, the consent screen and the client.

Register the Intuit app and store it in Elaichi

Open the QuickBooks connector in Elaichi's sidebar under Connectors. If the card titled Add your OAuth application is there, the organization supplies its own Intuit app before anyone connects. That takes connector:manage, held by Org Owner and Org Admin by default.

Create the app in Intuit's Developer Portal, under My Hub then App dashboard. Apps are not created inside QuickBooks itself. Production keys arrive only after Intuit approves an app assessment questionnaire; private, single-company apps need that review too (developer.intuit.com). Budget for that review cycle in your rollout plan rather than discovering it is a blocker on launch day.

In Elaichi, press Add OAuth app. Copy the read-only Redirect URL field with its copy button and paste it into the Intuit app's redirect URIs. Production redirect URIs in Intuit's implementation must be HTTPS, must match the registered string exactly (no trailing slash variance), and cannot carry query parameters (developer.intuit.com). Fill in Client ID and Client secret. Leave Scopes blank to keep the scopes Elaichi requests by default. A typed list replaces them wholesale. For QuickBooks it buys nothing, because the one accounting scope carries writes. Press Save OAuth app; the change lands in the audit trail as connector.oauth_app.updated, attributed to the admin who made it.

Nothing in the Scopes box buys read-only here. QuickBooks has one accounting scope and it carries writes (developer.intuit.com). Token refresh is not the finance team's job either. Elaichi's credential service owns refresh, and a failed refresh marks the connection needs_reauth rather than failing silently.

Connect the books once, then share them with finance

A QuickBooks admin connects the company file once in Elaichi, and that single connection is shared with the finance team at use. A shared connection runs on its owner's credential, so every finance member's call reaches QuickBooks as that admin account from Intuit's point of view. Elaichi still records which member made each call that runs, on its own side. So the audit trail does not collapse into one name, even though QuickBooks only ever sees one.

Use a connection share, not a template, for this shape. A template shared at use gives each person a toolbox bound to their own connection. That is correct when every member holds their own login in the underlying app, as with per-rep Salesforce access in ChatGPT. Finance has one set of books and typically one QuickBooks login. So one connection shared to the team is the correct unit, not one template per person.

Pick an owner who will stay. When an owner leaves, Elaichi's offboarding lists every connection they own. A shared connection the team depends on is deleted only if an admin explicitly asks for that. Otherwise the admin transfers it to another member. A transfer leaves every share exactly as it was. The credential behind the connection is still that person's sign-in to QuickBooks, so the QuickBooks side still needs its own deprovisioning.

Pointing the finance team's clients at the endpoint

Every organization uses the same address: POST https://api.elaichi.ai/mcp. Copy it exactly, with no trailing slash. Each member connects their own client and signs in, so each person holds their own OAuth grant against Elaichi. This is the identity Elaichi uses to attribute calls, independent of the shared QuickBooks credential underneath.

On Claude Team and Enterprise, an Owner adds it under Organization settings, then Connectors, then Add, then Custom, then Web. Members then connect it under Customize, then Connectors (support.claude.com). Note what Claude's per-tool permissions can and cannot do here. Elaichi's connected tools all route through a single Claude-visible tool, execute_tool. So a permission Claude lets you set on "that one tool" actually covers every connected tool across every connector at once. Claude cannot distinguish a QuickBooks report read from a QuickBooks invoice write at its own permission layer. That distinction exists only in Elaichi's restrictions, not in Claude's connector settings. Full walkthrough: connecting Elaichi to Claude.

ChatGPT Business, Enterprise and Edu have the same shape of limit. An admin publishes Elaichi as one custom app. The per-action read/write switches ChatGPT exposes sit on that single app, not on the individual tools or connectors behind it (help.openai.com). The admin-side steps are in the ChatGPT setup walkthrough. In both Claude and ChatGPT, the client's native permission UI is too coarse to do the job. The enforcement has to happen in Elaichi regardless of which client you use.

Write the allow rule that names the read tools

One allow rule on the finance role, naming the QuickBooks read tools the team actually uses, gives you QuickBooks read-only. 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. The rule is the role's whole allowlist, not a QuickBooks filter. Once the finance role holds an allow rule, every connector and every tool that rule does not name is denied for that role. So the same rule must also name every other app the finance team uses. Whole connectors are fine for those. Otherwise the team loses those apps too. Name the reports they ask for (profit and loss, balance sheet), plus read operations over accounts, bills, vendors, invoices and customers. Every create, update and delete tool on the QuickBooks connector falls away without being individually blocked.

Four things to get right:

1. Restriction targets are role or user only. There is no organization target and no team target. Finance needs its own role, and each member holds exactly one role. A finance analyst is a Finance role holder, not also a generic Member with broader reach. Custom roles are a Gold-tier feature; see the pricing page for current plan contents. For how to shape the role itself, see designing roles for AI agents.

2. Do not name the whole QuickBooks connector and some of its tools in the same allow rule. The whole-connector entry wins and grants reach to all of QuickBooks; the tool-level entries in the same rule grant nothing additional. That is a silent over-permission if it saves. In practice Elaichi's API rejects the overlap on new rule creation rather than saving a rule that looks narrow but is not.

3. Allow rules match the operation pinned against the catalog at write time, not the advertised tool name; blocks match either. This asymmetry matters if a connector's tool names change upstream. Full reasoning: why blocks match names and allows do not.

4. A new rule is not instant. A restriction change takes effect within about two minutes. Do not test a new rule one second after saving. If the read tool still looks restricted immediately after you hit save, that is expected, not a bug.

If you would rather block the handful of dangerous writes than allowlist the reads, that trade-off is laid out elsewhere. See restrict one tool or the whole app. For books specifically, the allowlist is the safer default. A new QuickBooks write tool added to the connector later is denied by an allowlist automatically, with no rule edit required. A blocklist has to be updated every time the connector's tool set grows.

Check it from a finance account before telling the team

Sign in from a test account that holds the finance role and search. In Elaichi, connected tools are never listed one by one, however few there are. So the verification method is a search, not a browse. Ask the client for "invoice" and you should see something like get_single_quickbooks_invoice_by_id or list_all_quickbooks_invoices returned. The create and update tools can come back only by name, flagged restricted, with no schema. They cannot be called.

A restricted tool is withheld from the tool list and cannot be called. Search names it, flagged restricted, with no description or schema, so a test account can tell a restricted tool from one that never existed. Reading the rule behind the restriction requires an account holding restriction:view. The built-in Auditor role has it and a default Member does not. The Auditor seat is free and strictly read-only on the control plane itself.

Then run a profit and loss and read the resulting audit entry. Elaichi writes one entry for each connected-tool call that reaches execution (a call refused earlier writes none). The entry also names the surface the call arrived on: Claude through the Elaichi connector, versus the Elaichi web Agent. It names the specific OAuth client it came through too. That is useful when the same person uses both Claude and ChatGPT against the same QuickBooks connection. You need to tell which session asked for what.

When somebody needs a write tool later, they file an access request, which any member can do with no permission required to initiate it. An admin approves it in the console, under Governance, then Access requests. Approval creates an access grant for that one person. The grant lifts exactly the approved tool out of their role rules. Every other role rule keeps applying, nobody else changes, no rule is written and the Finance role is not edited. Those approvals cannot be made from an MCP client or the Elaichi Agent itself. They must go through Elaichi's own admin surface. The separation is deliberate, so a compromised or over-eager AI session cannot self-approve its own elevated access.

Intuit's monthly cap on read calls

Every app sits on Intuit's free Builder tier by default. That tier caps data-out calls at 500,000 per month per app. Calls past the cap return an error rather than being queued or throttled gracefully (developer.intuit.com). Read-only access does not exempt you from this. Every read call your team makes still counts against that single number, shared across the whole company file connection.

AI clients are chatty. One question about a quarter can become several report calls: one per report type, sometimes one per month if the model paginates naively. A model that gets a truncated result may re-ask for the same data, assuming it failed rather than was trimmed. Elaichi caps a result at 32,000 characters per string and 200 items per array, and sets elaichi_truncated: true on the response when it cuts data. That is a signal your client should use to request a narrower query, not retry the same one. Elaichi also rate-limits a single token to 120 MCP requests per minute independent of Intuit's monthly cap. Narrow allow rules help on both counts: a tool nobody can call is a call nobody makes, which directly reduces pressure on Intuit's 500,000-a-month ceiling.

When Intuit's own QuickBooks options fit better

Sometimes the honest answer is that you do not need a control plane.

Intuit hosts a QuickBooks connector for Claude (announced April 2026). Intuit's own help documentation states it is for US customers, and that destructive actions require the user's explicit confirmation at the moment of the call. Its tool listing covers both reads and writes across invoices, estimates, customers and reports (quickbooks.intuit.com). You may be a US business where one or two people use it. If you actively want Claude to draft invoices rather than just read reports, that is the faster path to set up. A confirmation prompt asks the person in the moment and depends on them reading it. A restriction removes the capability before the question is ever asked. These are different security properties, not different strengths of the same one.

Intuit also publishes intuit/quickbooks-online-mcp-server, an open-source MCP server you run yourself. OAuth credentials go in environment variables, and three boolean switches (QUICKBOOKS_DISABLE_WRITE, QUICKBOOKS_DISABLE_UPDATE, QUICKBOOKS_DISABLE_DELETE) leave only read operations reachable (github.com). That is genuinely read-only, enforced at the server, for one analyst on one machine. The constraint is that it is per-machine and per-process. Five analysts means five installs, five copies of the client secret, and five sets of environment variables. All of them have to be kept in sync if a scope or credential changes. There is no shared audit trail across those five instances unless you build one.

Elaichi earns its place when the team is more than one or two people, and QuickBooks is one of several systems they ask about, not the only one. It earns it when someone has to be able to show an auditor who read what, when, from which client. Elaichi keeps one audit trail across every client and every connected app. The same connection-share-plus-allowlist shape applies to the rest of the finance stack. See Xero in Claude, without letting it edit invoices for the same pattern on a different ledger. For the control-plane concept itself, read what an MCP control plane is, and browse the 600+ connectors for the other apps finance already runs.

FAQ

Does QuickBooks Online have a read-only API scope?

No. QuickBooks Online has one accounting scope, com.intuit.quickbooks.accounting, and it covers reads and writes together. Intuit Developer Support's guidance for a read-only app is that it should make only GET requests (developer.intuit.com, checked October 2026). Read-only access therefore has to be enforced by whatever calls the API, such as a restriction in an MCP control plane, rather than by the scope itself.

Can I make QuickBooks read-only by unticking a box on Elaichi's consent screen?

No. On Elaichi's consent screen, "Run your connected tools" runs a connected app's read and write tools alike, and "Create and change data" governs Elaichi's own control-plane operations rather than the connected app's. Only a tool whose method is a delete needs the separate "Delete data and remove access" box. Read-only access to a connected app is written as a restriction: an allow rule naming its read tools, or blocks on its writes.

Who can connect QuickBooks for a finance team?

Intuit's UK help says the primary admin and company admins connect apps, and no US page was found stating otherwise, so a QuickBooks connection usually carries admin reach. In Elaichi that admin connects the company file once and shares the connection with the finance team at use. A shared connection runs on its owner's credential, so every member's call reaches QuickBooks as that admin account, while Elaichi records which member made each call that runs.

How quickly does a new restriction take effect?

A new restriction is not instant. A restriction change takes effect within about two minutes. In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change.

How do I confirm that a QuickBooks write tool is actually restricted?

Sign in from a test account holding the restricted role and search for the tool by name. Connected tools are never listed, so the model finds them through search_tools and runs them through execute_tool. A tool withheld by a restriction cannot be run. Search names it, flagged restricted, with no schema. Reading the rule behind it takes someone holding restriction:view, such as an admin or the free read-only Auditor.

Who can authorize a Ramp app, and what the finance team inherits

Finance wants Ramp in Claude: what did we spend with this vendor last quarter, which bills are still unapproved, who has not attached a receipt. The blocker arrives before the first question. Ramp's own pages name who can authorize a developer app. Only users with Developer API authorization permission can do it, typically Admin and Business Owner (https://docs.ramp.com/developer-api/v1/authorization, https://support.ramp.com/accessing-the-developer-api, checked October 2026). You are not handing five analysts an admin seat to get a spend question answered.

So one admin authorizes, and the team shares what that authorization produced. In Elaichi, a governed MCP control plane, one Ramp admin connects the Ramp account once. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. The connection is then shared with the finance team at use. That is the grant that lets a person call something they do not own. It is distinct from edit, the share level that lets them change the connection. A shared connection runs on its owner's credential, so every call reaches Ramp as that admin account. The analysts never see or hold the secret, and they gain no new role inside Ramp.

What actually bounds a shared call is three layers, each narrower than the last, and none able to widen what the layer before it allows:

1. The admin's Ramp role: whatever Admin or Business Owner can see in Ramp, which Ramp sets and Elaichi cannot override.
2. The OAuth app's scopes: the read/write list configured in Ramp's developer app, which bounds the credential itself.
3. Elaichi's restrictions: the allow/block rules on the finance role, which bound which people can reach which tools.

Ramp does not document that an OAuth app's calls are narrowed to the authorizing person's role. In practice, treat the connection as carrying the admin's full reach unless scopes and restrictions say otherwise, and put the boundary where you control it. In Elaichi that is layers 2 and 3: the scope list on the OAuth app, and restrictions on the finance role.

Setting up Ramp in Claude: does the connector want your own OAuth app?

Only if the connector's page shows the card. Most OAuth connectors in Elaichi connect through an operator-set default OAuth app that every organization inherits. Where a connector needs the organization's own app instead, its page carries a card titled Add your OAuth application. An admin holding connector:manage fills it in. Org Owner and Org Admin hold that permission by default. If the card is not there, skip this section and connect the account directly.

When the card is there, the order matters:

1. In Elaichi, open Connectors in the sidebar, open the Ramp connector, and press Add OAuth app. The Redirect URL field is read-only and has a copy button. Copy it now.
2. In Ramp, create a developer app. Ramp's pages give more than one menu path, so follow Ramp's current one (https://support.ramp.com/accessing-the-developer-api, checked October 2026). Paste Elaichi's Redirect URL wherever Ramp asks for a redirect URI. Ramp requires HTTPS and an exact match, so do not retype it.
3. Configure the app's scopes in Ramp. Start read-only, which is also Ramp's own advice (https://docs.ramp.com/developer-api/v1/authorization, checked October 2026).
4. Back in Elaichi, paste the Client ID and Client secret, type the scope list, and press Save OAuth app. The change is recorded as connector.oauth_app.updated.

Then the Ramp Admin or Business Owner connects the account in Elaichi. That person owns the connection. Pick an owner who is staying. When an owner leaves, Elaichi's offboarding lists every connection they own. A shared connection the team depends on is deleted only if an admin asks for that. Otherwise the admin transfers it to another member, which keeps every share as it was. The Ramp side still needs its own deprovisioning.

Which Ramp read scopes to type, and why the box replaces the defaults

Type only the read scopes the team's questions need, and type the complete list. Elaichi's Scopes box is wholesale: left blank it keeps the scopes Elaichi requests by default, and a typed list replaces those defaults entirely. One scope per line, written exactly as Ramp writes it.

One caution follows from that. The console never shows the scopes Elaichi requests by default. So a typed list has to be complete. Include any non-resource scopes Ramp lists, such as offline_access if the app relies on refresh tokens. After saving, check that the connection still works once its first access token has expired.

Ramp's scopes come in resource:read and resource:write pairs, with no wildcard, and a token holds only the scopes it was issued with. For finance's read-only questions, the scope set generally looks like this. Confirm the exact names against Ramp's current authorization page before typing them:

Per Ramp, asking for a scope the app is not configured for fails at sign-in with invalid_scope (https://docs.ramp.com/developer-api/v1/authorization, checked October 2026). A call that needs a scope the token lacks gets a 403 from Ramp. Elaichi records that as a failed tool call with an error code. Nothing escalates to a broader scope automatically. The fix is always the same sequence: add the scope in Ramp, add it to Elaichi's list, reconnect. Copy the exact names from Ramp's authorization page rather than guessing from a pattern.

This is the hard edge of the whole setup. A write scope you never type cannot be talked back into existence by a prompt, a misreading, or a clever tool call. Adding approvals or reimbursement submission later is a deliberate act: a new scope in Ramp, the same scope added to Elaichi's list, and a reconnect.

Which Ramp tools stay out of the finance role

Write one allow rule on the finance role naming Ramp's read tools. One consequence catches people out. Once the role holds an allow rule, every connector that no allow rule on the role names is denied for that role. That is not just Ramp's other tools. Allow rules on the same role add up. So give the finance role an allow rule for each other app it uses, naming a whole connector where that is fine. Otherwise the team loses those apps. The mental model is simple: scopes bound the credential, restrictions bound the people. Scopes are set once in Ramp and apply to everyone who shares the connection. Restrictions are set in Elaichi, target a role or a user, and can change without touching Ramp at all. A restriction change takes effect within about two minutes. In Elaichi, restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything.

Two traps decide whether the rule does what you meant:

• An allow rule that names nothing denies everything. 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. Leaving the tool list blank locks out the whole finance team.
• An allow rule that names the Ramp connector as a whole and some of its tools reaches all of Ramp. The tool entries grant nothing once the connector-level entry is present. Name the tools, or name the connector, not both.

Blocks always beat allows. A restricted tool is withheld from the tool list and cannot be called. Search names it, flagged restricted, with no schema. So an analyst who asks Claude to approve a transaction finds an approve tool that cannot run.

One correction catches people out at the consent screen: unticking Create and change data does not make Ramp read-only. That checkbox governs Elaichi's own operations. For a connected app, Run your connected tools runs reads and writes alike, and only a delete costs the destructive scope. Read-only access to Ramp is the scope list plus a restriction, never a consent checkbox. The matching rules are worth reading once in how blocks and allows resolve differently. The wider pattern is in least privilege without breaking the work.

Adding the one endpoint in Claude, and what the trail shows afterward

There is one address for the whole organization: POST https://api.elaichi.ai/mcp. No per-user URL, no token to paste. On Claude Team and Enterprise, an Owner or Primary Owner adds it under Organization settings, then Connectors, Add, Custom, Web. Members then enable it under Customize, Connectors and sign in with their own grant. On Pro and Max it is Customize, Connectors, "+", Add custom connector (https://support.claude.com/en/articles/11175166, checked October 2026).

Each analyst signs in once, picks the organization, and leaves Run your connected tools ticked. Delete is never pre-ticked. Claude's per-connector tool permissions land on Elaichi's execute_tool, a single permission that gates every connected tool at once, regardless of which app it belongs to. That is exactly why the per-tool boundary for Ramp has to live in Elaichi's restrictions and not in Claude's own settings. Claude's settings cannot distinguish a Ramp read from a Ramp write. The two places an admin approves apps are compared in approving apps for Claude across a company.

Afterward, Elaichi writes one entry for each connected-tool call that reaches execution (a call refused earlier writes none). The audit trail is the append-only record of what ran. It names the Ramp account actually reached, the operation and tool, whether approval was needed, the outcome, and an error code. The entry holds no argument values, with one exception: the one path argument that names the object is recorded as the target id. So a transaction amount does not end up in the log. The entry carries the surface (mcp) and the client, and Claude's name is marked verified by its redirect URIs. A call from Claude is recorded with the person as the actor, not as an assistant. An Auditor seat to read it is free. What belongs in an agent's audit record goes into the fields themselves.

When Ramp's own hosted MCP server is the better fit

When each person only needs their own Ramp data. Ramp hosts its own MCP server at https://mcp.ramp.com/mcp, labeled "Ramp MCP is in Beta" in Ramp's docs, with OAuth sign-in. Employees see only their own data, and admin tools require Admin or Business Owner. Admins grant access at Company, Integrations, Ramp MCP, Manage Access (https://docs.ramp.com/developer-api/v1/ramp-mcp, https://support.ramp.com/ramp-mcp, checked October 2026). Custom clients and gateways need their redirect URI allowlisted by Ramp first.

The two paths solve different problems, not the same problem with different branding:

If the question is personal, "where are my own receipts," "what did I spend," Ramp's server is the better fit. There is no second vendor in the path. Elaichi is the better fit when the question is operational and shared. Use it when no single analyst's Ramp role covers the question. Use it when Ramp needs to sit beside Xero, Slack, or Salesforce on one address with restrictions written once per role. Use it when one audit trail has to cover every app a finance analyst touches in Claude.

For the wider shape of this, read what an MCP control plane is and who needs one. The same playbook for a different ledger is in keeping Claude out of your Xero invoices. The choice between a whole-app and a single-tool rule is worked through in six cases for per-tool restrictions. The Ramp connector sits with the rest of the catalog under connectors.

FAQ

Can a finance analyst use Ramp in Claude without a Ramp admin seat?

Yes. Ramp documents that only users with Developer API authorization permission, typically Admin and Business Owner, can authorize a developer app (docs.ramp.com/developer-api/v1/authorization, checked October 2026). In Elaichi, that admin connects the Ramp account once and shares the connection with the finance team at use level. A shared connection runs on its owner's credential, so analysts call Ramp without holding a Ramp admin seat, and without ever seeing the credential.

How do you make a Ramp connection read-only for a team?

In two layers. First, configure only read scopes on the Ramp developer app, since Ramp scopes come in resource:read and resource:write pairs with no wildcard, and type that same complete list into Elaichi's Scopes box, because a typed list replaces Elaichi's defaults wholesale. Second, write a restriction on the finance role allowing only Ramp's read tools. Unticking "Create and change data" on Elaichi's consent screen does not do this: for a connected app, "Run your connected tools" runs reads and writes alike.

How long does a Ramp restriction change take to apply in Elaichi?

A role or restriction change takes effect within about two minutes. Role membership and restriction changes resolve through a short cache plus edge propagation on every surface, MCP clients and the console alike. Some changes are faster: revoking a share and disconnecting an account take effect on the caller's next request, because the grant and the connection are read fresh on every call. In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change.

Should a company use Ramp's own hosted MCP server instead?

Use Ramp's hosted server when each employee only needs their own data. It sits at https://mcp.ramp.com/mcp, is labeled a beta in Ramp's docs, signs in with OAuth, and scopes each person to their own Ramp role, with admin tools requiring Admin or Business Owner (docs.ramp.com/developer-api/v1/ramp-mcp, checked October 2026). A control plane such as Elaichi is the better fit when a team shares one admin-authorized view, when Ramp is one of several apps behind one address, or when one audit trail has to span all of them.

Who can add the organization's own OAuth app to a connector in Elaichi?

An admin holding the connector:manage permission, which Org Owner and Org Admin hold by default. The card is called "Add your OAuth application" on the connector's page, and it appears only where the connector needs the organization's own app or one is already stored. The Redirect URL field is read-only with a copy button; paste it wherever the provider asks for a redirect URI. Changes are recorded in the audit trail as connector.oauth_app.updated.

Why no admin console lists the MCP servers employees have installed

Most of the MCP servers employees have installed are lines in a file on a laptop, and no client vendor documents an admin inventory of those files. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. A server is either a local process the client starts on the device, or a remote HTTPS address the client calls (modelcontextprotocol.io, checked October 2026). Both are recorded the same way, as an entry in the client's own configuration file.

That is why network tooling finds so little. A local server never leaves the machine, so there is no request for a proxy to inspect. A remote one is an ordinary HTTPS call. For Claude's connectors, that call comes from Anthropic's cloud rather than the user's device, on every Claude client (claude.com/docs/connectors/custom/add-unlisted, checked October 2026). Inline inspection still earns its place for other reasons. It is not how you build this list.

Vendor consoles report what connects through the vendor's own surface, which is a different set from what sits in a file. So the order is: read the files, then read the logs, then ask the people.

A note on sourcing: every claim below traces to a vendor's own documentation, linked and dated. "Checked [month, year]" marks when we last reconciled the claim against that page, not a publication date. Vendor docs change without notice, and the config path below moved when Windsurf became Devin Desktop. Re-verify against the live link before you build unattended automation on a specific path or key.

Which file holds the server list on each client?

Each client keeps its MCP servers at a documented path, and usually there are two, one per user and one per project. These are the paths as of October 2026, read from each vendor's own page. This list covers the clients most likely to appear in a laptop fleet today: Claude Desktop, Claude Code, Cursor, VS Code with Copilot, Devin Desktop and Codex. JetBrains AI Assistant, Zed, and mobile or browser-based MCP clients aren't covered here; if your fleet includes them, find the equivalent path in that vendor's own docs before treating a sweep as complete.

• Claude Desktop. ~/Library/Application Support/Claude/claude_desktop_config.json on macOS, %APPDATA%\Claude\claude_desktop_config.json on Windows, with servers under the mcpServers key. Anthropic gives no Linux path. Server names also appear in the log directory, ~/Library/Logs/Claude or %APPDATA%\Claude\logs, as one mcp-server-SERVERNAME.log per server (modelcontextprotocol.io, checked October 2026).
• Claude Code. Local and user scope live in ~/.claude.json. Project scope lives in .mcp.json at the repository root. On a device you can also run claude mcp list (code.claude.com/docs/en/mcp, checked October 2026).
• Cursor. ~/.cursor/mcp.json globally and .cursor/mcp.json per project (cursor.com/docs/mcp, checked October 2026).
• VS Code with GitHub Copilot. .vscode/mcp.json with a top-level servers key, plus a user-profile mcp.json. Both are now labeled deprecated in the Add Server flow, which steers new servers to .mcp.json at the project root and ~/.copilot/mcp-config.json. Sweep both generations (code.visualstudio.com, checked October 2026).
• Devin Desktop, which was Windsurf. ~/.config/devin/mcp_config.json, or %APPDATA%\devin\mcp_config.json on Windows. Devin's docs still name the older ~/.codeium/windsurf/mcp_config.json, so check both (docs.devin.ai, checked October 2026).
• Codex. ~/.codex/config.toml, one [mcp_servers.<name>] table per server, plus a project .codex/config.toml in trusted projects only. One file covers the ChatGPT desktop app, the Codex CLI and the IDE extension (learn.chatgpt.com, checked October 2026).

Desktop extensions in Claude are local servers too, installed from Settings and then Extensions. No vendor page gives their path on disk, so the allowlist is the control for them, not a file sweep.

Quick reference: paths, policy and log coverage by client

How to collect only the server entries

Parse each file and emit the server objects alone. Never ship the whole file to your inventory.

The reason is concrete. ~/.claude.json holds the Claude Code sign-in session alongside its mcpServers object, so a script that uploads the file uploads a credential. Read the mcpServers object out and discard the rest. Do the same for servers in VS Code's files and the [mcp_servers.*] tables in Codex's TOML. Use a real JSON or TOML parser rather than a regular expression, and when a file will not parse, log the path and move on.

Per entry, record five fields: the device, the user, the client, the server name, and either its url or its command with arguments. For an env block, record the key names and not the values. Those values are often long-lived API tokens, and a sweep that copies them creates a second place they live.

Project files are the part most sweeps miss. .mcp.json, .cursor/mcp.json, .vscode/mcp.json and .codex/config.toml sit inside repository checkouts, not in the home directory, so the script needs a path glob across developer working directories. Run the whole sweep twice, a week apart. The delta tells you whether the list is growing, which matters more than the first snapshot.

Which admin logs show an MCP connection?

Three exist today, and each covers connections made through the vendor's surface rather than files on disk.

Anthropic's Compliance API, on Enterprise, emits integration_user_connected and integration_user_disconnected with integration_type set to mcp, carrying the server's id and name. It also carries admin events such as mcp_server_created and mcp_tool_policy_updated. The Primary Owner enables it and there is no backfill, so turn it on before you need the history (platform.claude.com, checked October 2026). It covers connectors on the claude.ai side, not local config files.

Claude Code can emit claude_code.mcp_server_connection over OpenTelemetry, with server names present only when OTEL_LOG_TOOL_DETAILS=1 (code.claude.com, checked October 2026). Cursor's Enterprise audit log carries mcp_server_config and mcp_authentication events (cursor.com/docs/enterprise/compliance-and-monitoring, checked October 2026). Cursor does not say that an edit to a member's own mcp.json emits either, so treat it as coverage of connections rather than of files. Cursor also documents MDM-deployed hooks, where beforeMCPExecution sees the server name and its URL or command on every call and can allow, deny or ask (cursor.com/docs/hooks, checked October 2026). GitHub's usage metrics report MCP use for Copilot CLI only (docs.github.com, checked October 2026). OpenAI and Devin document nothing comparable, so the file sweep is the whole answer for Codex and Devin Desktop.

What to ask people directly

Send a short message to the teams most likely to have built something, and make it a question about their work rather than a compliance notice. Scripts miss anything written outside a standard directory. An engineer who wrote a local server to read a staging database will say so if nothing bad happens when they do.

Four questions is enough. Which MCP servers do you have configured, in any client. Which of them reach a company system, as opposed to local files. Which did you write yourself. Which would break your week if it stopped working on Friday.

That last question sorts the list. It separates a tool somebody tried once from a tool that is now part of a process, and the second kind has to be replaced rather than removed. State up front that the goal is to keep the useful ones working. An audit that reads as punishment pushes the next one further out of sight.

Keep, replace, remove: sorting the inventory

Sort every entry into one of three buckets, and resist inventing a fourth.

Keep is a local server that touches nothing but the developer's own machine and holds no company credential. A filesystem reader over a local checkout is the usual case. Record it, scope it so it cannot reach a production environment, and move on.

Replace is any server that reaches a company SaaS account: the Jira server with a personal API token in an env block, the Slack server somebody pasted a bot token into, the internal API wrapper running on one laptop. These are the entries a leaver takes with them, and they sit outside whatever sign-in rules govern everything else on the device, which is the practical case for OAuth rather than API keys.

The replace pattern has the same shape regardless of vendor: one shared endpoint behind OAuth, so no server URL or token lives in a per-user config file; a catalog of maintained connectors, so engineering time isn't spent patching a Jira or Slack MCP server; and a restriction layer, a rule naming which connectors and which individual tools a role or person may reach, enforced at every place a member can reach a connector or tool, including listing, connecting, advertising, executing, the final outbound-request check and opening a stored tool file, not only at connect.

Disclosure: Elaichi, which publishes this post, is one implementation of that pattern. It serves 600+ connectors through a single organization-wide endpoint, POST https://api.elaichi.ai/mcp, behind OAuth, with no per-user URLs and no embedded tokens. A restriction change takes effect within about two minutes. Elaichi writes one entry for each connected-tool call that reaches execution (a call refused earlier writes none). If you're evaluating this category rather than this vendor, four questions apply to any product in it: single endpoint or per-user URLs, who authors and maintains the catalog, where restrictions are enforced (connect only, or also at execute), and how fast a change propagates.

Remove is everything with no owner, plus anything built on a shared long-lived token. Deleting the config entry is not the whole job. Rotate the credential it held, because the entry was only one copy of it.

Write the limit down next to the list. A governed endpoint controls access through itself and nothing upstream of it. It does not govern calls a client makes to a server directly. GitHub's own MCP server, for instance, stays governed by GitHub's policy and your identity provider, regardless of catalog. Removing access through the gateway also ends there: the person's account inside each downstream app still exists and is deprovisioned through that app or your identity provider, which is the harder half of offboarding when an agent holds access.

Which managed policy keeps the list from growing again

Each client ships its own, and each binds only that client. Set them after the sweep, so you know in advance what the policy will break.

Claude Desktop reads device policy from the macOS domain com.anthropic.claudefordesktop and from HKLM:\SOFTWARE\Policies\Claude on Windows, where isLocalDevMcpEnabled, isDesktopExtensionEnabled and isDesktopExtensionDirectoryEnabled all default to true. The Desktop extension allowlist in Organization settings is off by default, and turning it on removes existing installs (support.claude.com, checked October 2026). Claude Code uses allowedMcpServers and deniedMcpServers in managed settings, where the denylist always wins and an unset allowlist allows everything. Anthropic states that matching by serverName is not a security control; the reason is that users choose the names, since the name is the key a person types in their own config. Match on serverUrl or serverCommand instead (code.claude.com, checked October 2026). A newly blocked server disappears from /mcp with no reason shown, so tell people before you apply it.

VS Code has chat.mcp.access, set to all, registry or none, plus per-server allow and deny lists where deny beats allow (code.visualstudio.com, checked October 2026). Cursor's allowlist is Enterprise only and does not push servers to anyone (cursor.com/docs/enterprise/model-and-integration-management, checked October 2026). Devin Desktop lets a team admin turn MCP off or allowlist servers, and once any server is allowlisted every other server is blocked for the team (docs.devin.ai, checked October 2026). Codex reads an approved mcp_servers list from requirements.toml, where a key that is present but empty disables every MCP server (learn.chatgpt.com, checked October 2026).

When the inventory is the whole job

If the sweep returns four local servers on two laptops and none of them holds a company credential, you are done. Set the client policies, keep the script on a monthly schedule, and spend the budget elsewhere. A governed endpoint earns its place when people are reaching company SaaS accounts from an assistant, not when two developers are reading local files.

The decision changes when the same list shows a personal token in a config file, or a server nobody can name the owner of, or one app connected from three different clients. At that point the work is consolidation, and the case for waiting no longer holds.

For the replacement step in detail, see how to swap personal servers on laptops for one endpoint. For what the browser-side evidence does and does not prove, read the shadow AI browser extension log, and for the layer above it, what CASB and DLP can see. The architecture behind the single address is covered in the MCP control plane explainer. Check which servers on your list have a maintained equivalent in the connector catalog.

FAQ

Where does each AI client store its MCP server list?

As of October 2026: Claude Desktop uses ~/Library/Application Support/Claude/claude_desktop_config.json on macOS and %APPDATA%\Claude\claude_desktop_config.json on Windows, under the mcpServers key. Claude Code uses ~/.claude.json for local and user scope and .mcp.json at a repository root for project scope. Cursor uses ~/.cursor/mcp.json and .cursor/mcp.json. VS Code with Copilot uses .vscode/mcp.json and a user-profile mcp.json, both now deprecated in favor of .mcp.json at the project root and ~/.copilot/mcp-config.json. Devin Desktop, formerly Windsurf, uses ~/.config/devin/mcp_config.json or %APPDATA%\devin\mcp_config.json, with the older ~/.codeium/windsurf/mcp_config.json still named in its docs. Codex uses ~/.codex/config.toml with one [mcp_servers.] table per server.

Can an admin console show which MCP servers employees added on their own laptops?

No client vendor documents an admin inventory of the servers in members' local configuration files. Admin consoles report servers that connect, or are used, through the vendor's own surface. Anthropic's Compliance API emits integration_user_connected events with integration_type mcp, Claude Code can emit claude_code.mcp_server_connection over OpenTelemetry, and Cursor's Enterprise audit log carries mcp_server_config and mcp_authentication events. Finding local servers means reading the configuration files on each device with an MDM or EDR script.

Is it safe for an inventory script to upload the whole config file?

No. Parse the file and collect only the server entries. Claude Code's ~/.claude.json holds the sign-in session alongside its mcpServers object, so uploading the whole file uploads a credential. For an env block inside a server entry, record the key names and not the values, since those values are often long-lived API tokens.

Does removing an MCP server revoke the person's access to the third-party app?

No. Removing a server or a connector ends access through the AI client and nothing more. The person's account inside each app still exists, and it is deprovisioned in that app or through your identity provider. Rotate any credential the server config held, because deleting the entry does not invalidate the token it contained.

What should replace an MCP server that holds a personal API token?

A governed endpoint where the credential is not in the client at all. Elaichi serves every connected SaaS account through one organization-wide MCP endpoint at https://api.elaichi.ai/mcp, behind OAuth, with no per-user URL and no token to paste into a config file. Each member connects once and signs in with their own grant, and revoking that grant, removing the member or suspending them takes effect on the next call.

How do you keep BambooHR salary data out of an AI assistant?

HR wants Claude to answer the routine questions: who reports to whom, who is on leave next week, when a new hire starts. Someone in finance points out that the same connection could read pay bands and payroll deductions. Both positions are reasonable, and the argument stalls there.

Keeping BambooHR salary data out of the assistant takes two layers, and neither one alone is enough:

The order matters. Build layer one first, because it holds even if someone later misconfigures layer two. A bad allow rule can only expose tools the API key is itself permitted to run. It can never expose a field BambooHR already hides from that key.

MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. Elaichi is a governed MCP control plane. Every company account is connected once and served through one organization-wide endpoint. Restrictions are enforced per role before any tool reaches the model.

Layer one: which BambooHR user does the API key act as?

An API key in BambooHR carries its creator's reach. BambooHR's own documentation puts it plainly: "The API can only view or update data that the user can access" (BambooHR help, checked October 2026). The question is not what the key is allowed to do. It is who made it.

Two details decide whether compensation leaks:

1. Pay data lives in the compensation table and in the payRate, payType and paidPer fields (BambooHR table and field names, checked October 2026).
2. Get Employee drops fields the caller cannot view while returning no error (BambooHR Get Employee, checked October 2026). A model asking for an employee record gets a shorter record and no sign that anything was withheld.

That silent drop is the behavior you want. It is also the behavior that makes testing necessary. A 200 response with a short record looks identical to success whether or not compensation was ever in scope. Steps to verify:

1. In BambooHR, confirm the access level that will own the API key does not have compensation visibility, and that its field settings reflect that.
2. Create the API key from a user account at that access level.
3. Call Get Employee for a salaried employee whose pay rate you already know.
4. Read the response. If payRate comes back, the key belongs to the wrong user. Fix the access level, not the restriction.

BambooHR's OAuth scopes separate employee from employee:compensation and sensitive_employee:protected_info, which covers SSN, SIN and birthday (BambooHR Get Employee, checked October 2026). Elaichi's connector takes an API key rather than an OAuth app. So the access level behind that key, not an OAuth scope, is the control you have at this layer.

Layer two: what does an allow rule for an HR reader name?

An allow rule on the role, naming the specific read tools that role uses, and nothing else. Elaichi's bamboohr connector carries 406 tools: 182 have names starting with list_ or get_, and most of the other 224 create, update, delete or bulk-change records. The full, current list is on the BambooHR connector page, rather than reproduced here, since tool counts change as BambooHR's API surface grows.

The pay-related tools are easy to spot and easy to miss one of:

A block list that names those four leaves every one of the other 402 tools reachable. With 406 tools, that is not a boundary. It is a guess. Intune runs the same arithmetic: 198 tools, 69 of them reads, and six blocks do not hold a role to reading.

So write an allow rule instead of a block rule. Two properties of Elaichi restrictions shape how it has to look:

• A restriction targets a role or a single user. In Elaichi, restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything.
• An allow rule is the target's whole allowlist across every connector, not just the app it mentions. Once the HR role holds one allow rule, every connector its allow rules do not name is denied. Add an allow rule naming each of the role's other apps whole, or HR loses Slack and Google Calendar once the BambooHR rule takes effect.

Two traps to know before writing the rule:

1. An allow rule that names the bamboohr connector whole and also lists some of its tools reaches all of it. The tool entries grant nothing additional once the connector itself is named.
2. An allow rule naming nothing at all denies everything. This is the strictest thing the system can express.

Allow rules match the operation pinned against the catalog at write time. Blocks match the tool name or the operation. The mechanical difference is covered in why blocks match names and allows do not. A restriction change takes effect within about two minutes, on every surface. Custom roles are a Gold-plan feature, so a dedicated HR reader role requires that plan.

The role layer is not optional, because a shared connection runs on its owner's credential. Share the BambooHR connection with the HR team at use, and every grantee's call reaches BambooHR as the account behind that key. Those grantees never see the key itself: reading an account's configuration back returns the list of dot-paths that were encrypted, and none of their values. The restriction is what makes one shared connection serve different people differently. The per-tool or per-app decision runs through the same reasoning for other apps.

Checklist for locking down an HR reader role:

1. API key created from a BambooHR access level without compensation visibility (layer one, verified by test call)
2. Custom role created in Elaichi for HR readers
3. Allow rule naming only list_*/get_* BambooHR tools the role actually needs (not all 182)
4. Pay-related tools (table above) confirmed absent from the allow list
5. Allow rules added for the role's other connectors (Slack, Google Calendar, etc.), named whole, so they aren't silently denied
6. Connection shared with the HR team at use
7. Test call made as a role member to confirm pay tools are unreachable and routine tools work

What a withheld BambooHR tool looks like to the model

A restricted tool is withheld from the tool list and cannot be called. Search names it, flagged restricted, with no description or schema. The model has no schema to fill in and nothing it can run.

Connected tools are never listed in tools/list, however few there are. The model finds one with search_tools and runs it with execute_tool, and those two are the only way in. A BambooHR tool missing from a list is therefore usually a permission gap rather than a bug. MCP tools not showing up walks the diagnostic ladder in order.

One consequence of that shape: search_tools is annotated read-only, while execute_tool is annotated destructive and open-world, because it runs whatever connected tool it is handed. A client that prompts on anything not marked read-only will prompt on every BambooHR call, reads included. This is a client-side UX behavior, not something the restriction layer controls.

Should you use BambooHR's own MCP server instead?

If BambooHR is the only app you need in the assistant, yes. BambooHR runs an official MCP server, in beta, at {subdomain}.bamboohr.com/api/mcp, and it powers BambooHR's own Claude and ChatGPT connectors. An admin gate decides who may use it. BambooHR says it enforces BambooHR's existing permissions, omitting restricted fields without warning (BambooHR MCP server docs, checked October 2026). Ask BambooHR answers from data the user can access, and HR can read the chats (BambooHR help, checked October 2026).

Per-person permissions, enforced by the system that owns the data, with no second vendor in the path. That is a genuinely good answer for a single app, and the silent field omission matches the API behavior either way.

What BambooHR's own pages do not claim is the part that decides the rest of the question:

• One address covering apps from different vendors (BambooHR, Jira, Zendesk, a payroll provider) rather than one MCP server per app.
• Restrictions written once for a role, applying across all of those apps rather than configured separately in each vendor's admin panel.
• One audit trail spanning them, instead of one log per vendor.
• Ending a person's access to all of them in one action.

If HR also needs Jira, Zendesk and a payroll provider in the same assistant, those four gaps are the reason to put a control plane in front. If it does not, adding one is unnecessary overhead. Removal in Elaichi ends access through Elaichi and nothing more; the person's BambooHR account still exists and must be deprovisioned on BambooHR's side separately.

Decision rule: for a single-app HR assistant, BambooHR's own MCP server. For an assistant spanning HR, support and project tools under one role model, a control plane in front of all of them.

Adding one endpoint in Claude or ChatGPT

Every connected account is served through one organization-wide endpoint: POST https://api.elaichi.ai/mcp. There are no per-user URLs and no embedded tokens. An admin adds the address once where the client allows it. Each member then signs in with their own OAuth grant. OAuth is the browser sign-in that issues a client its access, with no key to paste.

In Claude Team and Enterprise, an Owner or Primary Owner adds it under Organization settings, Connectors, Add, Custom, Web. Members then connect it under Customize, Connectors (Anthropic support, checked October 2026). In ChatGPT, custom MCP apps with write actions are in beta on Business, Enterprise and Edu. Only Admins and Owners publish one (OpenAI help, checked October 2026). OpenAI now manages apps under Plugins in the Admin Console, so follow the current path in the ChatGPT guide below. Step-by-step versions are in connecting Elaichi to Claude and connecting Elaichi to ChatGPT.

On the consent screen, every scope the client asked for is pre-ticked except delete, which is never pre-ticked. With "Run your connected tools" ticked, a second step offers All my tools or Only the ones I pick. Read one line carefully here: for a connected app's tools, "Run your connected tools" covers reads and writes alike. Leaving "Create and change data" unticked does not make BambooHR read-only, because that checkbox governs Elaichi's own operations, not the connector's. Read-only BambooHR access is a restriction (layer two above), not a consent-screen setting. A finance team reaches the same conclusion in QuickBooks read-only for a finance team.

What the audit trail records for a BambooHR call

Elaichi writes one entry for each connected-tool call that reaches execution (a call refused earlier writes none), naming the account actually reached. Each entry records the operation and tool, the connection, the classification, whether it was approved, the outcome, and an error code. The entry holds no argument values, with one exception: the one path argument that names the object is recorded as the target id.

For HR data that default is the right one, and it is also a limit. The log proves that a given member ran an employee lookup through Claude at a given time. It records the object-naming path argument as the target id and nothing else about the arguments, so the fields requested and the values returned are not in the log. An investigation that needs that detail has to look on BambooHR's side.

The error text has a firewall around it. What the caller sees is derived from BambooHR's response body. What is written to the audit trail never is. Audit records are organization-visible and can be forwarded to a customer's own destination. A call from Claude or ChatGPT is recorded with actor_kind of user, the surface mcp, and the OAuth client named. Claude and ChatGPT are among the clients whose name is marked verified by their redirect URIs. The trail is append-only. A compliance reviewer reads it on the free Auditor seat, which lacks tool:execute. So an Auditor cannot call BambooHR at all, only read what others called. What an AI agent audit log must capture covers the record shape in full.

Who owns the BambooHR connection when its creator leaves?

Someone has to, and it will not resolve itself. Elaichi's offboarding preflight lists every connection the departing member owns. A shared connection stays in place unless the admin names an action. It can be transferred to one other active member or deleted, never to the admin running the removal. A private connection that nothing beyond the member depends on cannot be transferred and is deleted with them. In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change.

A transfer changes one thing: the owner. The credential behind the connection is still the original person's sign-in to the app. For BambooHR that credential is an API key tied to their BambooHR user. Plan for it to stop working when that account is deactivated, which would take the whole HR team's access with it. Every toolbox entry the departing owner pinned to that connection also stops resolving after a transfer. That holds for everyone including the new owner, until someone re-pins it.

So plan the swap before the leaving date:

1. Issue a new API key from a BambooHR account that is staying, at the same compensation-hiding access level.
2. Connect BambooHR again in Elaichi with that key, owned by a member who is staying, and share it with the HR team at use.
3. During the leaver's offboarding, delete the old connection or transfer it to another active member.

A private connection pinned into a toolbox its owner shared is marked needs_resolution and waits for an administrator's decision. That is one more reason to pick a long-tenured owner at the start rather than transfer reactively. Offboarding AI access covers the rest of the preflight.

Related questions

Can ChatGPT see my BambooHR salary data if it's connected via MCP? Only if the credential behind the connection belongs to a user whose BambooHR access level includes compensation. A restriction can withhold the pay tools. But an employee read can still return pay fields if the key's user can see them. That is why layer one comes first.

Is MCP inherently unsafe for HR data? No. MCP is a protocol for tool discovery and invocation; it has no opinion on field-level permissions. Safety depends entirely on what the underlying API key can see, which is BambooHR's access level. It also depends on what the control plane in front of it allows, the restriction. The protocol itself neither adds nor removes risk.

Does restricting tools in Elaichi affect BambooHR's own UI or reports? No. Restrictions apply only to calls made through Elaichi's MCP endpoint. A user's direct BambooHR login and its existing access level are unaffected.

The tool list for this connector is on the BambooHR connector page. For the shape of the thing you are building, read what an MCP control plane is. For the same playbook against a payroll system, see keeping payroll data in HR with Gusto.

FAQ

Does a BambooHR API key see salary data?

It sees whatever the BambooHR user who created it can see. BambooHR states that the API can only view or update data that the user can access ([BambooHR help](https://help.bamboohr.com/s/article/587841), checked October 2026), and Get Employee drops fields the caller cannot view without returning an error. Pay data sits in the compensation table and the payRate, payType and paidPer fields, so a key created by an account whose access level hides those fields returns records without them.

Can a consent checkbox make BambooHR read-only in Claude or ChatGPT?

No. On Elaichi's consent screen, "Run your connected tools" covers a connected app's reads and writes alike, and only a tool whose method is a delete needs the destructive scope on top. "Create and change data" governs Elaichi's own operations, not the connected app. Read-only access to BambooHR is written as a restriction in Elaichi, either an allow rule naming the read tools a role needs or blocks on the write tools. A restriction change takes effect within about two minutes.

Why use an allow rule instead of blocking BambooHR's pay tools?

Because Elaichi's BambooHR connector carries 406 tools, and a block list leaves every tool it does not name reachable. An allow rule names what a role may reach and denies the rest. One caution: in Elaichi an allow rule is the target's whole allowlist across every connector, so a role that also uses other apps needs an allow rule naming each of those connectors whole, or it loses them. In Elaichi, restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything.

Does BambooHR have its own MCP server?

Yes. BambooHR runs an official MCP server in beta at {subdomain}.bamboohr.com/api/mcp, which powers its Claude and ChatGPT connectors. An admin gate decides who may use it, and BambooHR says it enforces the company's existing BambooHR permissions, omitting restricted fields without warning ([BambooHR MCP server docs](https://documentation.bamboohr.com/docs/mcp-server), checked October 2026). For a company whose assistant only needs BambooHR, that is a sound choice with no second vendor involved.

What happens to a BambooHR connection when the person who created the API key leaves?

The key belongs to their BambooHR user, so it keeps working until BambooHR's side is handled and should be expected to stop working when their BambooHR account is deactivated. Elaichi's offboarding preflight lists every connection the departing member owns. A shared connection can go to one other active member or be deleted when the admin names that action, and never to the admin running the removal. A transfer changes only the owner, so before the leaving date connect BambooHR again with a key from a staying account at the same access level, and share that connection.

An HR lead wants Gusto in Claude. The ask is reasonable: stop exporting a CSV every time a manager wants a headcount, and stop rebuilding the payroll checklist by hand. The worry is also reasonable. Payroll and salary data should reach the people who run payroll, and nobody else who happens to use the same AI client.

This playbook covers Gusto's own MCP server, run through Elaichi. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps.

What can Gusto in Claude do through Gusto's own MCP server?

Gusto's MCP server reads live payroll and people data, and it acts. Gusto lists logging time, onboarding an employee or contractor, and preparing and running payroll (gusto.com, checked October 2026). Gusto also says every write comes back for confirmation before anything moves.

Gusto builds and runs this server. In Elaichi it is a native MCP connector: Gusto's tools, with Elaichi handling sign-in, access and audit in front of them. Elaichi does not write or fix these tools. Reports about how a tool behaves go to Gusto at support.gusto.com.

Gusto's server decides which tools each account gets. The Gusto connector page lists no fixed tool set for that reason. The tools you govern are the ones Gusto's server lists to your connection, and you read them on that connection's page in Elaichi.

Gusto's confirmation step deserves a plain reading. The confirmation goes to the person in the chat. Through a shared toolbox, that person may not be the admin whose Gusto account the call runs on. Decide who may confirm a payroll run before anyone shares anything.

Who can connect Gusto, and what does the connection see?

Only a primary or global Gusto admin can connect the server. Gusto says a connected assistant reads the Gusto data the authorizing user can already see, and nothing beyond it (gusto.com, checked October 2026). An admin's view is wide, so the connection is wide.

Gusto gives one lever at sign-in. OAuth (the browser sign-in that grants an app access without a password) asks the admin to choose which categories of Gusto data to share. Pick only what HR needs. That choice is the ceiling for every person who later uses the connection, and Elaichi can narrow below it but never above it.

In Elaichi, the credential stays with Elaichi's separate credential service. The AI client holds only an Elaichi token. A connection someone shares runs on its owner's account, so every Gusto call through it reaches Gusto as that admin.

Should HR share the Gusto connection or a Gusto toolbox?

Share a toolbox, and keep the connection private to the admin. A toolbox is a named set of tools pinned to connections. One that holds only Gusto tools gives the HR team exactly those tools and nothing else from the admin's account.

The two choices differ in reach:

A use grantee runs a toolbox's tools without holding any access to the connection behind them. Elaichi still checks that person's own restrictions on every call. Revoking the share takes effect on their next call.

A member who is also a Gusto admin can connect their own account instead. That route suits an admin who uses Gusto in Claude alone. It does not work for a coordinator who is not a Gusto admin, because Gusto requires a primary or global admin to connect.

How do roles and restrictions split Gusto tools inside HR?

Restrictions on roles decide which Gusto tools each person can reach. A restriction is a rule on a role or on one member, naming whole connectors or single tools. In Elaichi, restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything. There is no team target, so HR needs roles of its own, such as an HR coordinator role and a payroll role, built as custom roles on Gold.

A workable split for most HR teams:

• Every role outside HR. Restrict the Gusto connector whole. That also stops another Gusto admin elsewhere in the company from connecting their own account through Elaichi.
• HR coordinator. Restrict the payroll-run tools and any compensation reads Gusto lists to your account.
• Payroll. Keep the full Gusto toolbox.

A restricted tool is not offered to the member's AI client, and a call to it is refused. A member's own rule can only narrow what their role allows; it never widens or replaces the role's rules. A change takes effect within about two minutes. The trade-offs between naming a whole app and naming one tool are worked through in per-tool versus per-app rules.

Why does Elaichi treat an unmarked Gusto tool as destructive?

An MCP server can mark each tool as read-only or as non-destructive. For a native MCP connector, Elaichi counts any tool the server marks as neither as destructive. That is the default for every vendor's server, not a judgment about Gusto.

A destructive tool needs more from the AI client's grant (the access a person approves for one client). The person must tick "Delete data and remove access" at Elaichi's consent screen, as well as "Run your connected tools". That box is never ticked by default. It also covers deleting things in Elaichi itself, so tick it only where the HR chat needs those Gusto tools.

An admin can review each Gusto tool's tier in the console and lower it per tool. The console shows whether a tier came from Gusto's own label, from the default or from an override.

Can you follow Gusto's "use in isolation" advice through Elaichi?

Partly. Gusto's guidelines ask you to use its MCP server in isolation, with no other MCP servers in the same client session. They also ask for trusted clients only, manual confirmation for all tool use, checked outputs and an opt-out of model training (gusto.com, checked October 2026).

Elaichi serves many apps through one endpoint, https://api.elaichi.ai/mcp. Isolation is something you set up per client grant:

• What helps. At consent, each HR member picks Only the ones I pick and selects the Gusto toolbox. That grant reaches only that toolbox's connected tools, and never falls back to all of the person's tools.
• What Elaichi still adds. Elaichi's own operations stay available to that grant, according to the scopes the person ticked. Leave "Create and change data" unticked if the HR chat does not need it.
• What Elaichi cannot see. Other connectors the person turned on in Claude sit outside Elaichi. Claude lets a person switch connectors on or off for each chat (support.claude.com, checked October 2026). Turn the others off for Gusto work.

For manual confirmation, set Claude's tool permission on Elaichi's execute_tool to Needs approval. That one setting covers every connected-tool call made through execute_tool, so it cannot tell Gusto from another app. Model-training settings live in the AI client, and Elaichi does not change them.

Gusto's trusted-client examples are Claude, Gemini and Cursor. Its guidelines do not mention a layer in between. Routing through Elaichi adds a party that holds the Gusto credential, and your security review should weigh that.

What does the audit log record for each Gusto call?

The audit log (the organization's append-only record of actions) gets one row for each Gusto call that reaches execution. The row names the person who made the call, the tool, the connection it reached, the AI client and whether it worked. On a shared toolbox, it names the HR member, not only the admin whose account Gusto saw.

A call refused before execution, such as a restricted tool or a missing consent scope, writes no row. The row keeps no argument values, apart from the one path argument that names the object, recorded as the target id. So a pay rate passed as an argument is not written to the log.

When should HR connect Gusto directly, or not at all?

Connect Gusto's server directly when one or two Gusto admins will use it themselves, in one client, with no other apps. Gusto's guidelines are written for that shape. A direct connection skips Elaichi entirely, so Elaichi governs none of those calls, and nothing is lost if nobody else needs access.

Elaichi earns its place when non-admins need Gusto, when HR also works in other apps through Claude, ChatGPT, Cursor or any MCP client, or when the company wants one audit trail. The wider argument is in running vendor MCP servers through Elaichi.

Do not connect Gusto at all in three cases:

• The company will not accept an admin-level connection used by people who are not admins.
• The team will not keep confirmations manual, in Gusto and in the client.
• The data categories Gusto offers at sign-in are wider than anyone outside payroll should reach.

What happens to the Gusto connection when its admin leaves?

The HR setup keeps working only if you plan the handover. Elaichi's offboarding preview lists every connection the departing admin owns and the toolboxes that pin it. Transfer the HR toolbox to an admin who is staying. A transfer changes the owner and keeps every share.

The toolbox's entries still run on the departing admin's Gusto sign-in. Before that Gusto account is deprovisioned, have the staying admin connect Gusto with their own account and point the toolbox's entries at the new connection. Then deprovision the old account in Gusto or through your identity provider. The general version of this problem is in offboarding when the agent holds access, and other HR setups, such as Rippling in Claude, are on the use cases page.

FAQ

Can Gusto in Claude run payroll?

Yes, through Gusto's own MCP server. Gusto says the server can prepare and run payroll, log time, and onboard employees and contractors, and that every write comes back for confirmation before anything moves ([gusto.com](https://gusto.com/product/integrations/gusto-mcp), checked October 2026). In Elaichi, payroll-run tools can be restricted to the roles that should hold them.

Who can connect Gusto to an AI assistant?

Only a Gusto admin. Gusto's MCP page lists primary or global admin permissions as a requirement, and Gusto says a connected assistant reads what the authorizing user can already see ([gusto.com](https://gusto.com/product/agents), checked October 2026). A connection made by an admin therefore reaches admin-level data, within the data categories picked at sign-in.

How do you stop HR coordinators from running payroll through Gusto in Claude?

Give them a role of their own in Elaichi and write a restriction on that role naming Gusto's payroll-run tools. A restricted tool is not offered to their AI client and is refused if called. The rule takes effect within about two minutes. A person's own rule can only narrow what their role allows, never widen it.

Does Elaichi write or fix the Gusto MCP tools?

No. Gusto builds and runs the MCP server and its tools. Elaichi handles sign-in, access and audit in front of it, and reports about how a tool behaves go to Gusto's support team at support.gusto.com.

Is a Gusto call recorded when HR uses a shared connection?

Yes. Each Gusto call that reaches execution writes one audit row naming the person who made it, the tool, the connection, the AI client and the outcome. The row holds no argument values except the one path argument that names the object, recorded as the target id.

What do the three admin consoles control?

Each vendor console governs connectors on its own client and nothing else. The switches differ, the plan requirements differ, and so does the vocabulary.

You approved Claude for support, ChatGPT for marketing and Cursor for engineering. Each one now has an admin page for connectors, and none of those pages knows the other two exist. So IT admin controls for MCP connectors is really three questions, answered in three places. MCP (Model Context Protocol) is the protocol an AI client speaks to reach tools outside itself, and a connector is a server it talks to.

This comparison covers Claude, ChatGPT and Cursor. Microsoft Copilot's MCP governance runs through Power Platform data policies, advanced connector policies and the Microsoft 365 admin center. That stack is compared in Copilot Studio vs an MCP gateway. If you run a mixed fleet that includes Copilot, treat the table below as partial.

Everything below is read from each vendor's own documentation, checked October 2026. Date anything you copy out of it, because these consoles move.

Sources, all checked October 2026: Anthropic's custom connector and directory pages, OpenAI's admin controls for plugins and apps, and cursor.com/docs/mcp.

What can an Owner enforce in Claude's console?

Claude's console governs what an Owner added, on Anthropic's surface only. Directory connectors stay off until an Owner or Primary Owner adds them under Organization settings, then Browse connectors, then Add to your team. Adding connects nobody. Each member still signs in with their own account.

Custom connectors, which is what a remote MCP server is, are added by Owners and Primary Owners. On Enterprise a custom role holding Libraries (Manage) can add one as well. Ordinary members cannot add one; they enable what was added. The order these steps belong in across a whole company is set out in the Claude and ChatGPT rollout sequence.

On Team, members see a Request button on a directory connector. Owners find those requests under Requested by your team in Organization settings, and on the Requests tab in Notifications (claude.com/docs/connectors/directory, checked October 2026). Anthropic's page does not say Enterprise members get the same button, so do not plan around it.

Tool permissions are the sharp control. Per connector, per group or per tool, an Owner sets Always allow, Needs approval or Blocked. Anthropic states the limit in its own words on the custom roles page (checked October 2026). These permissions do not govern connectors a member runs locally on their own machine. That gap is worth treating as critical rather than cosmetic. A Blocked connector in the console does nothing to a copy of the same server a developer points Claude Desktop at locally. Device policy, covered below, is the only lever that reaches it.

What does ChatGPT's console control for MCP apps?

ChatGPT's controls are per app, and on the right plans per role. Apps, formerly called connectors, are managed at Admin Console, then the workspace, then Plugins (help.openai.com, checked October 2026). The older Workspace settings route is still reachable through Manage Legacy Apps. Labels moved during 2026, so date any menu path you write down.

Each app is on or off for the whole workspace. Business apps start on, and new Enterprise and Edu workspaces start with a selected set on. Giving different teams different apps is Enterprise and Edu only, through custom roles under Permissions and roles, then Custom roles, then Plugins and connected data. Roles add up, so any role granting a permission grants it, and changes take up to five minutes (help.openai.com, checked October 2026).

Within an app, Actions turn read and write actions on separately. New actions decides what happens when the app gains more. Plugin permissions decide when ChatGPT asks first: Always ask, Allow read actions, Allow low-risk actions, and per app, Allow all actions. Members of a managed workspace never get a lasting Always allow (help.openai.com, checked October 2026).

Custom MCP apps are published by Admins and Owners only, and on Business only admins use developer mode. A published app runs on a frozen snapshot of its tools, so new actions arrive disabled until an admin refreshes them. OpenAI does not verify custom apps (help.openai.com, checked October 2026). The frozen snapshot is a real failure mode. If a connector publisher adds a destructive new tool after the app was published, ChatGPT members cannot reach it until an admin refreshes the app. That is a safety net, and it also keeps a legitimately useful new read-only tool invisible for the same reason.

One consequence matters for any single-endpoint setup. Elaichi's connected tools are never listed individually; the model finds one with search_tools and runs it with execute_tool. ChatGPT therefore sees one app with a handful of tools, and its per-action switches cannot tell a Salesforce read from a Zendesk delete. Setting the Elaichi app to read actions only does not make the apps behind it read-only. Narrowing ChatGPT's own app list is covered in restricting ChatGPT Enterprise connectors.

What can a Cursor team admin enforce?

Cursor separates distribution from policy and says so plainly. "MCP distribution and MCP policy are configured separately. Team admins can distribute shared MCP servers. Enterprise admins can configure MCP policy" (cursor.com/docs/mcp, checked October 2026). That distinction generalizes beyond Cursor. In every console here, "who can make a server available" and "what that server is allowed to do once available" are separate permission axes. They are often on different plan tiers.

Shared Team MCP servers live under Dashboard, then Plugins and MCPs, and are available to Cloud Agents. Add to Team Marketplace makes one available in the Agent Window, the IDE and the CLI.

The policy allowlist is Enterprise only, and Cursor is explicit about what it does not do. Adding a server to the allowlist does not push it to users' machines. Team members still need to configure the server in their own Cursor settings. Individuals add a remote server by url in .cursor/mcp.json for a project or ~/.cursor/mcp.json globally. Cursor supports OAuth for servers that require it, and asks for approval before using MCP tools by default.

For what the console cannot reach, Cursor documents hooks. An MDM-deployed beforeMCPExecution hook sees the server name and the URL or command on every call. It can allow, deny or ask (cursor.com/docs/hooks, checked October 2026). A device the hooks file never reached runs without the hook, so monitor MDM delivery.

Which servers sit on laptops, and who can see them?

Nobody's console lists them. No client vendor documents an admin inventory of the servers sitting in members' local config files. Admin consoles report only what connects through the vendor's own surface. Finding local servers means reading the files on each device with an MDM or EDR script.

The paths, all checked October 2026. Claude Desktop keeps servers in claude_desktop_config.json under ~/Library/Application Support/Claude/ or %APPDATA%\Claude\ (modelcontextprotocol.io). Claude Code uses ~/.claude.json and a project .mcp.json; ~/.claude.json also holds the sign-in session, so read only its mcpServers objects (code.claude.com). Cursor uses ~/.cursor/mcp.json and .cursor/mcp.json (cursor.com/docs/mcp). Codex uses ~/.codex/config.toml (learn.chatgpt.com). VS Code with GitHub Copilot now steers new servers to .mcp.json at the project root and ~/.copilot/mcp-config.json (code.visualstudio.com). The longer version of this hunt is in find the MCP servers employees have installed.

Device policy is where you close the gap. Claude Desktop reads com.anthropic.claudefordesktop on macOS and HKLM:\SOFTWARE\Policies\Claude on Windows, where isLocalDevMcpEnabled and the two desktop extension keys default to true (support.claude.com, checked October 2026). Claude Code managed settings filter with allowedMcpServers and deniedMcpServers. The denylist always wins, and managed-mcp.json takes exclusive control. Anthropic warns that matching by serverName is not a security control, because users choose the names (code.claude.com, checked October 2026). VS Code ships chat.mcp.access, delivered as the ChatMCP policy, taking all, registry or none. Per-server allow and deny lists sit alongside it, where deny beats allow (code.visualstudio.com, checked October 2026). Devin Desktop, formerly Windsurf, blocks every other server for the team once any server is allowlisted (docs.devin.ai, checked October 2026).

Where IT admin controls for MCP connectors stop short

Every console above governs its own client competently. Three jobs sit outside all of them.

One rule that holds in all three clients. A tool restricted in Claude is not restricted in ChatGPT. An Enterprise allowlist in Cursor says nothing about what a member reaches in the ChatGPT web app. Each decision is written three times, by three admins, in three vocabularies, and starts drifting the day it is written. It fails silently: nothing errors, nothing logs a conflict, the same person simply has different access depending on which app they open.

Per-tool rules for the apps behind one endpoint. Route your clients through a single MCP endpoint and each client sees that endpoint's tools, not the connected tools underneath. For an aggregator like Elaichi that is search_tools and execute_tool. A Claude tool permission set on execute_tool covers every connected tool at once. That is the right granularity for the endpoint and the wrong granularity for Jira versus Salesforce. This only matters if you've put an aggregating endpoint in front of your clients. If every connector is added directly in each console, this gap doesn't apply to you. The choice between those two levels is unpacked in restricting one tool or the whole app.

One audit trail across clients. Anthropic's Compliance API records connector connects and disconnects for Enterprise, with no backfill (platform.claude.com, checked October 2026). OpenAI's Compliance Logs Platform is Enterprise and Edu only, keeps files 30 days, and documents no tool-name field (chatgpt.com admin API reference, checked October 2026). Cursor's Enterprise audit log carries mcp_server_config and mcp_authentication events (cursor.com, checked October 2026). Three formats, three retention windows, three sets of ids, and nothing joins them into an answer about last week's Salesforce changes. This doesn't block anything in real time. It does mean a post-incident investigation across clients requires manually correlating three exports by timestamp and user email, not by a shared id. The shape of the record you actually need is in what an AI agent audit log must capture.

Disclosure, and where the vendor-neutral part of this post ends

Everything above is sourced to vendor documentation, dated, and checked against each vendor's documentation in October 2026. Everything below describes how Elaichi, the product this blog is published by, addresses the three gaps above. It is not vendor-neutral, and it is not independently audited. Read it as one vendor's design decision, not as documentation with the same evidentiary status as the Anthropic, OpenAI and Cursor links above.

Splitting the work: consoles for devices, endpoint for rules

The client console decides which connectors exist on that client and what runs on employee laptops. A separate control plane like Elaichi decides what the approved connector may reach, once, for every client. That is the general shape of the fix for the three gaps above, independent of which vendor implements it.

In the client console, allow only the connectors you approved and govern local servers. That means Claude's device policy keys and Claude Code managed settings, Cursor's Enterprise allowlist plus an MDM hook, VS Code's chat.mcp.access, and ChatGPT's per-app switches. Nobody can do that part for you, because the files sit on the devices.

In Elaichi specifically, a restriction names whole connectors, single tools, or both. It targets a role or a user, which is why each role is written as one complete job. In Elaichi, restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything. A user-targeted rule can only narrow what the role allows, and blocks always beat allows. To let one person past a role block, they file an access request and an admin approves it. An allow rule is the target's whole allowlist across every connector, so every app the rule does not name is denied for that role. Holding one app to reads without touching the rest is done with blocks on that app's write tools.

A restricted tool is withheld from tools/list and cannot be called. search_tools names it, flagged restricted, with no schema, so the model has nothing it can run. Role and restriction changes take effect about two minutes, on the MCP endpoint, the console and the REST API alike. In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change.

One organization-wide endpoint serves Claude, ChatGPT, Cursor and any other MCP client, so the rule is written once. Each member still connects and signs in with their own OAuth grant. That grant is the browser consent that hands their client a scoped permission to act as them. The audit trail records the surface and the OAuth client each call came through. The client's name is marked verified when its redirect URIs prove it, which covers Claude, ChatGPT and Cursor. A client signing in through a loopback address, such as Claude Code or Codex CLI, shows the name it registered with, marked unverified.

When the client consoles are enough

Skip the second layer when there is nothing underneath it to govern. If your agents only reach servers your own engineers wrote, the client consoles plus device policy are the whole control set. A second vendor buys you nothing.

If you have standardized on Cloudflare Access, Cloudflare's MCP server portals put remote HTTP MCP servers behind one endpoint. That endpoint sits inside the access layer you already run, with per-server sign-in for users (developers.cloudflare.com, checked October 2026). This is a different shape from Elaichi. Cloudflare fronts whichever servers you or your vendors run, as you add them to a portal. Elaichi serves 600+ connectors, authoring most of them and governing vendors' own MCP servers for the rest, so there are no servers for you to run or list.

Pick based on what your agents reach, not on vendor preference. Servers you wrote point toward a fronting layer like Cloudflare Access; SaaS accounts your staff already hold point toward a managed-connector layer like Elaichi. The architecture behind that split is in what an MCP control plane is. The per-client version of the same argument is in Claude and ChatGPT connectors against one endpoint. The apps the rules apply to are listed at /connectors/.

FAQ

Can one admin console govern MCP connectors in Claude, ChatGPT and Cursor at once?

No. Each vendor's admin console governs only its own client. Claude Team and Enterprise control the connectors an Owner added plus per-tool approval states; ChatGPT Business, Enterprise and Edu control per-app switches and read or write actions; Cursor's policy allowlist is Enterprise only and does not push servers to machines. A rule written in one console does not reach the other two, so a company-wide rule has to live at the server the clients connect to. All checked October 2026.

Does Claude's per-tool permission cover connectors a member installs locally?

No. Anthropic's custom roles page states that connector tool permissions do not govern connectors a member runs locally on their own machine (checked October 2026). Local servers are governed separately: Claude Desktop device policy keys such as isLocalDevMcpEnabled, and for Claude Code the allowedMcpServers and deniedMcpServers managed settings, where the denylist always wins.

Will setting a ChatGPT app to read actions only make the apps behind it read-only?

Not when the app is a single MCP endpoint. ChatGPT's per-action switches apply to the tools the app advertises. Elaichi advertises search_tools, execute_tool and its own control-plane operations, and connected tools are never listed individually, so one switch covers every connected app at once. Read-only access to a specific connected app is written in Elaichi as a restriction: blocks on that app's write tools, or an allow rule naming its read tools. An allow rule is the role's whole allowlist across every connector, so blocks on that app's write tools are the way to hold one app to reads without touching the rest.

How do I find the MCP servers employees already configured?

By reading the config files on each device with an MDM or EDR script. No client vendor documents an admin inventory of servers sitting in members' local config files; admin consoles report only servers that connect through the vendor's own surface. The paths include ~/.cursor/mcp.json for Cursor, ~/.claude.json and .mcp.json for Claude Code, ~/.codex/config.toml for Codex, and claude_desktop_config.json for Claude Desktop.

How long does a restriction change in Elaichi take to apply?

A role or restriction change takes effect about two minutes. Both resolve through a 60-second cache plus edge propagation, on the MCP endpoint, the console and the REST API alike. Some changes are faster. In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change.

What a help desk ticket actually needs from Intune

A technician picks up a ticket: this laptop never applied the new Wi-Fi profile. The answer sits in Microsoft Intune. Which devices does the person have, is each one compliant, which configuration profiles landed, what apps were detected. Five read calls and the ticket closes. Putting Intune in Claude is worth doing for exactly that loop. The risk is everything else that arrives with it.

Elaichi's msintune connector carries 198 tools. Sixty-nine have names starting with list_ or get_, and they read, including list_all_msintune_managed_devices, get_single_msintune_managed_device_by_id, list_all_msintune_device_compliance_policies, list_all_msintune_device_configurations and list_all_msintune_detected_apps. Most of the other 129 create, update or delete records, or run actions on devices: wipe, retire, remote lock, script deployment and more.

Elaichi serves 600+ connectors through one organization-wide MCP endpoint. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. The design question for any connected app is the same: which of a connector's tools may a given role reach, and how is that decision enforced so it cannot quietly widen over time? For Intune specifically, that means deciding on the 69 read tools. Write the decision down once, rather than re-deciding it per technician or per incident.

General principle: allowlists survive, denylists decay

Before the Intune specifics, the underlying rule generalizes to any tool-calling AI connector, not just MCP or Elaichi:

• A denylist only covers what you named. Every tool you didn't think to block on the day you wrote the rule stays reachable. Tools a connector gains later are reachable by default unless the denylist is re-audited on every connector update.
• An allowlist is closed by construction. Naming the tools a role may use means everything else is denied, including tools that don't exist yet. This is the standard default-deny posture applied to tool calls.
• The two produce different failure modes. A denylist fails open (new or unnamed tools leak through). An allowlist fails closed (a technician hits a wall and has to file a request). Some workflows carry a high downside from an unreviewed write, such as device wipe, user deletion or remote lock. For those, fail-closed is the only defensible default.

This is a restatement of a well-known security principle (default-deny beats default-allow), not something specific to Elaichi.

Why blocking wipe and retire is not read-only

Six blocks is the obvious move, and it does not produce a read-only role. A block rule covers only the tools it names.

The six that come to mind: msintune_managed_devices_wipe, msintune_managed_devices_retire, msintune_managed_devices_remote_lock, msintune_managed_devices_reset_passcode, msintune_managed_devices_bypass_activation_lock and delete_a_msintune_managed_device_by_id. Block all six and the role still holds msintune_managed_devices_execute_action. That tool runs a named remote action on one or more devices via two arguments, actionName and deviceIds. Blocks on the six named tools do not cover it. A block matches a tool's name or its pinned operation, and this is a different operation.

Still reachable after those six blocks:

A denylist is a list of the writes somebody thought of on the day it was written. It is not, and cannot become, a complete inventory of what a connector can do. The wider trade-off between blocking individual tools and blocking an entire app is in restricting one tool against the whole app.

Writing the allow rule for Intune in Claude

Intune in Claude becomes a lookup tool when the help desk role holds an allow rule. That rule names the five read tools above, not a stack of blocks. A restriction in Elaichi states which connectors and tools a role or a user may reach. Name the five, and every other msintune tool is denied for that role by default.

One property catches people out: an allow rule is the target's entire allowlist across every connector, not just the app it mentions. Allow rules on the same role union together: the role's allowlist is the sum of every allow rule attached to it. If the help desk role also uses Slack and Jira, you must write a separate allow rule naming each of those connectors in full. Without them, the role loses Slack and Jira as soon as the Intune-only allow rule takes effect. The presence of any allow rule switches that role from default-allow to default-deny across the board.

Two mechanical details matter before you save the rule:

• A restricted tool is withheld, not just refused. It is withheld from the tool list and cannot be called. Search names it, flagged restricted, with no schema.
• A restriction change is not instant. It takes effect within about two minutes. Blocks match a tool's name or its pinned operation; allows match the pinned operation only. That asymmetry is the subject of why allows bind the operation.

Which Microsoft account should hold the Intune connection?

Connect with the narrowest Microsoft account that covers the required reads. The msintune connector signs in with OAuth as a person, so every call reaches Microsoft Graph as that account (checked October 2026). A shared connection runs on its owner's credential. Every technician's lookup reaches Graph as the connecting account, regardless of what Microsoft role that individual technician holds personally. The opposite shape, where each person connects their own account, is the right one when the app's own permissions should decide what each caller sees.

That account's Intune role is the outer limit; Elaichi's restrictions narrow access from there, never widen it. Compare the three systems that stack on top of each other:

Never connect as a Global Administrator, whose reach goes far beyond Intune.

The account you connect with is a ceiling the Elaichi allow rule sits under, never a floor it can raise. A delegated app cannot exceed the signed-in user's own permissions (Graph permissions overview, checked October 2026). All three Graph permissions above need an administrator's consent whether the call is delegated or app-only (Intune Graph APIs, checked October 2026; built-in roles reference, checked October 2026). Pairing Read Only Operator with the five-tool allow rule gives two independent layers that both have to agree before a write can happen.

Multi Admin Approval as a second signature on device actions

Multi Admin Approval is Intune's own opt-in second-signature control. It applies to calls made through Graph, delegated and app-only alike, not just the Intune admin center UI. It is configured as an access policy scoped to a specific resource type. The device actions policy covers wipe, retire and delete only. It is a backstop against the three worst outcomes, not a general write gate across all 129 non-read tools (Multi Admin Approval, checked October 2026). Separate access policies can protect scripts, apps, and compliance and configuration policies.

It applies to changes only, never to reads, so a help desk role doing lookups never triggers it. A protected call does not queue silently: it fails immediately and returns an approval request. The action runs only after a second administrator approves it in the Intune admin center and the original request is resubmitted with the approval code. Applications cannot approve their own requests. Changes to the access policies themselves always require a second administrator's sign-off, so one administrator cannot switch it off alone.

Multi Admin Approval and an Elaichi allow rule solve different problems. The allow rule stops a role from ever seeing the wipe tool. Multi Admin Approval adds a second human in the loop. It covers the rare case where a role that does have wipe access tries to use it.

Adding the endpoint in Claude, and what consent decides

On Claude Team and Enterprise, an Owner or Primary Owner adds Elaichi once, at Organization settings, Connectors, Add, Custom, Web (Anthropic's documentation, checked October 2026). The address is https://api.elaichi.ai/mcp for every organization. Members then connect it individually under Customize, Connectors, each with their own OAuth grant.

The consent screen is not where read-only access comes from. For a connected app's tools, the "Run your connected tools" checkbox enables reads and writes equally. Only a tool whose underlying method is a delete additionally requires the delete checkbox. "Create and change data" left unticked governs Elaichi's own internal operations, not Intune's write tools at all. Read-only Intune access comes from the allow rule, every time, not from any consent checkbox.

Claude's own per-tool permission settings don't substitute for this either (connector tool permissions, checked October 2026). Elaichi's connected tools all route through a single execute_tool call on Claude's side. So a permission set at that layer covers every connected app at once, not Intune specifically.

When a technician needs a tool the allow rule leaves out

Any member can file an access request with no permission of their own. Resolving a request requires member:manage, and an administrator cannot approve their own request. This is the designed path for the Tuesday when somebody genuinely needs a device action the allow rule withholds.

An admin approves the request in the console, under Governance, Access requests, and the person then has an access grant. The grant is for that one person. It lifts exactly the one tool requested out of their role rules. Every other rule on their role keeps applying, and nobody else changes. No rule is written and the role is not edited. No access request can be approved or denied from inside Claude, any other MCP client or the Elaichi Agent, so no AI surface can widen a restriction.

What the audit trail shows after a device lookup

Elaichi writes one entry for each connected-tool call that reaches execution (a call refused earlier writes none). Each entry names the account actually reached, not the one a user meant to reach. So after a lookup, the entry shows which technician called get_single_msintune_managed_device_by_id, the Intune connection it reached and the outcome. The entry carries the one path argument that names the object, here the device, as the target id, and no other argument value.

Each entry also records the calling surface and the OAuth client. A call from Claude is logged as a user action with surface mcp, with Claude named and marked verified, because its redirect URIs prove it. The approval field reads "Allowed by the access Claude was granted". Over MCP, the standing grant is the approval, and there is no separate per-call approval step. Log writes are eventually consistent, so a given row can take a short time to appear after the call completes. The full field-by-field schema is in what an AI agent audit log must capture.

Who owns the Intune connection when that admin leaves

Pick a connection owner who is staying, because the connection runs on that person's Microsoft sign-in, not an abstract service identity. Removing a member in Elaichi triggers an offboarding preflight, a check that lists every connection the departing member owns before the removal completes. The preflight lists private and shared connections alike. Only a private connection that a shared toolbox still relies on can block the removal. A shared connection is left untouched unless the admin deletes it or transfers it to a member who is staying. Use the transfer action before the person leaves. A transfer goes to one member, never to a team or the organization, and it sets a new owner on the connection. It leaves every existing grant on it exactly as it was, with no re-approval needed.

Transferring ownership in Elaichi does not change the credential underneath. The connection still runs on the departing person's Microsoft sign-in, and that account still has to be deprovisioned in Microsoft Entra ID. So before it is, have the staying owner connect Intune with their own narrow account and share that connection with the help desk. A SCIM deprovision suspends the member in Elaichi rather than removing them. In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change. Offboarding when the agent holds access covers the rest of the preflight.

Microsoft ships no Intune MCP server, so what else is there?

There is no official Microsoft MCP server for an Intune tenant today. Microsoft's MCP Server for Enterprise is a read-only Microsoft Entra preview with no Intune scopes (get-started page, checked October 2026). The alternative to a vendor gateway is self-hosting: an Entra app registration plus a host somebody on your team maintains and patches. The real cost of running your own MCP servers sets out what that ongoing maintenance involves.

If the help desk works entirely inside the Intune admin center, nothing needs to leave it, and none of this applies. A team with no need to ask device questions from Claude, ChatGPT or Cursor does not need a gateway at all.

The case for doing this through a gateway like Elaichi rather than a one-off connector is narrow and specific. One endpoint serves Intune alongside the rest of the stack. One role carries the allowlist across all connected apps, rather than one config per app. One audit trail answers who ran what across every tool, not just Intune's. The full tool list for each connected app is in the connector catalog. The use cases page shows the same pattern for other teams.

FAQ

Does Microsoft ship an official MCP server for Intune?

No. There is no official Microsoft MCP server for an Intune tenant. Microsoft's MCP Server for Enterprise is a read-only Microsoft Entra preview with no Intune scopes ([learn.microsoft.com](https://learn.microsoft.com/en-us/graph/mcp-server/get-started), checked October 2026). Teams reaching Intune from Claude or ChatGPT today either run a server themselves or use a governed MCP control plane such as Elaichi, whose msintune connector carries 198 tools.

Is blocking the Intune wipe and retire tools enough to make an AI assistant read-only?

No. Elaichi's msintune connector carries 198 tools, and only 69 of them read. Blocking wipe, retire, remote lock, reset passcode, bypass Activation Lock and delete device still leaves msintune_managed_devices_execute_action, which runs a named remote action on one or more devices, plus reboot, shut down, disable, clean Windows device, device management scripts and delete_a_msintune_user_by_id. A block rule covers only the tools it names. An allow rule naming the read tools you want is how a role is held to lookups.

Which Microsoft account should connect Intune to an MCP client?

The narrowest account whose Intune role covers the reads the team needs. Calls through Elaichi's msintune connector are delegated, so they reach Microsoft Graph as the connecting account, and a shared connection runs on its owner's credential. Microsoft's built-in Help Desk Operator can wipe, retire, remote lock and reset passcodes, while Read Only Operator's only remote task is getting a FileVault key ([learn.microsoft.com](https://learn.microsoft.com/en-us/intune/fundamentals/role-based-access-control/ref-built-in-roles), checked October 2026). Never connect as a Global Administrator.

How quickly does a restriction change on an Intune role take effect?

Within about two minutes. Role and restriction changes in Elaichi resolve through a short cache, so a new allow rule or block binds every surface shortly after you save it. Some changes are faster: revoking an OAuth grant, removing or suspending a member, revoking a share and disconnecting an account all take effect on the caller's next request.

Does ticking "Run your connected tools" let Claude write to Intune?

Yes. On Elaichi's consent screen, that checkbox covers a connected app's reads and writes alike, and only a tool whose method is a delete needs the separate delete permission. Leaving "Create and change data" unticked governs Elaichi's own operations, not Intune's create and update tools. Read-only access to a connected app is a restriction written in Elaichi, never a consent checkbox.

Why Jamf in Claude needs a connector

A help desk agent has a ticket open and a serial number. The answer sits in Jamf Pro: which Mac, which person, which OS build, which apps are installed. Jamf in Claude is worth setting up so that lookup happens inside the ticket, not in a second console with a second sign-in.

Jamf ships no official MCP server for a live Jamf Pro tenant. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. Jamf's own MCP server searches Jamf's API documentation and returns nothing about a live fleet (developer.jamf.com, read October 2026). MCP Hub is a separate, Jamf Concepts open-source project, labeled Beta. Its own repository describes it as not an official product, meant to run locally, and shipping with write tools enabled by default (read October 2026). Neither one is a managed, multi-user path to a live tenant.

The shortcut an engineer reaches for is a local server with a Jamf token in a config file. That works for one person testing queries on a laptop. It leaves nobody able to say afterward what was queried, and nothing to change when that person moves teams or leaves. Replacing personal MCP servers covers where that shape stops holding.

The fleet path for a team is a connector that calls the Jamf Pro API on the help desk's behalf. It runs under credentials nobody on the help desk ever sees directly. Elaichi's jamf connector is a connector Elaichi authors, maintains and serves from its own infrastructure. It signs in with a Jamf API client's credentials. Those credentials sit in a separate credential service, encrypted at rest.

Build the Jamf API role before you connect anything

Create a dedicated API role holding only the read privileges a help desk ticket needs, then create an API client that carries that one role. The path in Jamf Pro is Settings, then System, then API Roles and Clients. An API client gets the combined privileges of every role assigned to it. So one narrow role is easier to defend in an access review than three broad ones stacked together (learn.jamf.com, read October 2026).

What to leave out, specifically:

All five are named in Jamf's own privilege reference (developer.jamf.com, read October 2026). The role should hold read privileges for computer inventory, mobile devices, users and accounts. That is enough to answer "which Mac, whose it is, what's on it". It should hold nothing that creates, destroys, or remotely commands a device.

The Jamf role is the outer wall. It binds every call the client makes, including calls Elaichi never sees. If a tool somehow got past Elaichi's own restrictions, this role is what stops it from doing anything destructive at the Jamf API itself.

What the jamf connector carries, and what it leaves out

Elaichi's jamf connector exposes 25 tools total. The split, by effect on data:

No tool in the connector sends a wipe command, a device lock, or an unmanage command. Those commands are not in the connector at all, so the model cannot reach for one however the request is phrased. Its riskiest tools delete records and create accounts; none of them wipes a Mac.

This shapes how you plan the two layers. If the Jamf API role holds no write privileges, a write tool in Elaichi fails at Jamf's wall. The failure lands in the audit trail as an error. That is correct, but noisy, and a tool the model can run is a tool it may try. The cleaner shape is to restrict the write and delete tools in Elaichi as well. The model then cannot run them at all. Search names them only as restricted, with no schema.

One API client, many people: how restrictions narrow it

A Jamf API client authenticates with client credentials, and each token's subject is the client, not a person. Everyone calling through that one connection gets the same reach into Jamf. Jamf Pro has no concept of "this call came from help desk agent X vs. agent Y" once it is behind one API client. Narrowing per person happens in Elaichi, through restrictions: rules naming which connectors and which individual tools a role or a user may reach.

The setup for a team: an IT admin connects the Jamf API client once, then shares that connection at use with the help desk team. A shared connection runs on its owner's credential, so every agent's call reaches Jamf as that same API client. Then write a restriction against the help desk role. Custom roles are a Gold-tier feature, and one person holds exactly one role at a time. So the help desk role functions as a complete persona rather than an add-on permission.

There are two ways to write the rule, and one of them has a trap:

• Block rule names the connector's write and delete tools specifically (create_a_jamf_account first among them). It leaves the role's other connectors and tools untouched. Safe default for "hold one app to reads."
• Allow rule: once a role holds even one allow rule, that rule becomes the role's entire allowlist across every connector it uses. An allow rule naming only Jamf's read tools will silently deny Zendesk, Slack, and everything else the role was supposed to reach.

Use blocks when you are restricting one app within an otherwise-open role. Use allow rules only when you are deliberately writing the role's complete approved-apps list. In that case name every connector it needs, not just the one you are thinking about right now. A block matches the tool name or its pinned operation. An allow matches the pinned operation only. The mechanics are in why blocks match tool names but allows do not.

A restriction change takes effect within about two minutes. The change applies on every surface, MCP, console and REST alike, and a restricted tool is withheld from the tool list. Search names it, flagged restricted, with no schema, and it cannot be called.

Add the one endpoint in Claude and let agents sign in

Claude points at one address for the whole organization: POST https://api.elaichi.ai/mcp. On Claude Team and Enterprise, an Owner or Primary Owner adds it once under Organization settings, Connectors, Add, Custom, Web. Each member then connects it individually under Customize, Connectors (support.claude.com, checked October 2026). There are no per-user URLs and no tokens to paste in. Each agent still signs in once with their own OAuth grant, the browser handshake that ties their Elaichi identity to that Claude client.

On Elaichi's consent screen, the agent ticks the scopes the client asked for. Two things worth telling them up front: "Run your connected tools" is the scope that reaches Jamf at all. Leaving "Create and change data" unticked does not make Jamf read-only. That checkbox governs Elaichi's own operations, such as editing a saved connection, not a connected app's tools. Read-only Jamf is a function of the restriction on the help desk role, not of this checkbox.

In Elaichi, connected tools are never listed one by one, however few there are. The agent asks about a serial number, the model calls search_tools, then runs the match with execute_tool. Claude's per-connector tool permissions, Always allow, Needs approval and Blocked, land on execute_tool as a single gate. One setting there covers every connected tool at once, with no per-tool granularity on Claude's side (claude.com, checked October 2026). Per-tool decisions for Jamf belong in Elaichi's restrictions, not in Claude's connector settings. The client-side walkthrough is in connecting Elaichi to Claude.

Ending access while the Jamf token is still valid

Disabling or deleting a Jamf API client does not revoke tokens that are already issued and still valid (learn.jamf.com, read October 2026). Token lifetime is configured per client. A long lifetime leaves a real window after you think you have cut access off. A token minted an hour before you disable the client can keep working until it expires on its own schedule.

This is a direct argument for keeping the credential in Elaichi rather than on a laptop. The departing agent never held the Jamf token in the first place. Cutting them off means removing the member, suspending them, or revoking the share on the connection, none of which require touching Jamf Pro itself. In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change. A SCIM deprovision suspends the member and revokes every live grant in one action. Removing the member outright is a separate, deliberate step an admin takes in Elaichi afterward.

One thing to plan in advance: a shared connection runs on its owner's credential. If the admin who originally connected Jamf leaves the org, transfer ownership during offboarding to someone who is staying. Otherwise the whole team's Jamf access is tied to a departing person's state. The offboarding preflight lists every connection that member owns, specifically so this does not get missed. Offboarding when the agent holds access covers the rest of that checklist.

What the audit trail shows after a ticket closes

Elaichi writes one entry for each connected-tool call that reaches execution (a call refused earlier writes none). Each entry names the operation and tool, the connection actually reached, and the classification. It also names whether it was approved, the outcome, and an error code if one occurred. The entry carries the one path argument that names the object as the target id, and no other argument value. A device ID in the path is recorded. The body of an update is not.

The entry also records the surface and the OAuth client. A call from Claude shows surface mcp with Claude named and marked verified, because its redirect URIs prove it. The actor kind recorded is user, not ai_assistant: that second marker is reserved for calls made through the in-app Elaichi Agent, a different surface. Approval reads as "Allowed by the access Claude was granted," because over MCP the OAuth grant itself is the approval event, not a separate click. The trail is append-only and eventually consistent, so a row may take a short delay to appear after the call completes. A compliance reviewer can read all of this on a free Auditor seat. That seat lacks the tool:execute permission and therefore cannot call anything itself. Read access to the log does not imply write access to the fleet. For what to check in these records during a review, see what an AI agent audit log must capture.

When Jamf's own AI Assistant is the better answer

If your admins are happy working inside the Jamf console, use Jamf's built-in AI Assistant instead and stop here. It is a better fit for that specific job. It has been generally available since 31 March 2026, and it is read-only. It makes GET calls as the signed-in user, so it inherits that person's existing Jamf permissions with no second credential anywhere (learn.jamf.com, read October 2026). For a Jamf admin answering a Jamf-only question inside Jamf Pro, that is less machinery than anything described in this post.

The case for a connector is the ticket, not the device record in isolation. The agent is in Claude with the customer's message, the Zendesk history, and the device state in one place. They are not a Jamf admin with console access of their own. If one engineer only wants to test queries on their own laptop, a local server is still a better fit than an organization-wide control plane. When you do not need an MCP gateway yet draws that line explicitly. Once several people need the same reach, and somebody has to be able to prove afterward what was looked up and by whom, an MCP control plane is what you are actually buying. The connector is just the part you interact with. Browse the rest of the catalog at /connectors/, or see how other teams set this up at /use-cases/.

FAQ

Does Jamf have an official MCP server for a Jamf Pro tenant?

No. Jamf's MCP server at [developer.jamf.com/mcp](https://developer.jamf.com/developer-guide/docs/mcp) searches Jamf's API documentation and returns nothing about a live fleet (read October 2026). MCP Hub is a Jamf Concepts open-source project, labeled Beta, described on [its own repository](https://github.com/Jamf-Concepts/mcp-hub) as not an official product, run locally, and carrying write tools. Reaching a Jamf Pro tenant from an AI client therefore means a connector that calls the Jamf Pro API, such as Elaichi's jamf connector.

Can a Jamf API client be limited to read-only access?

Yes. In Jamf Pro, an API role holds privileges and an API client gets the combined privileges of its roles, set under Settings, System, API Roles and Clients ([learn.jamf.com](https://learn.jamf.com/r/en-US/jamf-pro-documentation-current/Creating_an_API_Client), read October 2026). A role built from read privileges only gives the client read-only reach. Leave account creation out of it: creating an account through the Jamf Pro API defaults to ADMINISTRATOR privilege ([developer.jamf.com](https://developer.jamf.com/jamf-pro/reference/post_v1-accounts), read October 2026), so a role that can create accounts can create a full admin.

Does disabling a Jamf API client cut off an AI client straight away?

No. Jamf's documentation states that disabling or deleting an API client does not revoke tokens that are still valid ([learn.jamf.com](https://learn.jamf.com/r/en-US/jamf-pro-documentation-current/Creating_an_API_Client), read October 2026), and token lifetime is set per client. When the connection lives in Elaichi, access ends by removing the member, suspending them, or revoking the share on the connection. In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change.

Which Jamf tools does Elaichi's jamf connector carry?

Elaichi's jamf connector carries 25 tools: reads, plus create, update and delete for accounts, users, mobile devices, mobile device apps and computer inventory, including create_a_jamf_account. It has no tool that sends a wipe, lock or unmanage command. Which of the 25 a given person reaches is set by restrictions on their role in Elaichi, and a restricted tool is withheld from the tool list and cannot be called.

How does a shared Jamf connection stay limited per person?

A Jamf API client's token has the client as its subject, not a person, so every caller through one connection has the same baseline reach into Jamf. A restriction targeted at a role narrows which connectors and tools that role may reach. The change takes effect within about two minutes. In Elaichi, restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything.

What Microsoft Copilot with Salesforce gives you today

Your company runs on Microsoft 365. Sales works in Salesforce, engineering works in Jira, and somebody has asked whether Copilot can cover both. The short answer: Microsoft Copilot with Salesforce and Jira is built for search and grounding over an indexed copy of your data. It is not built for taking live action inside either app. A separate path, using MCP (Model Context Protocol) clients like Claude, ChatGPT or Cursor, covers the live-action case. This post lays out both, with a comparison table and the specific permission and audit behavior each one gives you.

Every Microsoft claim below links the Microsoft Learn page it came from, checked October 2026, and anything marked preview or planned had not shipped then.

The four paths at a glance

The column that matters most is writes: only Copilot Studio and Elaichi write to Salesforce or Jira today.

Microsoft renamed Microsoft 365 Copilot to Microsoft Copilot in August 2026, and Graph connectors are now Copilot connectors. Synced Copilot connectors index Salesforce CRM and Jira Cloud into Microsoft Graph, and Copilot answers from that index (learn.microsoft.com, checked October 2026).

Federated connectors are Microsoft's live-read path. They fetch as the signed-in user at query time, and they are published by Microsoft or approved partners. Salesforce and Jira are not on that list today (learn.microsoft.com, checked October 2026).

The practical line falls here. "Find the renewal notes on the Acme account" is what the indexed path is for. "Create the renewal opportunity and link the Jira epic" is not. No Copilot connector, synced or federated, writes to either app today.

Why permission sync is not the same as live permissions

Synced Copilot connectors do honor the source app's permissions. The point to hold onto is that Microsoft Graph holds a copy, and a copy has a refresh schedule. It is not a window onto Salesforce or Jira, it is a snapshot of one.

Microsoft's own page for the Salesforce CRM connector states three specific behaviors. The default mode honors Salesforce record ownership, sharing rules and role hierarchy. Field-level security is not enforced if an admin opts in to index restricted fields. And permission changes sync only on full crawls, not incrementally (learn.microsoft.com, checked October 2026).

For an IT admin, that becomes two decisions, each made once and reviewed rarely: which fields get indexed, and how often a full crawl runs. A sharing change made in Salesforce on Monday reaches Copilot search only when the next full crawl runs. Check the connector's full-crawl schedule rather than assuming one.

A live call has no such lag, because it has no copy to go stale. Federated connectors and MCP-based tools evaluate permissions at the moment of the call, every time, against the source system directly. That gap is scheduled refresh versus per-call evaluation. It is the reason to pick one path for search and a different one for action, rather than forcing a single connector to do both.

Where do Copilot Studio and Agent 365 fit?

Copilot Studio is Microsoft's action path, and its governance is written per environment and per connector rather than per tool. Copilot Studio agents can call the Premium Salesforce and Jira connectors. Copilot Studio agents can also add MCP servers as tools (learn.microsoft.com, checked October 2026). Each tool runs on end-user credentials by default, with maker-provided credentials as an option an admin can forbid per environment (learn.microsoft.com, checked October 2026).

Governance rides on Power Platform, through two separate mechanisms that don't talk to each other:

• Data loss prevention (DLP) policies sort connectors into Business, Non-business and Blocked. Changes usually apply within an hour, and Microsoft's documented upper bound is 24 hours (learn.microsoft.com, checked October 2026).
• Advanced connector policies are a default-deny allowlist per environment or group. They can block a whole MCP server, but Microsoft states explicitly that per-tool MCP control is not available at this layer (learn.microsoft.com, checked October 2026).

The practical effect: one MCP server may expose both a read tool and a delete tool. The policy layer allows or blocks the server as one unit. A maker can switch off single tools inside one agent. That is a build choice per agent, not an admin policy (learn.microsoft.com, checked October 2026).

Agent 365 has been generally available since 1 May 2026. It is priced at $15 per user per month, or bundled into Microsoft 365 E7 (microsoft.com, checked October 2026). Its tooling gateway for registered MCP servers is in preview. Admins can approve or block servers at runtime today. Microsoft has stated tool-level blocking for those servers is planned but not shipped (learn.microsoft.com, checked October 2026). The side-by-side of Copilot Studio and an MCP gateway goes through that surface in more detail.

How Claude, ChatGPT and Cursor reach Salesforce and Jira live

The second path puts the live call directly in the AI client people already have open. The call does not go through an indexed copy or a separately governed Power Platform environment. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps.

Elaichi serves one organization-wide MCP endpoint, POST https://api.elaichi.ai/mcp, behind OAuth (the sign-in standard that hands an app limited access without a shared password). There are no per-user URLs and no embedded tokens to manage or rotate. An admin adds the one address to each client where the client allows it. Each member then connects and signs in with their own grant. Clients register themselves through dynamic client registration, so there is no client ID or secret to distribute by hand.

Salesforce and Jira are both connectors Elaichi wrote, in its catalog of 600+ connectors. Elaichi authors and serves them, rather than proxying them through a third-party integration platform. A rep connects their own Salesforce account; an engineer connects their own Jira account. Every read and every write then reaches the app as that person, evaluated live by Salesforce or Jira's own permission system. There is no index in between to go stale. A connection shared with a team runs on its owner's credential. Share one only where every person using it should be able to act as that single account.

Tool discovery works differently from a plain, flat server list, which matters once you connect more than one app to the same client. In Elaichi, connected tools are never listed one by one, however few there are. The model finds what it needs and calls it. That keeps a two-app rollout from filling the context window with every available tool on the first message. When a tool somebody expected is missing, the checks run in a fixed order.

One trade-off to state plainly, because it affects what "read-only" means in practice. On Elaichi's consent screen, the single permission "Run your connected tools" covers a connected app's reads and writes alike. Only a tool whose method is a delete also needs the "Delete data and remove access" box, which is never pre-ticked. There is no checkbox for "read-only" at connection time. Read-only access to Salesforce or Jira is something you write as a restriction afterward. It is not something a user selects when they first connect.

Writing restrictions for two apps at once

Restrictions decide which connectors and which individual tools a target may reach. A target is a role or a single user. A rule aimed at a member can only narrow what their role allows, and never replaces or loosens a role rule.

The trap with two apps is the allow rule. An allow rule is the target's entire allowlist, across every connector the target can see, not only the app it names. Write an allow rule to hold Jira to its read tools, and the role loses Salesforce entirely. The fix is a second allow rule naming Salesforce too. Allow rules on the same target union together, so one allow rule per app is the correct pattern once you know this. Holding a single app to reads while leaving every other connector untouched is done differently. Use blocks on that one app's write tools, not an allow rule at all. The per-tool against per-app decision covers the six cases where each shape is the right one.

Two more behaviors to know before you write anything:

• Blocks always beat allows within each layer. A block is never silently overridden by a broader allow.
• 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.

Timing matters when you defend the setup to security or an auditor. A restriction change takes effect within about two minutes. Removal is faster. In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change.

What the audit trail records for both apps

Elaichi writes one entry for each connected-tool call that reaches execution (a call refused earlier writes none). That holds across Salesforce and Jira alike. The recorded connection is the account actually reached, taken from the execution rather than the intent. That answers "which Jira site did it write to" without reconstructing it from context.

Each entry carries the operation and tool name, plus the surface and the OAuth client the call came through. It also carries whether it was approved, the outcome, and an error code. It carries the one path argument that names the object as the target id, and no other argument value. A call made from Claude or Cursor is recorded as a user action, attributed to the person who made it, not to "the assistant."

One more distinction: the error text returned to the caller is derived from the third party's response, Salesforce's or Jira's own error message. The error written to the audit trail is not the same string. Audit records are org-visible and may fan out to a customer's own logging destination. So what is written there is an error code, never derived from Salesforce's or Jira's response.

On plans: the audit trail is on Elaichi's Gold plan. Forwarding it to your own Datadog comes with the Black plan, launching soon.

When the Microsoft path is the right answer

Say your people work in Teams, Outlook and Word, and what they want is to find things. Then the synced Copilot connectors are the complete and correct setup. The index honors source permissions in its default mode, you control which fields are indexed, and there is no second vendor in the call path. Adding anything else buys you nothing for a pure-search use case.

The Microsoft path is also right when the action you want is a Copilot Studio agent running inside Power Platform. Those agents are built and governed by the admins who already run environments and DLP policies. That fits especially well if the write operations you need are already exposed as Premium connectors.

The second path earns its place when three things are true at once. People are working in Claude, ChatGPT or Cursor rather than only in Microsoft surfaces. They need live reads and writes in Salesforce and Jira, as themselves, not through a shared service account. And you want the permission decision written once, per role, down to a single tool. One audit trail then covers both apps, instead of two separate connector logs.

Elaichi has two plans, Gold and Black. Gold is $15 per user per month as the USD list price; pricing shows the local figure. 14-day trial, no credit card to start. Checkout does collect a card, and it sets the paid trial to the remaining days rather than granting a fresh 14, so it is one continuous trial rather than two. Disclosure: Elaichi, the MCP control plane described as the second path above, publishes this blog. The comparison table and Microsoft-side claims are sourced independently from Microsoft's own documentation, linked throughout.

For the wider shape of this category, read what an MCP control plane is. For the team-level walkthroughs behind this post, see giving each rep their own Salesforce access in ChatGPT. There is also rolling Cursor out to an engineering team on Jira. The full connector catalog lists what else is reachable from the same address.

FAQ

Can Microsoft Copilot take actions in Salesforce and Jira?

Not through synced Copilot connectors. Those index Salesforce CRM and Jira Cloud into Microsoft Graph for search and grounding rather than for actions, and Microsoft's live federated connector list does not include Salesforce or Jira today ([learn.microsoft.com](https://learn.microsoft.com/en-us/microsoft-365/copilot/connectors/federated-connectors-overview), checked October 2026). Copilot Studio agents can call the Premium Salesforce and Jira connectors, which is Microsoft's action path and is governed through Power Platform data policies and advanced connector policies.

Do Microsoft Copilot's Salesforce results respect Salesforce permissions?

In the default mode, yes: Microsoft's own page says the Salesforce CRM connector honors record ownership, sharing rules and role hierarchy ([learn.microsoft.com](https://learn.microsoft.com/en-us/microsoft-365/copilot/connectors/salesforce-crm-overview), checked October 2026). Two limits appear on the same page. Field-level security is not enforced if an admin opts in to index restricted fields, and permission changes sync only on full crawls, so a sharing change is reflected when the next full crawl runs.

Do Power Platform policies control individual MCP tools?

No. Advanced connector policies are a default-deny allowlist per environment or group, and Microsoft states that per-tool MCP control is not available there, so a whole MCP server is allowed or blocked as one unit ([learn.microsoft.com](https://learn.microsoft.com/en-us/power-platform/admin/advanced-connector-policies), checked October 2026). Agent 365's tooling gateway for registered MCP servers is in preview, with tool-level blocking planned.

How do you make Jira read-only for a role in Elaichi?

With a restriction, not a consent checkbox. The simplest version is block rules on Jira's write tools for that role, which leaves the role's other apps untouched. An allow rule also works but behaves as the role's whole allowlist across every connector, so the role then needs an allow rule for each other app it uses. The change takes effect within about two minutes.

Which AI clients connect to Elaichi's MCP endpoint?

Claude, ChatGPT, Cursor and any other MCP client. They all point at the same address, POST https://api.elaichi.ai/mcp, and each person signs in over OAuth with their own grant, picking scopes on Elaichi's consent screen. Microsoft's Copilot surfaces are governed by Microsoft's own controls, such as Power Platform policies and the Microsoft 365 admin center.

What n8n AI agents per-user permissions actually mean

n8n AI agents per-user permissions come down to one question. Whose credential does the run hold? n8n's default is a Fixed credential. It is the same account for every execution, manual or scheduled. An agent reaching Salesforce, Jira and Zendesk reaches them as whoever connected those accounts. That holds no matter who started the run. n8n documents this directly. It warns that a Fixed credential can expose one person's access to everyone (docs.n8n.io, checked October 2026).

Elaichi comes at the same question from the other side. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. Every company account is connected once, and the tools those accounts expose are served through one organization-wide MCP endpoint at POST https://api.elaichi.ai/mcp. A client signs in there over OAuth and holds a grant, which is the permission one named person gave one named client. That grant carries the person's role, and their restrictions apply on every call. A restriction is a rule naming which connectors and which individual tools a role or a user may reach.

n8n is not on the list of clients Elaichi names as connecting. Nothing here says it connects.

Fixed credentials versus end-user credentials in n8n

n8n has a per-user credential model, and its documented limits decide whether it helps you here. A Fixed credential, the default, resolves to one account for everyone. End-user credentials resolve per user. But n8n currently lists them as Enterprise, in Preview, not for production, OAuth only, and team projects only (docs.n8n.io, checked October 2026).

The supported triggers matter more than the tier:

The Schedule Trigger runs a published workflow on intervals or cron. It is not on n8n's list of triggers compatible with end-user credentials. So a scheduled agent cannot use n8n's native per-user identity today, as of n8n's current docs. Whether an MCP OAuth2 credential can itself be configured as an end-user credential is not documented either way. Treat that as an open question to ask n8n, not an assumption to design around.

Credential sharing sits underneath all of this. Sharing is available on every n8n Cloud plan and on self-hosted Business and Enterprise, and recipients can use a shared credential without seeing its contents. That's convenient, and it's the shared-account problem in another shape: everyone using a shared credential inherits one identity.

Does n8n meet Elaichi's endpoint requirements?

On paper the two lists line up. Verify it in a throwaway workflow before you build on it. Matching documentation is not the same as a working handshake. When the handshake fails, the OAuth error itself names what to fix.

The endpoint requires MCP over Streamable HTTP with JSON-RPC 2.0, stateless, behind OAuth. Clients register themselves through dynamic client registration (RFC 7591), so there's no client ID or secret to paste in manually. PKCE with S256 is required. It proves the software finishing sign-in is the software that started it. A missing code_challenge_method is not assumed to be S256, and plain is refused outright. A resource value, if the client sends one, must be https://api.elaichi.ai, or the token request fails with invalid_target. Scopes are limited to mcp:read, mcp:write, mcp:destructive, mcp:tools, openid and email.

n8n's MCP Client Tool documents Server Transport as HTTP Streamable (the default) or deprecated SSE. It documents authentication as Bearer Auth, Header Auth, MCP OAuth2, Multiple Headers Auth or None. Its MCP OAuth2 credential uses dynamic client registration by default and takes an optional Resource URL. It negotiates PKCE with S256 where the server supports it (docs.n8n.io, checked October 2026).

Two behaviors to check at first sign-in:

1. Scope narrowing is possible, widening isn't. A client that requests no scope at all gets read-only access. Connected third-party tools additionally require mcp:tools (the "Run your connected tools" checkbox). Without mcp:destructive, any connected tool whose underlying method is a delete is left out of the search index. A call to one by name is still refused, with a message naming the missing scope. Consent can only narrow what a client requested.
2. Rate limiting. The endpoint allows 120 MCP requests per minute per token and returns HTTP 429 with Retry-After: 60 above that. A wide fan-out loop will hit this, for example an agent calling search_tools per item in a batch. Batch or cache tool discovery instead of repeating it per item.

Whose identity does a scheduled run act as?

Through Elaichi, a scheduled run acts as the member whose grant the credential holds. There is no anonymous service identity on the endpoint. The grant is read fresh on every call. So the run gets that member's current reach and nothing wider than it, at the moment the call happens.

Three consequences follow. First, that member's role restrictions apply to the run exactly as if they'd made the call themselves. A role or restriction change reaches the run within about two minutes. Second, each tool call that reaches execution gets an audit entry, run or failed. It names the member, the surface mcp, the OAuth client it came through, the tool, and the connection actually reached. Third, a call from an MCP client is recorded with actor_kind of user, not as an AI actor. Elaichi's AI marker covers only its in-product Agent, not third-party MCP clients calling in.

The client name on an audit entry is marked verified only where its redirect URIs prove it. This currently covers Claude, ChatGPT and Cursor. Any other client shows the name it registered with, marked unverified. Read that as a label for a human reviewer, not as a security control that blocks anything.

Name the trade-off before you ship it. In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change. A SCIM deprovision suspends rather than deletes, with the same effect on grants. A nightly workflow signed in with a departed employee's grant stops running that night, mid-pipeline if it's mid-run. Sometimes that's exactly the behavior you want; sometimes it's an unplanned outage. Decide which, deliberately, before it happens. See offboarding AI access.

Plan for token lifetimes too. An access token lasts an hour, and a refresh token lasts 30 days and rotates on every use. A workflow idle for more than 30 days needs its credential reconnected. Reusing an old refresh token revokes the whole grant, so test what happens when two executions refresh the same credential at once.

Why Tools to Include cannot pick one connected app

It cannot, because connected tools are never advertised one by one. Elaichi lists its own elaichi__ operations individually, plus two generic tools: search_tools and execute_tool. Connected third-party tools (Jira, Zendesk, Salesforce, etc.) are found with search_tools and run with execute_tool, regardless of how many connected tools exist behind them.

n8n's Tools to Include option offers All, Selected or All Except over the tools a server advertises. Against this endpoint, that means picking or excluding execute_tool as a single unit, never Jira's create-issue tool as distinct from Zendesk's. The same ceiling applies to n8n's human-in-the-loop approval for tools. It gates execute_tool as a whole, not the specific operation behind it. execute_tool is also annotated destructive and open-world by design, because its real risk tier isn't knowable before the call resolves. So a client configured to prompt on anything not marked read-only will prompt on every connected call, reads included.

Per-app and per-tool control lives in Elaichi's restriction layer instead, scoped to a role or a user. Blocks beat allows. A restricted tool is withheld from the tool list and cannot be called. Search names it, flagged restricted, with no schema. One caution on allow rules. An allow rule is the target's entire allowlist across every connector. So a role restricted to one app's read tools also needs explicit allow rules naming every other app it uses. Otherwise those calls fail silently from the agent's perspective. Restricting one tool or a whole app walks through the six cases this produces.

What n8n's own logs record, and what they miss

n8n's audit events leave the instance only through Log Streaming, which is Enterprise-tier. Two gaps matter specifically for a scheduled agent. Workflow execution events carry no userId when a Schedule Trigger starts the run. There's no human to attribute it to in n8n's own data model. And n8n's MCP-specific audit events cover its instance-level MCP server, not the MCP Server Trigger used inside workflows (docs.n8n.io, checked October 2026). If a scheduled agent deletes a record, n8n's log alone will not name the human accountable for it. It names only the workflow and the service account it ran under.

Elaichi's audit trail is a different unit of record: per call rather than per workflow execution. Elaichi writes one entry for each connected-tool call that reaches execution (a call refused earlier writes none). The text written to the trail is never derived from the third party's response. So a malformed or hostile error body from, say, Jira cannot inject content into the log pipe. The trail is org-visible, newest-first, and filterable by actor, category, action kind and time. A free read-only Auditor seat lets a compliance reviewer read it without a paid license. It's eventually consistent, so a row may take a moment to appear after the call completes. Forwarding it to your own Datadog comes with the Black plan, launching soon. For what a record needs to contain to actually survive a compliance review, see what an AI agent audit log must capture.

Who should sign the workflow credential in

The person who owns the workflow, using their own grant, under their own role, not a shared admin account. That keeps one accountable name on every run. It also caps the blast radius at one job's worth of access, rather than an administrator's entire reach. Every member holds exactly one role, so a workflow inherits its owner's whole role. If that is wider than the job, have the credential signed in by someone whose role fits the job. One role each covers why a role should be a complete, narrow persona rather than a reused one. Use n8n's end-user credentials only where n8n's documented triggers actually support them. As of this writing, that excludes the Schedule Trigger.

There's a case where none of this is worth doing. Say a workflow touches exactly one app, and n8n already has a native node for it. If a single service account on that one app is an acceptable risk for your org, a control plane buys you an audit trail and restrictions you don't yet need. When you don't need an MCP gateway is the honest version of that decision. Read it before adding infrastructure you won't use.

If you do need per-user control across multiple apps, the shape is simple. One endpoint, one grant per person, no shared bot identity, one role per job. The same endpoint is what people point Claude and ChatGPT at. Elaichi serves the 600+ connectors in its connector catalog directly, most of them its own and the rest vendors' MCP servers it governs. So restrictions are defined once at the gateway, rather than re-implemented per downstream server or per workflow tool.

FAQ

Does n8n connect to Elaichi's MCP endpoint?

n8n is not on the list of clients Elaichi names as connecting, so check sign-in yourself before relying on it. On paper the requirements match: Elaichi needs MCP over Streamable HTTP with OAuth, dynamic client registration and PKCE S256, and n8n's MCP Client Tool documents HTTP Streamable transport and an MCP OAuth2 credential that uses dynamic client registration and picks PKCE S256 where the server supports it ([docs.n8n.io](https://docs.n8n.io/integrations/builtin/credentials/mcp/), checked October 2026). Build a throwaway workflow with a manual trigger and complete sign-in once before anything else.

Can an n8n scheduled workflow run as the person who triggered it?

No. n8n's end-user credentials, which resolve per user, are Enterprise, in Preview, OAuth only and team projects only, and the Schedule Trigger is not among their supported triggers ([docs.n8n.io](https://docs.n8n.io/administer/manage-credentials/end-user-credentials), checked October 2026). Through Elaichi, a workflow's OAuth credential holds one member's grant, so every run, scheduled ones included, acts as that member, under that member's role and restrictions.

What does Elaichi record when an MCP client calls a tool?

Elaichi writes one entry for each connected-tool call that reaches execution (a call refused earlier writes none). It names the member, the surface the call came through, the OAuth client, the tool, the connection actually reached, whether the call was approved, the outcome and an error code. It carries the one path argument that names the object as the target id, and no other argument value. The client's name is marked verified only where its redirect URIs prove it, which covers Claude, ChatGPT and Cursor.

Can I make one connected app read-only for an AI agent?

Yes, with a restriction in Elaichi, not with an OAuth consent checkbox. For a connected app's tools, the "Run your connected tools" scope covers reads and writes alike, and only a tool whose method is a delete needs the destructive scope on top. Read-only access is written as an allow rule naming that app's read tools, or as blocks on its write tools. An allow rule becomes the target's whole allowlist across every connector, so the role needs allow rules for its other apps too.

What happens to a workflow when the credential owner leaves?

It stops on the next call. In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change, and the grant's revoked state is re-read from the organization store on every call with no cache. A nightly workflow signed in with that person's grant fails the next time it runs. Pick an owner who is staying, or plan the handover before the leave date.

Which Agents SDK class fits a remote MCP endpoint?

A remote server behind OAuth fits MCPServerStreamableHttp or HostedMCPTool. Stdio is for a server running as a local child process, which a hosted endpoint is not.

The situation: you have an agent written with the OpenAI Agents SDK, it needs to read opportunities in Salesforce and post a digest to Slack, and it has to act as a named person with a record of what it did. OpenAI Agents SDK governed access comes down to three decisions. Which transport class, who holds the OAuth grant, and where the per-tool rules live.

The OpenAI Agents SDK documents four MCP shapes:

Source: the Agents SDK MCP guide (openai.github.io, checked October 2026). MCP is the Model Context Protocol, the wire format an AI client uses to find and call tools on a server (the specification).

Elaichi is a remote server. It serves standard MCP over Streamable HTTP, JSON-RPC 2.0, stateless, behind OAuth, at one organization-wide address: POST https://api.elaichi.ai/mcp. There are no per-toolbox URLs and no embedded tokens. With MCPServerStreamableHttp your own process makes the calls. With HostedMCPTool, or the Responses API mcp tool, OpenAI's infrastructure calls the server instead.

Disclosure: Elaichi publishes this blog.

One caveat before any code. Elaichi names Claude, ChatGPT, Cursor and any other MCP client as the clients that connect. Neither the Agents SDK nor the Responses API mcp tool is named there specifically. What follows sets Elaichi's documented requirements beside OpenAI's documented options. Prove the pairing in a throwaway organization first.

Copy the address exactly. POST https://api.elaichi.ai/mcp answers 401 with the resource_metadata challenge that starts sign-in. With a trailing slash it answers 404, and on app.elaichi.ai/mcp it answers 405 (probed October 2026). Neither carries the challenge, so neither starts sign-in.

OpenAI Agents SDK governed access starts with one person's grant

Your program holds a real person's OAuth grant, not a service key. OAuth is the sign-in handshake that issues a scoped token, and the grant is the standing permission a person approved for one named client.

Elaichi takes OAuth only. A client registers itself through dynamic client registration (RFC 7591) at /oauth/register, with PKCE S256 required, then sends the person to Elaichi's consent screen in a browser. There is no client ID, secret or header to paste.

The Python SDK will not run that flow. The Python Agents SDK takes a token through headers or an httpx.Auth handler in params["auth"]. The JS SDK accepts an authProvider, the MCP TypeScript SDK's OAuthClientProvider (openai.github.io, checked October 2026). The Responses API mcp tool takes an authorization value that OpenAI says it never stores and sends on every request (developers.openai.com, checked October 2026). The Python SDK and the Responses API tool assume you already have a token; the JS SDK's authProvider can run the browser leg through the MCP TypeScript SDK.

So you build one component: a browser sign-in that captures the grant, plus storage and a refresher. Minimal shape in Python:

from agents.mcp import MCPServerStreamableHttp
import httpx

class ElaichiAuth(httpx.Auth):
    """Wraps a token store that owns refresh, rotation, and the single-writer lock."""
    def __init__(self, token_store):
        self.token_store = token_store

    def auth_flow(self, request):
        token = self.token_store.get_access_token()  # refreshes if < ~60s to expiry
        request.headers["Authorization"] = f"Bearer {token}"
        yield request

server = MCPServerStreamableHttp(
    params={
        "url": "https://api.elaichi.ai/mcp",
        "auth": ElaichiAuth(token_store),
    }
)

The snippet leaves out the browser consent leg, which runs once per person at onboarding, not on every agent invocation. The token_store is the part worth building carefully. The lifetimes and locking rule below explain why.

Four lifetimes shape the token store. The consent request lasts 30 minutes and works once. An access token lasts 1 hour. A refresh token lasts 30 days and rotates on every use: each refresh call returns a new refresh token and invalidates the old one. Reusing an old refresh token or an authorization code revokes the whole grant, so serialize refreshes through a single writer (a DB advisory lock or a single refresher process). This matters concretely in multi-process deployments: if two workers both see a token expiring and both call refresh concurrently, the second call's refresh token is already dead by the time it lands, and the whole grant goes with it. One writer, one in-flight refresh at a time, is not optional. The grant itself has no expiry, but 30 idle days means somebody signs in again.

Four details trip OAuth libraries here:

• Scopes come only from mcp:read, mcp:write, mcp:destructive, mcp:tools, openid and email. A library that adds offline_access gets invalid_scope.
• A resource parameter, if sent, must be on https://api.elaichi.ai, or invalid_target.
• The redirect_uri must match registration exactly. A loopback address may change port only, never host, so 127.0.0.1 never matches localhost.
• Rate limits are 30 OAuth requests a minute and 120 MCP requests a minute per token, answered with 429 and Retry-After: 60.

Sign-in needs a browser. A program running headless in CI cannot complete it. That is a stop, not a configuration problem.

A revoked or expired grant answers 401 invalid_token on the next request, and a refresh answers invalid_grant. Both are fixed by sending the person back through sign-in. The two credential shapes are compared in OAuth or API keys for AI agents.

If your organization runs both patterns at once, one team wiring MCPServerStreamableHttp directly and another going through HostedMCPTool via the Responses API, both see the same tools/list output for the same grant, because the tool list is a property of the grant's role and scopes, not of which SDK class is calling. There's no split-brain case here: change the role, both callers see it change within about two minutes.

Why per-tool control over Salesforce and Slack is written in Elaichi

Client-side filters cannot tell one Salesforce tool from another. Connected tools are never listed in tools/list, however few there are. Elaichi's list carries its own elaichi__ operations plus two meta-tools: the model finds a connected tool with search_tools and runs it with execute_tool.

That bounds what the SDK's controls can do. tool_filter=create_static_tool_filter(...), the Responses API's allowed_tools and require_approval all act on advertised names. Against Elaichi they can allow or gate execute_tool as a whole. Allow it and every connected tool the grant reaches is callable. Block it and the agent reaches no connected app at all. execute_tool is annotated destructive and open-world on purpose, because its real tier is not knowable before the call.

Client-side approval is also inconsistent across OpenAI's own surfaces. The JS hostedMcpTool defaults requireApproval to 'never' (openai.github.io, checked October 2026), while the Responses API mcp tool requires approval by default (developers.openai.com, checked October 2026). A control whose default flips between surfaces is a poor home for a Salesforce write policy.

Write the policy in Elaichi, as a restriction on the role the agent's person holds. 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.

For the Salesforce and Slack pair, two shapes do most of the work:

• Blocks on one app's write tools hold that app to reads and leave the person's other apps untouched.
• An allow rule is stricter and wider. It becomes the role's entire allowlist across every connector, so a role allowed a handful of Salesforce read tools also needs allow rules naming its other apps, Slack included, or it loses them.

A digest-posting agent usually wants the first shape twice. Block the Salesforce write tools so the agent reads opportunities and changes nothing, and block Slack's destructive tools so it posts without deleting. A restricted tool is withheld from tools/list and cannot be called. Search names it only as restricted, with no schema. A role or restriction change takes effect within about two minutes, which matters while you are testing. Which shape fits which case is worked through in restricting one tool or a whole app.

One scope note surprises people. For a connected app's tools, mcp:tools runs reads and writes alike, and only a tool whose method is a delete costs mcp:destructive. Leaving "Create and change data" unticked on the consent screen does not make Slack read-only. Read-only access to a connected app is a restriction, never a consent checkbox.

Every call acts as the member whose grant the program holds. The audit entry records the surface as mcp, names the OAuth client, and names the connection actually reached, so "which Slack workspace did it post to" has an answer. A client that registers itself shows the name it registered with, marked unverified; only clients whose redirect URIs prove them, Claude, ChatGPT and Cursor among them, are marked verified. The entry carries the one path argument that names the object as the target id, and no other argument value. Offboarding follows the same model. In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change.

What SDK tracing records, and OpenAI's warning about aggregators

Agents SDK tracing is on by default and includes tool inputs and outputs. It goes to OpenAI's Traces dashboard, covers MCP tool listing and calls, and is governed by trace_include_sensitive_data (openai.github.io, checked October 2026). If Salesforce field values should not land in a third party's dashboard, decide that before the first run and reroute with add_trace_processor() or set_trace_processors().

OpenAI also says it does not verify remote MCP servers, that a malicious one can exfiltrate what is in the model's context, and that "aggregators" deserve extra due diligence (developers.openai.com, checked October 2026). That warning points at Elaichi too, and deserves a direct answer rather than a reassurance.

What holds on Elaichi's endpoint: Elaichi authors, maintains and serves most of its connectors from its own infrastructure, and governs vendors' own MCP servers for the rest. Connector credentials sit in a separate credential service, encrypted at rest with AES-256-GCM. Role checks apply per operation, a tool classified forbidden is reachable under no scope, results are scrubbed for secret-shaped values as a backstop, OAuth scopes bound the grant, and every call that reaches execution is logged. The detail is on the security page.

What does not hold: the prompt-injection write gate in the Elaichi Agent does not apply to POST /mcp, and cannot, because an MCP server never sees a user prompt. Do not count the endpoint as prompt-injection protection. The rest of that surface is in MCP security risks and how to reduce them.

When the app's own MCP server is the better answer

One agent, one app, one vendor: use the vendor's own server. Salesforce hosted MCP servers are generally available for Enterprise Edition orgs and above, where "every transaction runs as the authenticated user" (developer.salesforce.com, checked October 2026). Slack hosts one at https://mcp.slack.com/mcp, where workspace admins approve MCP clients and each client must be backed by a registered Slack app (docs.slack.dev, checked October 2026). Both run under the app's own permission model and add no second vendor. If your agent only ever touches one app, this is the simpler, lower-trust-surface choice, and we'd say so even though we sell the alternative.

The case for a single endpoint like Elaichi's starts when the agent spans several apps and more are coming. One address, one grant per person, restrictions written once against a role, and one audit trail across every app. That consolidation is the actual trade: fewer integration points per agent, at the cost of adding Elaichi itself as a party that touches every credential. Removing someone from Elaichi ends their access through Elaichi and nothing more; their Salesforce and Slack accounts are still deprovisioned separately, where they live. Elaichi does not replace app-level offboarding, it adds a second place that also needs to be checked.

If what you actually need is a budget cap per model or a rate limit on inference, that is a different layer, and a proxy in front of the model is the right shape. Elaichi governs tool execution, not token spend. The 600+ connectors behind the endpoint are listed in the connector catalog, including Salesforce and Slack.

A first run you can check in an afternoon

Start in a throwaway organization, with a member whose role you are willing to break. Sign in once through a browser, store the grant, point MCPServerStreamableHttp at https://api.elaichi.ai/mcp, and call tools/list.

Seeing search_tools and execute_tool means the grant reaches connected tools. Seeing only elaichi__ operations means the grant lacks mcp:tools or no connected tool is reachable yet, for example a connection still pending or needing reauthorization. Reconnecting with "Run your connected tools" ticked fixes the first case. An empty list usually means the role lacks tool:execute, which no amount of re-authorizing grants. The rest of the ladder is in why MCP tools do not show up.

Then prove the governance leg. Block a Salesforce write tool on that role, give the change about two minutes, and search for the tool. It should now show only as restricted, with no schema. Then run an allowed read and open the audit trail. The entry should name the member, the OAuth client and the connection reached. That record is the evidence a reviewer asks for later.

For the wider shape, read what an MCP control plane is. For the same problem from the human end, where a rep uses their own Salesforce access inside a chat client, see each rep's own Salesforce access in ChatGPT. Team rollouts sit on use cases, and Gold's USD list price is on pricing.

FAQ

Does the OpenAI Agents SDK connect to Elaichi's MCP endpoint?

Elaichi names Claude, ChatGPT, Cursor and any other MCP client as the clients that connect, and the OpenAI Agents SDK is not named specifically. Elaichi's endpoint is standard MCP over Streamable HTTP at POST https://api.elaichi.ai/mcp, behind OAuth with dynamic client registration and PKCE S256, so the SDK's MCPServerStreamableHttp class is the shape that matches. Test the pairing in a throwaway organization before building on it.

How does a Python Agents SDK program get an Elaichi access token?

The Python OpenAI Agents SDK runs no OAuth flow of its own; you pass a token through headers or an httpx.Auth handler in params["auth"]. Elaichi issues tokens only through OAuth with dynamic client registration, PKCE S256 and a person signing in from a browser, so the program needs a component that captures that person's grant and refreshes it. A headless CI job with no browser access cannot complete the sign-in.

Can require_approval or allowed_tools limit which Salesforce tools an agent calls through Elaichi?

No. Elaichi never lists connected tools in tools/list; the model finds them with search_tools and runs them with execute_tool. Client-side filters such as tool_filter, allowed_tools and require_approval can only pick or gate execute_tool as a whole, which covers every connected app at once. Per-tool control over Salesforce or Slack is a restriction written in Elaichi against the person's role or the person, and it takes effect within about two minutes.

How long do Elaichi's OAuth tokens last for a long-running agent?

An access token lasts 1 hour. A refresh token lasts 30 days and rotates on every use, and reusing an old refresh token or an authorization code revokes the whole grant. The grant itself has no expiry, so a single serialized refresher keeps a long-running program signed in. After 30 idle days, the person signs in again.

Does Agents SDK tracing record what an agent read from Salesforce?

Yes, by default. OpenAI's Agents SDK tracing is on by default, sends traces to OpenAI's Traces dashboard, covers MCP tool listing and calls, and includes tool inputs and outputs unless trace_include_sensitive_data is turned off ([openai.github.io](https://openai.github.io/openai-agents-python/tracing/), checked October 2026). Traces can be rerouted with add_trace_processor() or set_trace_processors().

Can admins restrict ChatGPT Enterprise connectors?

Yes. Somebody in finance asks for Salesforce inside ChatGPT, and you want the boundary set before the first query runs.

Scope note before the detail: the OpenAI sections below are sourced to a specific help.openai.com article and a check date. Re-check a menu path on the live page before you write a runbook. The sections after "Where ChatGPT's per-action switches stop" describe Elaichi, a third-party MCP control plane, and how it extends those controls below the per-app level.

You can restrict ChatGPT Enterprise connectors app by app, and on Enterprise and Edu group by group. As of this check, apps are managed at Admin Console, then the workspace, then Plugins. The older page is Workspace settings, then Apps. It is also reached from Plugins through Manage Legacy Apps (help.openai.com, admin controls for plugins and apps, checked October 2026).

Plan matters more than anything else here:

The workspace-wide switch is the one control that exists on every paid team plan. Business workspaces start with apps on. New Enterprise and Edu workspaces start with a selected default set on. If you're auditing an existing workspace, don't assume the default. Read the current state directly.

Giving different groups different apps

Per-group app assignment is Enterprise and Edu only; it does not exist on Business at any price point. The path is Permissions & roles, then Custom roles, then Plugins & connected data, then Select. Roles are assigned to manual groups or groups synced via SCIM.

SCIM (RFC 7644) is the standard that syncs users and groups from your identity provider (Okta, Entra ID, etc.) into ChatGPT. So group membership in ChatGPT tracks group membership in your IdP, instead of being maintained by hand.

Two resolution rules matter in practice:

• Roles are additive. If any role a person holds grants a permission, they have it. There is no "most restrictive role wins": a second role can only add access, never subtract it.
• Propagation is not instant. Changes take up to 5 minutes to apply (help.openai.com, role-based access control in ChatGPT, checked October 2026). If you're testing a permission change, wait before concluding it failed.

On Business there is no group grain at all. Switching an app on switches it on for every member of the workspace. If your plan is Business and finance needs an app that support should not reach, that split cannot be built in the ChatGPT admin console. It has to live in an identity layer or a separate tool below the app.

Read actions, write actions and when ChatGPT asks first

Separate controls govern what an app may do and when the person is asked to approve it. Keep them distinct when you configure a workspace.

Business has had the Actions control since a release dated 20 April 2026 (help.openai.com, admin controls for plugins and apps, checked October 2026).

On Plugin permissions: members of a managed workspace never get a lasting "Always allow". No current OpenAI page documents what the default setting is for a newly enabled app. Check your own workspace rather than assuming "Always ask" or any other state (help.openai.com, managing app permissions, checked October 2026).

These controls only police what ChatGPT asks about. The destination system's own OAuth 2.0 scopes are a separate, independent check. OAuth is the browser sign-in flow that issues a scoped, revocable token instead of handing over a password. Salesforce's or Jira's own scope grants still apply underneath whatever ChatGPT allows.

Who may publish a custom MCP app

Only Admins and Owners can publish a custom app, on every plan tier that supports custom apps at all.

MCP (Model Context Protocol) is the open standard an AI client uses to discover a server's tools and call them. On Business, only admins and owners can use developer mode. On Enterprise and Edu, role-based access control can let regular members build and test drafts. The publish step, which sets the app's enabled actions and, on Enterprise and Edu, which groups receive it, stays with Admins and Owners.

Two behaviors worth planning around:

• Snapshots, not live sync. A published app runs on a frozen snapshot of its tool list. If the connector adds a tool later, it arrives disabled by default until an admin manually refreshes the app.
• No verification, no escalation path. OpenAI does not review or verify custom MCP apps before publish. There is no documented member-to-admin request flow for "I need this app published" (help.openai.com, developer mode and MCP apps, checked October 2026). Whatever approval process you want has to be built outside ChatGPT. It lives in Slack, a ticketing system, or the approval step in front of the tool call itself.

Where ChatGPT's per-action switches stop

This is the architectural limit that the controls above cannot see past. It applies to a server that exposes a search tool and an execute tool instead of listing every connected tool, as Elaichi does.

To ChatGPT, Elaichi is one custom app whose listed tools are search_tools, execute_tool and Elaichi's own operations. The actual connected tools, a Salesforce record update or a Jira issue create, are never listed in tools/list, no matter how few of them exist. The model finds a connected tool at runtime by calling search_tools, then invokes it by calling execute_tool with the tool's identifier as an argument.

Consequence: ChatGPT's per-app Actions toggle (read/write) and its Plugin permissions prompt can only act on execute_tool as a single undifferentiated unit. They cannot distinguish a Salesforce read from a Jira write, because both are the same tool call from ChatGPT's point of view. Only the arguments differ, and ChatGPT's admin console does not inspect arguments. Elaichi annotates execute_tool as destructive and open-world precisely because its real risk tier can't be known until the call resolves.

The practical implication: setting the aggregator app to "read actions only" in ChatGPT does not make the connectors behind it read-only. That setting acts on execute_tool, which runs every connected tool, reads included, so it cannot single out the writes behind it. If you need read/write or connector-level granularity, it has to be enforced inside the aggregator, before the call leaves it. That is what the rest of this post describes.

Writing per-app and per-tool rules in Elaichi

From here on, this describes Elaichi specifically, not an OpenAI feature.

Elaichi enforces per-app and per-tool rules as restrictions, written server-side, independent of ChatGPT's own permission model. A restriction names 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.

Resolution logic:

1. A member is governed by two layers at once. One is their role's rules. The other is any rule aimed at them personally. A tool is reachable only when both layers admit it, so a personal rule can only narrow what the role allows. It never replaces or loosens a role rule.
2. Within each layer, allow rules union and block rules union.
3. Blocks always beat allows, regardless of which rule was written more recently or more specifically.
4. An allow rule naming nothing denies everything. 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 an easy rule to write by accident when a restriction is left half-filled.
5. An allow rule naming a connector as a whole grants every tool on that connector, even if specific tool entries are also listed. The tool entries in that case add nothing beyond what the connector-level grant already covers.

Matching detail that affects correctness: blocks match on the tool's name or on the operation pinned against the catalog. Allows match the pinned operation only. The reason is that a tool's advertised display name can be edited by whoever maintains the connector's documentation. Matching allows against a name would let a documentation edit silently widen access. A restricted tool is withheld from the tool list and cannot be called. Search names it, flagged restricted, with no schema. A restriction change takes effect within about two minutes.

Elaichi serves 600+ connectors, most of them authored on its own infrastructure, on one organization-wide endpoint, https://api.elaichi.ai/mcp. Because the restriction is enforced at that endpoint rather than inside any one client, a restriction written once for a role applies identically. That is true whether the member is using Claude, ChatGPT, Cursor or any other MCP client. Each client sees the same filtered tool list and the same enforcement, because the filtering happens before the response reaches the client.

Each member holds exactly one role, which is why roles are built as complete personas rather than stacked fragments. The walkthrough of when to block a tool and when to block the app covers how to choose the grain for a given rule.

Failure mode to plan for: because enforcement happens at api.elaichi.ai, that endpoint is a dependency for every connector call from every client. If it's unreachable, calls fail closed: ChatGPT's execute_tool call returns an error rather than falling back to a direct, unfiltered connection to Salesforce or Jira. This also means every connector call takes one additional network hop versus a native, unmediated connector. Whether that overhead matters depends on your latency budget. It is worth measuring against your own traffic rather than taking on faith.

Where each layer's record lives

The two layers, ChatGPT's own logs and Elaichi's audit log, keep separate records, and neither is a superset of the other.

ChatGPT's Compliance Logs Platform is Enterprise and Edu only (Business has no equivalent). APP_LOG events carry the user's id and email, the app identifier (app_type includes MCP for custom apps), the conversation id, and the request/response payload. Relevant admin events include APP_SET_ENABLED_ACTIONS, ROLE_SET_PLUGIN_PERMISSIONS, and PLUGIN_USE_BLOCKED. Files are retained 30 days. No field documents the specific tool name that was called inside an aggregator app (OpenAI, compliance API reference, checked October 2026). That is precisely the gap that makes the per-action limit concrete: ChatGPT's own logs cannot tell you which connector or tool ran inside execute_tool.

Elaichi's audit log is the append-only record of what a tool-call entry has to capture at the tool level. Elaichi writes one entry for each connected-tool call that reaches execution (a call refused earlier writes none). The entry holds the one path argument that names the object, as the target id, and no other argument: no argument names, no count, and no other values. Each entry records the client surface and the OAuth client the call arrived through. Claude, ChatGPT, and Cursor are distinguishable from each other by their registered redirect URIs. Each entry also states how the call was approved, which over MCP corresponds to the scope the client was granted at consent. The log is eventually consistent, so a row can take a short time to appear after the call completes. Don't treat an immediate query as authoritative.

The order to set this up

This sequence is Elaichi-specific. Write the restrictions before anyone connects. A person who signs in first can connect any catalog app their role allows. A restriction added afterward does not retroactively apply to calls already made.

1. Decide the roles. One role per member, each a complete persona.
2. Write a restriction per role in Elaichi: allow rules for the approved connectors, blocks for the specific tools nobody in that role should reach.
3. Create the custom app in ChatGPT under Workspace settings, then Apps, then Create. Paste https://api.elaichi.ai/mcp exactly, with no trailing slash, then Scan Tools and complete the OAuth prompt.
4. Publish the app, setting its enabled actions and, on Enterprise and Edu, the groups it's assigned to.
5. Set Plugin permissions to control how often ChatGPT prompts before a call.
6. Have each member connect and sign in. They choose scopes on Elaichi's own consent screen at connection time, and that per-person grant is independent of the role-level restriction and cannot exceed it.
7. Read the first week of calls in Elaichi's audit trail, filtered to the ChatGPT client. Confirm the restrictions behaved as written before you treat the rollout as done.

The client-side detail of step 3 and step 6 is covered in the ChatGPT connection walkthrough.

When the native controls are enough

If ChatGPT is the only AI client your organization will run, stop at the native controls described above. That holds when every app your teams need is already in OpenAI's own catalog with the granularity you need. The workspace switches, custom roles, and action controls cost nothing beyond your existing ChatGPT plan. Adding another layer for a problem you don't have is pure overhead.

A control plane like Elaichi earns its place under two conditions, not before. The first: a second MCP client enters the picture (Claude, Cursor, an internal agent), and you need the same restriction to apply in both without maintaining it twice. The second: the access rule you need is finer than "this app, on or off". That means a specific tool inside a connector rather than the whole connector. The Claude side of that two-client case is set out in approving apps for Claude across a company.

The case against adding a layer prematurely is set out in when a gateway is premature. The trade-off against OpenAI's built-in apps is in native connectors versus one endpoint. For the architecture underneath all of this, see what an MCP control plane is. To check whether your teams' apps are covered, see the connector catalog or team use cases.

FAQ

Can a ChatGPT Business workspace give different teams different apps?

No. On ChatGPT Business, turning an app on turns it on for the whole workspace. Giving different groups different apps runs through custom roles under Permissions & roles, then Custom roles, then Plugins & connected data, and that is available on Enterprise and Edu only. Roles are assigned to manual or SCIM groups, roles add up, and changes take up to 5 minutes (help.openai.com, checked October 2026).

Does turning off write actions on a custom MCP app make the connected apps read-only?

No. For a governed MCP endpoint such as Elaichi, ChatGPT sees one custom app whose tools are search_tools, execute_tool and the control-plane operations. Connected tools are never listed individually, so the per-action switches cannot separate a read from a write inside Salesforce or Jira. Read-only access to a connected app is written in Elaichi as a restriction, typically an allow rule naming that connector's read tools. Once a role holds an allow rule, every connector no allow rule names is denied for that role, so the role also needs an allow rule for each other app it uses, or blocks on this app's write tools instead.

How quickly does a restriction change take effect in Elaichi?

Within about two minutes. Role membership and restriction changes resolve through a 60-second cache plus edge propagation on every surface, including MCP, the console and the REST API. A few changes are faster. In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change.

Which log shows that an AI agent wrote to a specific account?

Elaichi's audit log, which writes one entry for each connected-tool call that reaches execution (a call refused earlier writes none). It also records the one path argument that names the object, as the target id, and no other argument, plus the surface, the OAuth client the call came through, and how the call was approved. ChatGPT's own Compliance Logs Platform, on Enterprise and Edu, records APP_LOG events with the user, the app and the conversation, and documents no tool-name field.

Who can publish a custom MCP app in ChatGPT Enterprise?

Only Admins and Owners. On Enterprise and Edu, role-based access control can let members build drafts, but the publish step stays with Admins and Owners, and it sets the app's actions and which groups receive it. A published app runs on a frozen snapshot of its tools, so new actions arrive disabled until an admin refreshes them, and OpenAI does not verify custom apps (help.openai.com, checked October 2026).

Why scheduled AI agent tasks need controls set before the run

A scheduled task fires at 6am with nobody at the keyboard. That single fact decides the rest. Scheduled AI agent tasks are made safe by what you configure in advance. The approval prompt that would normally catch a bad call has no one there to answer it.

Most teams reach for approval first. Right instinct, wrong layer. Over Elaichi's MCP endpoint, the OAuth grant is the approval. MCP is the protocol an AI client uses to find and call tools. OAuth is the sign-in that issues a client a token on a person's behalf. The person ticked scopes on Elaichi's consent screen for that named client, and that was the human decision. There is no per-call prompt on the endpoint, and any approval card an MCP client renders from Elaichi's results is display only. This applies specifically to the OAuth-gated pattern described here. Some MCP servers authenticate with static API keys or mTLS instead. That removes the consent-screen step entirely and pushes all authorization decisions onto whatever issued the key. If your stack uses that pattern, the "grant as approval" argument below doesn't transfer; you need an equivalent decision made at key-issuance time. The layers of approval sets out who decides what, and where.

One limit belongs in the open. The endpoint does not inspect prompts and cannot, because an MCP server never sees the user's prompt. It only sees the tool call and arguments the client's model chose to send. The prompt-injection write gate in the Elaichi Agent window does not apply to POST /mcp. What does hold on the endpoint: permissions per operation, the forbidden classification, output redaction, OAuth scope limits and an audit row for each call that reaches execution. None of these five inspect the natural-language prompt that produced the call; all five constrain or record the call itself.

What do scheduled tasks in Claude and ChatGPT do today?

Three surfaces, three different answers, each read on the vendor's own page.

A pause is the safe outcome and also an unfinished job, the trade-off to weigh before scheduling anything that writes. Claude Code's shape works unattended precisely because it skips that trade-off. That puts the whole weight of the control on what the owning user can reach: if the user's account can delete a repo, the routine can too. Claude Cowork's undocumented identity is not a minor omission. "Whose credential did this action run under" is the first question any access review asks, and a page that doesn't answer it means you're assuming, not verifying. Treat it as an open question to put to Anthropic rather than a gap to fill in with guesswork.

The practical reading: an unattended run may stop and wait, may write without asking, or may act as an identity nobody can name. Pick your controls accordingly, and re-verify this table against the vendor pages periodically. Scheduled-task behavior for all three products is young enough (research preview, in one case) that it is likely to change faster than most API surfaces.

Whose account does a scheduled run act as through Elaichi?

It acts as the member whose grant the client holds. Nothing else.

Every client points at one organization-wide address, POST https://api.elaichi.ai/mcp, and each member signs in there once with their own OAuth grant. A scheduled task calls through whichever grant its client is holding, so the call carries that member's role, that member's restrictions and that member's connections. There is no shared service account in the middle unless somebody deliberately shares a connection. A shared connection runs on its owner's credential, so the app sees the owner's account. The reasoning behind giving an agent an employee's own permissions is the same reasoning that makes a scheduled run attributable.

The record says the same thing afterward. Elaichi writes one entry for each connected-tool call that reaches execution (a call refused earlier writes none), and each entry names the member, not a generic "agent" identity. The entry also records the surface, mcp, and the OAuth client the call came through. A client's name is marked verified only when its redirect URIs prove it, which covers Claude, ChatGPT and Cursor. A client signing in through a loopback address, such as Claude Code, shows the name it registered with, marked unverified. The approval line on an MCP entry reads "Allowed by the access was granted." That describes the OAuth grant as the authorizing event, not a per-call human decision. What an AI agent audit log must capture covers the rest of the record shape.

Which controls hold when nobody is present

Three mechanisms, all set before the schedule fires: restrictions on the role, frozen parameters on a toolbox entry, and a grant scoped to chosen toolboxes. These are Elaichi-specific constructs. The general principle (constrain reachable tools, pin dangerous arguments, scope the credential) is portable to any MCP control plane. The specific nouns below are not standard MCP or OAuth terms.

Restrictions on the role. A restriction decides 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. Within each layer, allow rules union, block rules union, and blocks always beat allows. So a single block on a destructive tool cannot be overridden by any allow rule in the same role, and the two rule types match a tool by different things. For a scheduled role, blocks on an app's destructive tools are the simplest shape that does not break the rest. An allow rule behaves differently and catches people out. It becomes the role's whole allowlist across every connector, so every other app that role needs takes its own allow rule, naming whole connectors where that is fine. An allow rule naming nothing denies everything. Restrictions are enforced at every place a member can reach a connector or tool, including listing, connecting, advertising, executing, the final outbound-request check and opening a stored tool file. A restricted tool is withheld from the tool list and cannot be called. Search names it, flagged restricted, with no schema. That is a stronger guarantee than "the model is instructed not to call it," since the tool cannot be called at all. A restriction change takes effect within about two minutes, which matters when you're trying to close access in a hurry.

Frozen parameters on a toolbox entry. A freeze is a per-entry map over a tool's arguments: a destination folder, a payee, a channel. Frozen keys are stripped from the advertised schema, so the model never sees them as fillable fields. Frozen values are merged over caller arguments at execution, so a model that guesses the key name and passes it anyway cannot un-freeze it. The precedence order is: entry defaults, then caller arguments, then frozen values. Frozen values win last. The caveat matters more than the mechanism: a freeze holds only on the path that runs through the entry. If the owner shares the connection itself with the team, the frozen path is bypassed. Anyone holding use on the connection can call the tool unfrozen. The correct setup: the owner keeps the connection unshared with the team. The owner then pins it into a toolbox entry with frozen values, and shares the toolbox at use. Do not try to close the other path with a restriction. A block on the tool withholds the frozen entry too, since restrictions apply before entry-level logic runs. Locking a tool argument the way a wire transfer locks a payee walks through the setup.

A grant scoped to chosen toolboxes. On Elaichi's consent screen, with "Run your connected tools" ticked, a second step asks which toolboxes. The choice is All my tools, or Only the ones I pick, up to 50. For a client that will run unattended, pick. A grant scoped to chosen toolboxes reaches only their tools. If none of them resolves any more there are no connected tools at all, never a silent fallback to everything else the member can reach.

One correction worth carrying into the setup. Leaving "Create and change data" unticked does not make a connected app read-only. For a connected app's tools, "Run your connected tools" covers reads and writes alike. Only a tool whose method is a delete also costs "Delete data and remove access." Read-only access to a connected app is a restriction, not a consent checkbox. Least privilege without breaking automation covers how far to take that before the task stalls.

What stops a scheduled task, and how fast?

Some changes stop a scheduled run on its very next call, and some take longer. The difference matters when you are closing access in a hurry. Assuming the wrong latency during an incident is itself a risk.

Next call (fast path): removing or suspending the member. In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change. A SCIM deprovision sets the member to suspended rather than removing them, and that is enough to refuse the next call. SCIM is the standard an identity provider uses to push joiners and leavers into an app. Revoking a share or disconnecting an account also takes effect on the caller's next request. A revoked grant returns 401 invalid_token; a refresh attempt against a revoked grant returns invalid_grant.

Propagation delay (slow path): role changes, restriction changes and team membership changes take effect within about two minutes. Never plan a shutdown around a restriction edit for that reason. To stop a task at once, suspend the member or revoke the grant, and leave the role alone.

Then there is the clock the task runs against regardless of what you change. An access token lasts 1 hour. A refresh token lasts 30 days and rotates on every use; reusing an old refresh token or authorization code revokes the whole grant. The grant itself has no expiry. But a client idle past 30 days needs the member to sign in again, in a browser, since sign-in cannot be completed headless. Practical consequence: a schedule that quietly stops running is often a grant that needs reconnecting, not a broken connector. That distinction should be the first thing you check before debugging further.

Last, the person behind the connection. Each toolbox entry records who pinned it, and that identity is re-checked on every call, not just at creation. If that person loses use, is removed, or is SCIM-suspended, the entry resolves unmet for every grantee until someone present re-pins it. So a scheduled task can stop working weeks after the person who set it up has left. The connection behind a recurring task should belong to someone who will still be there in six months, as a matter of design, not hope. Offboarding when the agent holds access covers the preflight.

When a scheduled run is the wrong shape

If a person genuinely has to look at every write before it lands, do not schedule it over an MCP endpoint at all. There is no mechanism described above that inserts a human into that loop. The Elaichi Agent fits that requirement: a write or delete there stops at an approval card with Deny, Allow once and Always allow, and a delete asks every time. ChatGPT's scheduled tasks may pause for approval on data-changing actions, so check that behavior against the requirement before relying on it. The MCP endpoint, by design, puts no person in the loop.

If the task only reads, skip the frozen parameters and spend the effort on restrictions. A read-only scheduled summary needs a narrow role and an accurate audit trail. Frozen parameters solve an argument-tampering problem that doesn't exist if no call in the role can write.

And if one team runs one app with one assistant, a scheduled task pointed at that app's own MCP server is often enough. Standing up a separate control plane adds overhead that only pays off once the same role needs to touch more than one system. The case for a control plane starts when the same role touches several apps. That is the argument in what an MCP control plane is. The apps a scheduled role can be pointed at are in the connector catalog, 600+ connectors in all.

FAQ

Does Elaichi ask for approval before a scheduled AI task writes to an app?

No. Over Elaichi's MCP endpoint, the OAuth grant is the approval: the person picked scopes on Elaichi's consent screen for that named client, and the server re-checks those scopes on every call. There is no per-call prompt on the endpoint, and any approval card an MCP client renders from Elaichi's results is display only. Per-call prompting over MCP belongs to the client. Inside the Elaichi Agent, a write or delete does stop at an approval card before it runs.

Whose permissions does a scheduled AI agent task run with?

Through Elaichi, a scheduled task runs with the permissions of the member whose OAuth grant the client holds. The call carries that member's role, restrictions and connections, and Elaichi's audit entry names that member, the surface (mcp) and the OAuth client it came through. Claude Code routines act as the owning user, per [Anthropic's docs](https://code.claude.com/docs/en/web-scheduled-tasks) (checked October 2026); whose identity a Claude Cowork scheduled task acts as is not documented.

How long can a scheduled task keep calling without anyone signing in again?

An Elaichi access token lasts 1 hour and a refresh token lasts 30 days, rotating on every use. A client that keeps refreshing can run indefinitely, but one that sits idle past 30 days needs the member to sign in again in a browser, because Elaichi's OAuth sign-in cannot be completed headless. Reusing an old refresh token or authorization code revokes the whole grant.

What happens to a scheduled task when the employee behind it leaves?

In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change. So the scheduled task's very next call is refused. A SCIM deprovision sets the member to suspended rather than removing them, which has the same effect on live grants. Separately, any toolbox entry that person pinned stops resolving for every grantee until someone present re-pins it.

Can an argument be locked so a scheduled agent cannot change it?

Yes, with frozen parameters on a toolbox entry in Elaichi. Frozen keys are stripped from the advertised tool schema, so the model cannot fill them in, and frozen values are merged over caller arguments at execution, so passing the key cannot override the freeze. The freeze holds only on the path through that entry, so the connection's owner leaves the connection unshared and shares the toolbox at use instead.

Where people sharing personal API keys with AI tools put them

They sit in three places: local AI client config files, Git repositories, and chat histories. Start with the config files, because nothing inventories them for you.

The usual path is ordinary. An engineer wants Claude or Cursor to read an internal system, installs a local MCP server, and pastes a key into that server's environment block. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. Sharing personal API keys with AI tools spreads through exactly this shortcut, one laptop at a time, with no ticket and no record. Nobody is being reckless. There is no sanctioned path, so people build their own.

This post covers the Claude/ChatGPT/Cursor/Copilot ecosystem because that is where the documented vendor controls exist as of this writing. The same failure mode shows up with other providers' keys: Azure OpenAI keys pasted into local scripts, and AWS Bedrock credentials in .env files. Neither has a vendor-documented admin console either. The discovery method below, read the file rather than ask the vendor, applies to all of them.

No client vendor documents an admin console that lists the servers sitting in members' local config files (vendor docs read October 2026). Finding them means reading the files on each device, with a mobile device management or endpoint detection script. The paths, from each vendor's own documentation:

• Claude Desktop: ~/Library/Application Support/Claude/claude_desktop_config.json on macOS, %APPDATA%\Claude\claude_desktop_config.json on Windows, servers under mcpServers (modelcontextprotocol.io).
• Claude Code: ~/.claude.json for local and user scope, .mcp.json at the repo root for project scope. That file also holds the sign-in session, so read only its mcpServers objects (code.claude.com).
• Cursor: ~/.cursor/mcp.json globally, .cursor/mcp.json per project (cursor.com/docs/mcp).
• VS Code with GitHub Copilot: .vscode/mcp.json and a user-profile mcp.json, both now marked deprecated, plus .mcp.json at the project root and ~/.copilot/mcp-config.json (code.visualstudio.com).
• Devin Desktop, formerly Windsurf: ~/.config/devin/mcp_config.json, and the older ~/.codeium/windsurf/mcp_config.json (docs.devin.ai).
• Codex: ~/.codex/config.toml, one [mcp_servers.<name>] table per server (learn.chatgpt.com).

Run the same sweep across repositories and any chat export you can reach. A fuller version of the discovery pass is in the guide to finding installed MCP servers.

What do the key issuers already catch?

More than most security teams assume. Some of it is on by default and the rest is a license line, before you build anything.

GitHub secret scanning is free and automatic on public repositories. Private and internal repositories need GitHub Secret Protection, at $19 per active committer per month on GitHub Team or Enterprise. Push protection for users is on by default for public repositories on GitHub.com; repository push protection is off by default and needs Secret Protection (docs.github.com, GitHub Advanced Security, checked October 2026). OpenAI and Anthropic keys are partner patterns, so they carry push protection and validity checks (docs.github.com, checked October 2026).

OpenAI says sharing API keys is against its Terms of Use, and that it disables a key as soon as it is found on the public internet or inside an app-store app (help.openai.com, checked October 2026). Anthropic takes part in GitHub's partner program, deactivates exposed Claude API keys automatically and emails the owner; a personal key is archived when its owner is removed from the organization (support.claude.com, checked October 2026).

Turn these on first. They cost a license line and a configuration change, and they catch the loudest failure mode, which is a key committed to a repository. They do nothing about a valid token sitting quietly in a config file on one laptop, which never gets near git push.

What API Key Governance and inference hooks cover

Four vendor-side controls exist today, and they do not overlap. None of them, alone or together, covers a key already pasted into a local MCP server's config file.

OpenAI's API Key Governance, announced 15 September 2026, lets admins allow only service-account keys or block new key creation outright (developers.openai.com, checked October 2026). It narrows who can create a personal key going forward. It does not claim automatic rotation of keys that already exist, so do not plan on one.

For secrets typed into a prompt rather than a config file, Claude Enterprise has Inference hooks, in beta. Each governed prompt is sent to the organization's own security server for an allow or deny verdict before inference, with no redaction step: the verdict is binary, not a scrub (platform.claude.com, checked October 2026). ChatGPT Enterprise has no documented native equivalent for inline prompt filtering. Review runs after the fact through Compliance Platform partners, and a ChatGPT-Allowed-Workspace-Id header injected at the network keeps people off personal workspaces, but it does not inspect what's typed into a sanctioned one (help.openai.com, checked October 2026).

The asymmetry matters when you decide which assistant gets which data: one vendor documents a prompt-time content gate, the other documents workspace-level network controls plus after-the-fact review. Neither touches a project-scoped key already pasted into a local environment file. That gap is what the next section is about.

Remove the reason to paste a key

People paste keys because the sanctioned path does not exist yet. Build the path and the pasting drops, because the key stops being the only way in.

The rest of this section describes how Elaichi, specifically, implements that path. This is vendor self-report, not an independently audited claim: treat the architecture description as "how one product says it works," and verify against your own vendor's documentation before relying on it for a compliance control.

Elaichi is a governed MCP control plane. Every company SaaS account is connected once, and the tools those accounts expose are served through one organization-wide MCP endpoint at https://api.elaichi.ai/mcp. Claude, ChatGPT, Cursor and any other MCP client all point at that same address and sign in over OAuth (an authorization standard where the client receives a scoped token instead of a shared secret). Clients register themselves through dynamic client registration with PKCE (a challenge-response extension to OAuth that stops an intercepted authorization code from being replayed), so there is no client ID, secret, or header for a person to type or to leak.

Four properties do the work, as Elaichi documents them:

• No key to hand out. Connector credentials never live in Elaichi's application layer. A separate credential service holds per-account secrets, encrypted at rest with AES-256-GCM, and owns token refresh. A failed refresh marks the connection needs_reauth rather than failing silently.
• The model never handles the credential. The model finds a connected tool with search_tools and runs it with execute_tool, two tools Elaichi exposes over MCP. The credential is read and the third-party call made server-side. Tool results are scrubbed for secret-shaped values before they reach the model, as a backstop, not the primary control.
• Nothing secret is readable back. Reading an account's configuration returns public values plus secret_paths, the list of dot-paths that were encrypted, carrying none of the underlying values. Editing one is refused by the API.
• Revocation is a database write, not a key rotation. The grant's revoked_at field is re-read from the organization store on every call, with no cache. In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change.

That last point is the one an offboarding checklist cares about. Disabling an identity provider account does nothing to a static key sitting in a config file on a laptop. The key keeps working until someone revokes it at the issuer, which can be days later or never. A grant to a governed endpoint dies on the next tool call, because the revocation check happens per-request rather than per-session. The argument for OAuth over static keys generally, not specific to this vendor, is set out in the comparison of the two credential shapes.

There is also no server to install on a laptop in this model. Elaichi authors, maintains and serves most of its connectors from its own infrastructure, and the rest are app vendors' own MCP servers that it governs, so adopting the path does not mean approving somebody else's code onto a laptop. That is a real tradeoff against a registry-based approach, not a strictly better one: you gain a single control plane to audit and lose the option of a community-maintained connector for something niche. Where your connectors come from covers that distinction in more detail.

The path only removes the reason to paste a key if the app people want is actually on it. Elaichi's catalog holds 600+ connectors, and where a connector needs the organization's own OAuth app, an admin with connector:manage adds it. Check the connector catalog before you write the policy line below, so the policy isn't asking people to use something that doesn't exist yet. The cost side: building or buying this is more setup than flipping on GitHub push protection, and it is only worth it once more than one or two engineers are already pasting keys, which is the trigger condition in the last section of this post.

The one policy line worth writing

Write one sentence people can remember at the moment they are about to break it.

No personal API key goes into an AI client's config, a prompt, or a repository. If the app is on the company MCP endpoint, connect it there. If it is not, file a request and we will add it.

That line works because it names the alternative in the same breath as the prohibition. A rule with no sanctioned path is a rule people route around, and the routing is invisible, which is the whole shadow AI problem. Pair it with a request route. In Elaichi, any member can file an access request with no permission needed, and resolving one takes member:manage.

What to do when a key turns up

Revoke first, then rotate, then read the usage. In that order, because every minute between discovery and revocation is a minute the key still works.

1. Revoke at the issuer. Not at the gateway, not in the config file. The key is valid until the system that issued it says otherwise.
2. Rotate the replacement into a sanctioned place. A service account the platform team owns, or a connection on the governed endpoint. Never back into the same config file.
3. Read the usage history at the issuer. You want the window between creation and revocation, and whether any call came from somewhere you do not recognize.
4. Sweep for copies. The same key is often in a second config file, a .env, and a chat message. Use the paths listed earlier in this post.
5. Record what you did. If the app also sits behind Elaichi, disconnecting that account takes effect on the caller's next request, not on a schedule. Elaichi writes one entry for each connected-tool call that reaches execution (a call refused earlier writes none).

What a governed endpoint does not stop

It does not stop someone pasting a key into a chat window. An MCP endpoint sits between a client and a SaaS account. It never sees the prompt, so it cannot inspect one. This is a structural limit of the architecture, not a missing feature.

That half of the problem belongs to the issuer controls and to DLP (data loss prevention tooling that inspects content leaving the company). Four layers, each covering a different point in the path, none of them redundant with the others:

Treating any one of these as the whole program leaves the other three gaps open. How CASB and DLP see AI traffic covers what each layer observes in more detail, and why people paste company data in the first place covers the underlying behavior.

One more specific limit. The prompt-injection write gate in the Elaichi Agent does not apply to POST /mcp and structurally cannot, because an MCP server never sees a user prompt. It only sees a tool call with parameters. What does hold on the endpoint is permission checks per operation, the forbidden classification, output redaction, OAuth scope limits, and an audit row for each call that reaches execution.

And there is a case where none of this is yours yet. If nobody has wired an AI client to a company system, and the only keys in play are a handful of model API keys on a platform team's service accounts, the issuer controls plus a rotation habit are the whole program. Buying or building a governed endpoint before that point is solving a problem you don't have yet. The signs you do not need a gateway yet is the better read in that situation. Come back when the second engineer pastes a production key into a config file, because that is the week the shortcut becomes a pattern instead of an incident.

For the shape of the thing you would be adopting, start with the control plane explainer. For the laptop side of the cleanup, replacing personal MCP servers picks up where the discovery sweep ends.

FAQ

Can an admin console show which API keys sit in employees' local AI client config files?

No. As of October 2026, no MCP client vendor documents an admin inventory of the servers sitting in members' local configuration files. Admin consoles report servers that connect through the vendor's own surface. Finding local servers, and the keys in their environment blocks, means reading the files on each device with a device management or endpoint detection script, at paths such as ~/.cursor/mcp.json for Cursor ([cursor.com/docs/mcp](https://cursor.com/docs/mcp)), ~/.claude.json for Claude Code ([code.claude.com](https://code.claude.com/docs/en/mcp)) and ~/.codex/config.toml for Codex ([learn.chatgpt.com](https://learn.chatgpt.com/docs/extend/mcp)).

Does GitHub secret scanning cover private repositories by default?

No. GitHub secret scanning is free and automatic on public repositories. Private and internal repositories need GitHub Secret Protection, which costs $19 per active committer per month on GitHub Team or Enterprise. Push protection for users is on by default for public repositories on GitHub.com, while repository push protection is off by default and also needs Secret Protection ([docs.github.com](https://docs.github.com/en/code-security/concepts/secret-security/push-protection), checked October 2026).

Does disabling someone's identity provider account kill the API keys on their laptop?

No. An API key pasted into a local AI client config file is a standalone credential. It keeps working until someone revokes it at the system that issued it. That is the practical difference with OAuth: a grant to Elaichi's organization-wide MCP endpoint is checked on every call with no cache. In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change.

Will a governed MCP endpoint stop employees pasting API keys into chat?

No, and it cannot. An MCP endpoint sits between an AI client and a SaaS account and never sees the user's prompt. Prompt-level secrets belong to other layers: Claude Enterprise Inference hooks send each governed prompt to the organization's own security server for an allow or deny verdict before inference ([platform.claude.com](https://platform.claude.com/docs/en/manage-claude/inference-hooks), checked October 2026), while ChatGPT Enterprise has no documented native equivalent and relies on after-the-fact compliance review plus network controls ([help.openai.com](https://help.openai.com/en/articles/20001323-corporate-network-controls-in-chatgpt-enterprise), checked October 2026).

What is the first step when a personal API key turns up in a config file?

Revoke it at the issuer, before anything else. The key stays valid until the issuing system says otherwise, so deleting it from the file changes nothing. Then rotate the replacement into a sanctioned place, read the key's usage history at the issuer for the window between creation and revocation, and sweep for copies in other config files, .env files and chat messages.

An engineer hands Claude Code a Jira ticket at 4:40 PM and goes to a meeting. When she returns, the agent has read the ticket and pulled the Sentry stack trace. It has checked the PagerDuty incident, changed three files and pushed a branch. It has posted in the team's Slack channel. That took dozens of tool calls, and nobody read any of them as they ran.

That run is what MCP for coding agents has to be designed around. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. A chat assistant answers a person who reads every reply. A coding agent works a task, and the person reads the result.

What makes a coding agent different from a chat assistant?

Four things: it takes many steps per task, it acts without a person approving each call, it runs on the engineer's machine, and the engineer wires it up in a config file. Each one moves the control away from the person in the chat.

Both clients let engineers turn approval prompts down. Claude Code's auto mode "runs without routine prompts", with a background classifier checking actions instead. Its bypassPermissions mode skips prompts, and the docs say to use it only "in isolated environments like containers or VMs" (Claude Code permissions, checked October 2026). A scripted claude -p run "shows no workspace trust dialog and no per-server approval prompt" (Claude Code headless docs).

Cursor "asks for approval before using MCP tools by default". Its Run Modes can let approved tools "run immediately" and send everything else to a classifier (Cursor's MCP docs, checked October 2026).

None of that is a flaw. Speed is the reason teams use coding agents. It does mean the approval prompt is a convenience the engineer controls. The rules that matter have to sit where the call lands.

What goes wrong when each engineer wires up their own MCP servers?

Four problems arrive together: server sprawl, secrets in dotfiles, slow offboarding and no shared record. They grow with headcount, not with usage.

Sprawl comes from the config model. Claude Code stores a server at local, project or user scope, in ~/.claude.json or a project's .mcp.json (Claude Code MCP docs, checked October 2026). Cursor reads .cursor/mcp.json or ~/.cursor/mcp.json. Forty engineers end up with forty different sets of servers, and nobody holds the list.

Secrets follow the same path. Claude Code's own example adds a server with --header "Authorization: Bearer YOUR_GITHUB_PAT", and .mcp.json can expand ${API_KEY} from the environment. Cursor interpolates ${env:MY_SERVICE_TOKEN} the same way. The token then lives in a shell profile or an .env file. A personal token usually carries everything its owner can do in that app, and the agent inherits all of it.

Offboarding becomes a hunt. Each token is revoked app by app, and only if someone knows it exists. The record is split too. Each app logs the call against the engineer's token, and a call on a personal token looks the same as the engineer's own.

How should MCP for coding agents work without shared API keys?

Through one organization-wide endpoint that each engineer signs in to with OAuth (a sign-in that issues a revocable grant instead of a copied secret). Elaichi serves every connected account at https://api.elaichi.ai/mcp. Claude, ChatGPT, Cursor and any MCP client use that same address.

The config entry holds a URL and nothing else. Claude Code "supports OAuth 2.0 for secure connections", runs the sign-in in the browser from /mcp, and stores tokens securely and refreshes them. Cursor supports OAuth for servers that require it. Both register themselves with Elaichi through dynamic client registration, so nobody types a client ID or a secret. A project .mcp.json holding only the address is safe to commit.

Each SaaS account is connected once, in Elaichi, not on a laptop. A separate credential service holds the account secrets, encrypted at rest, and owns refresh. An engineer's grant issues access tokens that last an hour and refresh tokens that rotate on every use.

The step-by-step setup is in connecting Cursor for a whole team and in the Claude Code setup guide. For why a grant beats a pasted key, read OAuth or API keys for AI agents.

How do you give engineers AI access to Jira and PagerDuty with the right permissions?

Give engineers one role, share them a toolbox instead of the connections, and restrict the destructive tools on that role. The consent screen then holds back deletes on each engineer's grant.

The role carries tool:execute, which gates the whole endpoint. Each member holds exactly one role, so it has to be complete. A member sees only what they own or what was shared with them, and no admin role widens that view. Restrictions decide 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.

Start with the tools whose damage is hard to undo:

• delete_a_jira_issue_by_id, which can take an issue's subtasks with it when deleteSubtasks is true.
• delete_a_pagerduty_service_by_id. Its description says that once deleted, "new incidents cannot be created for it".
• delete_a_pagerduty_event_orchestrations_integration_by_id, which removes a routing key, "stopping all future events sent with that key".
• sentry_organization_issues_bulk_delete. If no issue IDs are passed, "the first 1000 matching issues are removed".

A restricted tool is withheld from the tool list and cannot be called. Search names it, flagged restricted, with no schema, so an agent chasing a bad idea finds nothing to call. A rule takes about two minutes to apply, so wait before you test it.

The grant adds a second lock. On Elaichi's consent screen, "Delete data and remove access" is never ticked in advance. Without that scope, connected tools whose method is a delete are left out of the tool list and the search index.

Why shouldn't a coding agent's own approval rules decide read versus delete?

Because every connected Elaichi tool reaches the client through one tool, execute_tool, and the usual approval rules name that tool instead of the one inside it. In Elaichi, connected tools are never listed one by one, however few there are. The agent finds a tool with search_tools and runs it with execute_tool.

Claude Code writes MCP permission rules against a tool name, such as mcp__puppeteer__puppeteer_navigate. For Elaichi, that name is the same for a Sentry read and a Sentry bulk delete. A Cursor approval prompt likewise names execute_tool, with the real tool inside the arguments.

Claude Code can go further, but only on the command line. A deny rule passed with --disallowedTools can match the name parameter of execute_tool by exact value, which names one tool. Settings files skip MCP rules that carry a parameter, and allow rules cannot match a parameter at all.

So keep the read-versus-delete decision in Elaichi's restrictions. execute_tool is only a naming indirection. It unwraps to the real tool and arguments and passes the same checks as a direct call, with no extra privilege.

How do frozen parameters keep a long-running agent on target?

They fix the arguments that pick a destination, so the agent cannot choose them. Freeze channel on create_a_slack_chat and the project inside fields on create_a_jira_issue.

A frozen key is stripped from the schema the agent sees, so the model is never offered a channel to pick. At execution, the frozen value is merged over whatever the agent sends. The order is entry defaults, then the agent's arguments, then frozen values last.

That matters most for an agent nobody is watching. A misread ticket cannot send its status update to the company-wide channel. One condition: a freeze binds only calls made through its toolbox entry, so share the toolbox with the people it governs, not the connection itself. The connection owner pins the entry and vouches for it, so pick an owner who will stay. Locking a wire transfer's receiver walks through the same setup.

What does one Jira ticket look like, call by call?

Seven steps, five of which run through Elaichi. The code edits and the pull request stay on the engineer's machine.

1. The agent searches for a Jira tool and calls get_single_jira_issue_by_id for the ticket.
2. It reads the error with get_single_sentry_organization_issue_by_id, then list_all_sentry_issue_events with latest as the event ID.
3. It checks the incident with get_single_pagerduty_incident_by_id.
4. It edits files and runs tests locally. Elaichi sees none of this.
5. It opens the pull request with the engineer's own Git and GitHub credentials. GitHub is not in Elaichi's catalog, so this step stays outside Elaichi.
6. It links the pull request with create_a_jira_issue_comment and create_a_pagerduty_incident_note.
7. It posts a summary with create_a_slack_chat, to the frozen channel.

Each call through Elaichi passes the engineer's role, the restrictions and the grant's scopes. An agent stuck in a retry loop meets a plain limit: 120 MCP requests a minute per token, then a 429 with Retry-After: 60.

How do you tell afterward which agent made a call?

From Elaichi's audit trail, which records one entry for each connected-tool call that reaches execution (a call refused earlier writes none). Each entry names the account the call actually reached.

Each tool-call entry also records the surface and the OAuth client the call came through. Elaichi trusts a client's name only when its registered redirect addresses prove it, as with Claude, ChatGPT and Cursor. A terminal client that signs in through a local loopback address, such as Claude Code, carries the name it registered with, marked unverified.

The trail keeps the one path argument that names the object, as the target id, and nothing else about the arguments, so it shows what ran and where without holding the payload. The read-only Auditor seat is free. Beyond the in-app trail, export to your own Datadog comes with the Black plan, which is launching soon. What an AI audit log must capture lists the fields.

Is there an MCP gateway that supports Claude Code and Codex for engineering teams?

Elaichi is an MCP control plane, a hosted service rather than a gateway you deploy, and its endpoint is standard MCP over Streamable HTTP behind OAuth. Claude Code, Cursor, Codex, Windsurf and VS Code Copilot connect to it with an OAuth sign-in and no key. Any other client fits under "any MCP client" when it supports remote servers with an OAuth sign-in.

Codex documents both. Its docs describe "Streamable HTTP servers: Servers that you access at an address", and codex mcp login <server-name> "to start an MCP OAuth login" (Codex MCP docs, checked October 2026). Sign-in needs a browser. An unattended CI run with no browser, in any of these clients, cannot sign in, so plan for engineers to sign in at their own machines.

When is an app's own MCP server the better choice for a coding agent?

When the team needs one app, especially one Elaichi does not carry. The app's server runs under its own permission model and puts no second vendor in the path.

GitHub is the clearest case. Its server "connects AI tools directly to GitHub's platform", hosted at https://api.githubcopilot.com/mcp, with a read-only mode that skips write tools (GitHub MCP Server, checked October 2026). Sentry runs one at https://mcp.sentry.dev/mcp, and "All connections use OAuth" (Sentry MCP, checked October 2026). Atlassian's server connects Jira, Confluence and more to AI tools "using OAuth 2.1 or API tokens" (checked October 2026).

What Elaichi adds is the layer across apps. Engineers add one address instead of one server per app. Restrictions are written once for the engineer role across Jira, Sentry, PagerDuty and Slack. Frozen arguments, one audit trail, and one removal that ends access through Elaichi come with it. That removal does not close the person's accounts inside each app.

When does an engineering team not need any of this?

When the agents only touch local code, or when a few engineers share one read-only account and nobody asks who did what. A coding agent that reads and writes files reaches no SaaS account, so there is nothing to govern.

Elaichi also stops at its own edge. It does not see the shell, Git, or a local server an engineer adds beside it. The prompt-injection write gate lives in the Elaichi agent window and does not apply to a raw tool call. A poisoned ticket can still steer a model toward a tool. Restrictions decide whether that tool exists for the engineer. A call that reaches execution is logged.

A contractor, a second Jira site or an auditor's question changes the math. Run the test in when you don't need an MCP gateway first. Gold lists at $15 per user per month in USD.

FAQ

How do you give Cursor access to internal tools across an engineering team without sharing API keys?

Connect each company account once in Elaichi, then have every engineer add the same address, https://api.elaichi.ai/mcp, as a remote MCP server in Cursor. The entry holds a URL and no key. Cursor supports OAuth for servers that require it, so each engineer signs in as themselves and gets a grant that can be revoked on its own. The account credentials stay in Elaichi's separate credential service and never reach a laptop.

Does Elaichi work with Codex, Windsurf or VS Code Copilot?

Yes. Elaichi serves standard MCP over Streamable HTTP behind OAuth, and Codex, Windsurf and VS Code Copilot connect to it, as do Claude, ChatGPT, Cursor and Claude Code. Any other MCP client that supports remote servers with an OAuth sign-in fits under "any MCP client". Sign-in needs a browser, so an unattended CI run with no browser cannot sign in.

Can a coding agent delete things through Elaichi?

Only what the engineer's grant and the organization's rules allow. On Elaichi's consent screen, the box for deleting data is never ticked in advance. Without that scope, connected tools whose method is a delete are left out of the tool list and out of search. Admins can also restrict individual tools for a role. A restricted tool is withheld from the tool list and cannot be called, and search names it, flagged restricted.

What happens to a coding agent's access when an engineer leaves?

It ends with their Elaichi membership. In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change, so the next call from their Claude Code or Cursor fails. The URL left in their config file is the same public address every engineer uses and carries no token. Their own accounts inside each app are a separate step.

An IT lead gets the same request from three teams in one week. Support wants Zendesk in Claude. Sales wants Salesforce in ChatGPT, and engineering wants Jira in both. Answered one at a time, that is four setups, three permission models and three places to check when someone leaves.

This guide shows how to connect company apps to Claude and ChatGPT once, for the whole company. 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 endpoint, the web address a client calls. People sign in to it with OAuth, the standard that gives a client a revocable grant instead of a password.

How do you connect company apps to Claude and ChatGPT at once?

Connect each account once in Elaichi, share it, and add one address to each AI client. All of your apps then reach both clients in one pass. Work in this order: accounts first, sharing second, clients last.

1. Connect each account, such as Slack, Jira and Salesforce, once in Elaichi.
2. Share each connection, or a toolbox built from it, with the people who need it.
3. Bring people into the organization with a role already set.
4. Add https://api.elaichi.ai/mcp once in Claude and once in ChatGPT.
5. Sign in as one member, run a read in each app, and check the audit trail.

The same address serves Claude, ChatGPT, Cursor and any MCP client. Adding Cursor later is the same work. Under the default consent choice, a new app needs no change in any client.

Can Google Workspace, Slack, Jira and Salesforce reach Claude for the whole company?

Yes. Each is a connector in Elaichi's catalog. Google Workspace arrives as several: Gmail, Google Drive, Google Calendar and Google Docs. A separate Google Workspace connector covers directory users and groups. Slack, Jira and Salesforce are one connector each.

Decide, per app, whose account each connection is. A connection runs on the credential of the person who connected it. Every call through a shared connection therefore reaches the app as that one account.

That suits a team account, such as a Jira site connected by its admin. It does not suit an inbox, or a CRM where each person's own permissions matter. For Gmail and Salesforce, each person connects their own account, once. Each rep's own Salesforce access shows that pattern in full.

Connecting can start inside either client. The chat shows a one-time link with no token in it, so the link exposes no secret.

Do you have to build or run an MCP server for each app?

No. Elaichi authors, maintains and serves most of its 600+ connectors from its own infrastructure, and the rest are app vendors' own MCP servers, so the company runs no MCP server, hosted or local.

Running your own is real work. Under the MCP specification's local transport, the client launches the server as a subprocess on the person's machine (MCP transports). Multiply that by every app and every laptop, and someone installs, updates and secures each copy. A remote server spares the laptops, but somebody still hosts one per app.

App credentials stay out of the clients and out of Elaichi's organization store. Secrets live in a separate credential service, which encrypts them at rest and refreshes the tokens. If a refresh fails, the connection becomes needs_reauth. That is one account to reconnect, not silent failures in fifty chats.

When the catalog lacks an app, a custom connector is authored from JSON config. Creating one needs the connector:create permission, which Elaichi flags as high trust. Running MCP servers yourself compares the two shapes in depth.

How do connected accounts become tools in a toolbox?

On their own at first, and on purpose when you need limits. Every connection a person holds use on joins their "All my tools" set as soon as it exists. There is no build step.

A toolbox is a saved set of tools from one or more connections, shared with a team. It earns its place in two cases. The first is a fixed argument, such as the one Slack channel a team may post to. One condition: a freeze binds only calls made through its toolbox entry, so share the toolbox with the people it governs, not the connection itself. The second is delegation. A team runs tools through the toolbox without being able to open, see or reshare the connection behind it.

What a person may call is still decided by restrictions, rules about which connectors and which individual tools a target may reach. Write them against roles before anyone signs in. A change takes about two minutes to apply, so test after that window. Locking one tool argument walks through a frozen toolbox entry.

How do you share one setup so nobody else has to configure it?

Share the connection or the toolbox, and let people join with a role already set. Sharing in Elaichi is a grant of view, use or edit on a resource. It goes to one person, a team or the whole organization, and use lets the grantee run tools through it.

A member sees only what they own or what was shared with them. No org-level permission widens that view, for owners and admins as well.

People join in four ways. An emailed invite link can carry a role and teams. A verified email domain can auto-join new people with a default role. SCIM, a standard for syncing users from a directory, provisions them, and single sign-on can add them on first sign-in. Each member holds exactly one role, so choose the default with care.

What remains for each person is small but real. They connect the connector their admin added, and sign in once. They paste no URL, token or client ID. Under "All my tools", an account shared with them later reaches their client with no new step.

Where do you add Elaichi's one address in Claude and ChatGPT?

Once, in each client's admin settings, as a custom connector or a custom app. The address is https://api.elaichi.ai/mcp for every organization, with no trailing slash. Nobody enters a client ID or secret. Claude registers itself through OAuth dynamic client registration (RFC 7591).

In Claude Team and Enterprise, an Owner adds it under Organization settings, then Connectors. Members then connect it under Customize, then Connectors (Anthropic's custom connector guide, as of October 2026). Pro and Max users add it themselves. The Claude walkthrough has every click.

In ChatGPT, full MCP with write actions is rolling out in beta to Business, Enterprise and Edu (OpenAI's developer mode guide, as of October 2026). An admin creates one app under Workspace settings, then Apps, runs Scan Tools and publishes it. Members find it in their Apps settings, labeled custom. Setting Elaichi up in ChatGPT covers the plan details.

One ChatGPT app covers twenty apps or two hundred. In Elaichi, connected tools are never listed one by one, however few there are. The client sees search_tools and execute_tool, which reach every connected app. A new app is a new connection in Elaichi, not a new app in ChatGPT.

Connect at least one account the admin can use before running Scan Tools. Those two tools appear only while at least one connected tool is reachable, and the scanning admin's own grant decides that.

What does each person see at sign-in and consent?

Elaichi's sign-in, then a consent screen with an organization picker and up to four checkboxes. Someone not yet signed in to Elaichi signs in first. If the company enforces SSO for its email domain, other sign-in methods are refused.

A person in one organization finds it preselected. The checkboxes are:

• Read your organization's data
• Create and change data
• Run your connected tools
• Delete data and remove access

Everything the client requested starts ticked except delete, which never does. With "Run your connected tools" ticked, a second step offers "All my tools", the default, or "Only the ones I pick", up to 50 toolboxes. Continue stays disabled until an organization is picked, its plan is active and at least one box is ticked.

Each grant belongs to one person. In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change, so a leaver's next call from either client fails.

How do you check that every app reached every client?

Sign in as an ordinary member with the default role, and run one read per app. Most people will hold that role, so it is the view that matters.

1. The client's tool list shows search_tools and execute_tool. If both are missing, no connected tool is reachable. The usual causes are a connection that is absent, pending or needs_reauth, a grant without "Run your connected tools", or a role without tool:execute.
2. Ask for one read per app, such as today's calendar or an open Jira issue. A search naming an app the person never connected returns nothing, plus a line naming up to six apps they can reach.
3. Open the audit trail. Elaichi writes one entry for each connected-tool call that reaches execution (a call refused earlier writes none), naming the account each call reached. Each entry records the surface, mcp for a remote client, and the OAuth client the call came through. Claude, ChatGPT and Cursor are named and marked verified.
4. In Elaichi, Settings, then Connected apps lists the person's client. That is also where they disconnect it.

If a tool is missing, the missing-tools checklist walks the checks in order. If sign-in fails, the OAuth error guide names the broken step.

When is a client's own connector enough without Elaichi?

When one person needs one app. A person reading one app through the client's own connector needs nothing more, and a second vendor adds cost without adding control.

The case changes with the second app, the second team or the first contractor. At that point you have several permission models, and no one place to end a person's access. When you don't need an MCP gateway yet lists the signals in detail.

Cost is the other honest limit. Elaichi's Gold plan lists at $15 per user per month in USD, and the pricing page shows your region's price. Auditor, Guest and Billing Admin seats are not billed. Gold starts with a 14-day trial, no credit card to start. Checkout does collect a card, and it sets the paid trial to the remaining days rather than granting a fresh 14, so it is one continuous trial rather than two.

Engineers on Cursor use the same address, as the Cursor rollout shows. To plan which team goes first, start from the use-cases directory. If nobody has the time to set it up, forward deployed engineers can do it with you.

FAQ

Can one setup connect 20 or more SaaS apps to ChatGPT Enterprise?

Yes, with Elaichi. A ChatGPT Enterprise admin creates one custom app from Elaichi's address and publishes it to the workspace. Every app the company connects in Elaichi is reached through that one app, because connected tools are found through two tools, search_tools and execute_tool. Adding a twenty-first app is a new connection in Elaichi, not a new app in ChatGPT.

Does Elaichi host the MCP servers, or do we run them?

Neither is on you. Elaichi authors, maintains and serves most of its connectors from its own infrastructure, and the rest are app vendors' own MCP servers that Elaichi governs, so a company runs no MCP server for any app. A separate credential service holds each connected account's secrets, encrypted at rest, and refreshes their tokens. When the catalog lacks an app, a custom connector can be authored from JSON config.

Does each employee have to configure anything for Claude or ChatGPT?

Very little. An admin adds Elaichi's address once in each client, and the apps are shared in Elaichi. Each employee then connects the connector in their own client and signs in with OAuth once. Nobody pastes a URL, an API token or a client ID, and apps shared with them later need no new step.

How much does a company-wide Elaichi rollout cost?

Elaichi's Gold plan lists at $15 per user per month in USD, or $120 per user per year, and elaichi.ai/pricing shows the price in your region. Auditor, Guest and Billing Admin seats are not billed. Gold starts with a 14-day trial, no credit card to start. Checkout does collect a card, and it sets the paid trial to the remaining days rather than granting a fresh 14, so it is one continuous trial rather than two.

Claude Code is Anthropic's coding agent for the terminal. Give it a bug, and it reads the Jira issue, searches Slack and edits code over dozens of steps. Each step that reaches a company app needs a credential. The usual answer is a personal token pasted into a config file, one per app, per engineer. One endpoint behind OAuth replaces those tokens.

How do you connect Elaichi to Claude Code?

Run one claude mcp add command with Elaichi's endpoint, https://api.elaichi.ai/mcp, then sign in from Claude Code in your browser. That is the whole job to connect Elaichi to Claude Code. There is no API key, no header and no server to run.

MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. Its specification is open for anyone to read. Elaichi exposes all connected SaaS accounts at one organization-wide address, POST /mcp, protected by OAuth.

Which command adds Elaichi to Claude Code?

claude mcp add with the HTTP transport, a name and the URL. Anthropic's docs give the form claude mcp add --transport http <name> <url> (Claude Code MCP docs, checked October 2026). For Elaichi, at user scope:

claude mcp add --transport http elaichi --scope user https://api.elaichi.ai/mcp

Leave out --header. Elaichi does not take a bearer token you paste. Copy the URL exactly, with no trailing slash and on the api host. With a trailing slash the endpoint returns 404, and on app.elaichi.ai it returns 405. Neither starts sign-in.

Should Elaichi live at user, project or local scope?

User scope for one engineer, project scope for a team. Claude Code stores a local or user server in ~/.claude.json, and a project server in .mcp.json at the repository root. Local is the default and loads in one project only. User scope loads in all your projects. Project scope is shared through version control.

A project entry for Elaichi looks like this:

{
  "mcpServers": {
    "elaichi": {
      "type": "http",
      "url": "https://api.elaichi.ai/mcp"
    }
  }
}

That file is safe to commit, because it holds no secret. Every clone carries the same address, and each engineer still signs in as themselves. In interactive sessions, Claude Code asks each engineer to approve a project server from .mcp.json before it connects. In claude -p runs, Agent SDK sessions and cloud sessions it cannot show that prompt, and the docs say it "loads project-scoped servers without asking". The entry holds no secret, so loading it exposes no credential.

A platform lead can pin the requested scopes in the same file with Claude Code's oauth.scopes field. Add "oauth": { "scopes": "mcp:read mcp:write mcp:tools" } to the entry, and Claude Code asks for those scopes instead of the ones Elaichi's metadata lists. Treat that pin as a default, not a ceiling. Claude Code's precedence runs local, then project, then user, and it uses the whole entry from the highest source with no merging. An engineer who adds a local elaichi entry replaces the project one. To hold deletes back reliably, restrict the delete tools in Elaichi. That binds whichever entry an engineer uses.

What happens when an engineer signs in?

Claude Code opens Elaichi's sign-in in the browser, and the engineer approves a consent screen. Start it with /mcp inside a session, or with claude mcp login elaichi from the shell. Over SSH, claude mcp login prints the URL instead, and --no-browser forces that.

Sign-in needs a browser. Claude Code running headless in CI, or in a terminal with no access to a browser, cannot complete Elaichi's OAuth sign-in. Connect from a machine where the engineer can open the browser, and do not plan on unattended CI runs.

Claude Code registers itself through dynamic client registration (RFC 7591), which Elaichi supports, so there is no client ID to enter. It picks a random local port for the callback each time. Elaichi checks the callback address exactly, except that a loopback address may change its port. That is the rule RFC 8252 sets for native apps.

On Elaichi's consent screen, the engineer picks one organization. Then come up to four checkboxes: read data, create and change data, run connected tools, and delete data. Everything requested starts ticked except delete, which never does. Keep Run your connected tools ticked, or the agent reaches no connected app. The request lasts 30 minutes and works once.

How do you confirm Claude Code can see the tools?

Check the server first, then ask for one read. claude mcp list shows a health status beside each server, such as Connected or Needs authentication. claude mcp get elaichi shows one server's details, and /mcp shows the same inside a session.

Expect a short tool list. In Elaichi, connected tools are never listed one by one, however few there are. Claude Code calls search_tools to find a connected tool, then execute_tool to run it. Those two, plus any Elaichi operations the engineer's role and grant allow, are the whole list.

Then ask a real question, such as "List my open Jira issues". If the list is empty or an app is missing, the missing-tools checklist walks the causes in order.

How do Jira, Slack and GitHub reach Claude Code?

Jira and Slack go through Elaichi, and GitHub does not. An admin or engineer connects each SaaS account once, from a catalog of 600+ connectors, most of them authored by Elaichi. A shared Jira connection reaches Jira as the account that connected it. Elaichi's role, restrictions and audit trail are per engineer. Where Jira's own permissions and log must be the engineer's, each engineer connects their own account once. A separate credential service holds each account's secrets, encrypted at rest, so no Jira or Slack token sits in a dotfile.

GitHub is not in Elaichi's connector catalog. GitHub runs its own remote server at https://api.githubcopilot.com/mcp. GitHub's guide for Claude Code (checked October 2026) adds that server with a personal access token in a header. That one token stays on the laptop, and calls to it do not pass through Elaichi's restrictions or audit trail. The other route is an Elaichi custom connector, which needs the high-trust connector:create permission.

The Jira connector and the Slack connector list every tool a rule can name.

Can one URL serve Claude, ChatGPT, Cursor and Claude Code?

Yes. Elaichi's endpoint is one address for every member, and clients point at it and sign in: Claude, ChatGPT, Cursor and any MCP client. An admin adds it once where a client allows, and each person connects it there and signs in with their own grant.

Claude Code has a shortcut for people who already use Claude. Anthropic's docs say connectors added in claude.ai are available automatically in Claude Code when you log in with a claude.ai account (using claude.ai connectors in Claude Code). So Elaichi, added as a custom connector in Claude, can appear in /mcp with no command at all. That works only with a claude.ai subscription login, not with an API key or a cloud provider. A server you add yourself with the same URL takes precedence, and /mcp then lists the connector as hidden.

The Claude setup and the Cursor setup use the same address unchanged.

What do restrictions and the audit log add for Claude Code?

Elaichi checks every call against the engineer's role, shares and restrictions, whatever approval mode Claude Code runs in. Restrictions decide which connectors and which individual tools a target may reach, and the audit trail names the engineer and the account each call reached. Claude Code's settings-file permission rules cannot tell a Jira read from a Jira delete, because every connected tool runs through one tool name, execute_tool. Only a deny rule passed on the command line can name one tool. MCP for coding agents across an engineering org makes the full argument, including frozen arguments and how to tell which agent made a call. A restriction change takes about two minutes to apply.

How do you disconnect Claude Code from Elaichi?

Remove it in Claude Code, then end the grant in Elaichi. claude mcp logout elaichi clears the credentials Claude Code stores. To be sure the grant has ended in Elaichi, disconnect it in Settings, under Connected apps. When an admin removes or suspends a member, removing or suspending a member revokes every live grant in the same transaction as the membership change, so that engineer's next call fails.

What goes wrong most often, and how do you fix it?

Most failures are the URL, an expired request or a missing checkbox. Each has a quick fix:

• Sign-in never opens. Check the URL for a trailing slash or the app host. In CI or a terminal with no browser access, sign-in cannot finish at all, so connect from a machine with a browser.
• The consent screen says the request is no longer valid. It expired or was used. Run /mcp again.
• A tool error names a checkbox. Elaichi answers with an error telling the engineer to reconnect and allow it. Run claude mcp logout elaichi, then claude mcp login elaichi, and tick the box. If you pinned scopes, add the missing one to oauth.scopes first.
• The list is empty for everyone in a role. The role may lack tool:execute, which an admin fixes.
• A 429 mid-task. Elaichi allows 120 MCP requests a minute per token. Wait a minute.

What each OAuth error means covers the rest, with who fixes each one.

When is Elaichi more than a Claude Code user needs?

When one engineer uses Claude Code against one app they own. That app's own MCP server, signed in with OAuth, is enough. Revisit when a second app arrives, a contractor joins, or someone asks which agent changed a ticket. When you don't need an MCP gateway yet lists the signals.

Gold lists at $15 per user per month in USD, and the pricing page shows your region's price. Gold starts with a 14-day trial, no credit card to start. Checkout does collect a card, and it sets the paid trial to the remaining days rather than granting a fresh 14, so it is one continuous trial rather than two. For the wider picture, read what an MCP control plane is, or pick a first app from the connector catalog.

FAQ

Can one MCP server URL work in Claude, ChatGPT, Cursor and Claude Code?

Yes, with Elaichi. Its endpoint, https://api.elaichi.ai/mcp, is the same for every client and every member of the organization. Each client adds it once, and each person signs in with their own OAuth grant, so the address never changes and only the grant behind it differs.

How do I connect Claude Code to Jira and Slack for a whole engineering team?

Connect Jira and Slack once in Elaichi, then point every engineer's Claude Code at Elaichi's endpoint. Each engineer signs in as themselves, so their Elaichi role, what is shared with them and any restrictions decide what their agent can call. A shared Jira connection reaches Jira as the account that connected it. Where Jira's own permissions and log must be the engineer's, each engineer connects their own account once. GitHub is not in Elaichi's connector catalog, so GitHub's own MCP server sits beside Elaichi or a custom connector fills the gap.

How do you give AI agents access to SaaS apps without a shared service account?

Give each person their own OAuth grant to one endpoint instead of one account that everybody's agent uses. With Elaichi, the grant of the person who signed in authorizes every call, the audit trail names that person, and removing them ends that grant without touching anyone else's access. Where the app itself must see the engineer, each engineer connects their own account.

Is it safe to commit an Elaichi entry to .mcp.json?

Yes. The entry holds a public URL and nothing else: no token, no header and no client secret. In interactive sessions, Claude Code asks each engineer to approve a project server before it connects. In claude -p runs, Agent SDK sessions and cloud sessions, it loads project-scoped servers without asking. Either way the entry exposes no credential, and each engineer signs in as themselves.

Why does Claude Code show only a few Elaichi tools?

In Elaichi, connected tools are never listed one by one, however few there are. Claude Code calls search_tools to find a connected tool, then execute_tool to run it. The /mcp list therefore stays short by design, and a short list is not a broken connection.

Codex is OpenAI's coding agent. It runs in a terminal, in an editor and in the ChatGPT desktop app. Hand it a bug, and it wants the Jira issue, the Sentry error and the Slack thread. Each of those needs a credential. The quick fix is a personal token in an environment variable, one per app, per engineer. One endpoint behind OAuth replaces those tokens.

How do you connect Elaichi to Codex?

Add Elaichi's endpoint, https://api.elaichi.ai/mcp, to Codex as a streamable HTTP server, then run codex mcp login elaichi and sign in in the browser. There is no API key, no header and no server to run.

MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. Its specification is public. Elaichi serves every connected SaaS account at one organization-wide address, behind OAuth (a sign-in that issues a revocable grant instead of a copied secret).

Which Codex command adds the Elaichi endpoint?

codex mcp add with a name and --url. OpenAI's command reference says add registers "a server using a stdio launcher command or a streamable HTTP URL" (Codex command line options, checked October 2026). For Elaichi:

codex mcp add elaichi --url https://api.elaichi.ai/mcp

Leave out --bearer-token-env-var and --oauth-client-id. Elaichi takes no pasted token and needs no client ID. Copy the URL exactly, with no trailing slash and on the api host. With a trailing slash the endpoint returns 404, and on app.elaichi.ai it returns 405. Neither starts sign-in.

How do you add Elaichi in config.toml or the IDE extension?

Write one [mcp_servers.elaichi] table, or use the extension's form. Codex keeps MCP servers in ~/.codex/config.toml, and a project can scope one in .codex/config.toml, for trusted projects only (Codex MCP docs, checked October 2026). The entry is two lines:

[mcp_servers.elaichi]
url = "https://api.elaichi.ai/mcp"

The docs say the ChatGPT desktop app, the Codex CLI and the IDE extension share this configuration. Add Elaichi once, and all three see it.

In the IDE extension, open the gear menu, then MCP servers, then Add server. Enter elaichi, choose Streamable HTTP, paste the URL, save, and select Restart extension. The list then marks servers that need OAuth, and Authenticate starts the sign-in.

A project file holding only this entry is safe to commit, because it carries no secret. Every clone gets the same address, and each engineer still signs in as themselves.

What happens when you run codex mcp login?

Codex opens Elaichi's sign-in in the browser, and the engineer approves a consent screen. OpenAI's docs say to run codex mcp login <server-name> "to start an MCP OAuth login". Without it, Codex can connect with no credential at all, and Elaichi answers that request with a sign-in challenge.

Codex registers itself through dynamic client registration (RFC 7591), which Elaichi supports, so there is no client ID to enter. Its callback listens on 127.0.0.1. Elaichi checks the callback address exactly, except that a loopback address may change its port. RFC 8252 sets that rule for native apps.

Codex asks for the scopes the server advertises, and Elaichi advertises all of its MCP scopes. The consent screen still holds deletes back. The engineer picks one organization, then sees up to four boxes: read data, create and change data, run connected tools, and delete data. Everything requested starts ticked except delete. Keep Run your connected tools ticked, or Codex reaches no connected app. The request lasts 30 minutes and works once.

Sign-in needs a browser. Codex running headless in CI, or in a terminal with no browser access, cannot complete Elaichi's sign-in. Sign in from a machine where the engineer can open a browser.

How do you check that Codex can see Elaichi's tools?

List the server, then ask for one read. codex mcp list shows configured servers, and codex mcp get elaichi shows one entry. Inside the codex TUI, /mcp shows the active servers.

Expect a short tool list. In Elaichi, connected tools are never listed one by one, however few there are. Codex calls search_tools to find a connected tool, then execute_tool to run it. Those two, plus any Elaichi operations the engineer's role and grant allow, make up the list.

Then ask a real question, such as "Summarize my open Jira issues". If the list is empty or an app is missing, the missing-tools checklist walks the causes in order.

Which Codex approval setting fits Elaichi?

Use Codex's settings for prompts, and Elaichi's restrictions for what Codex may reach. Codex sets approvals per server with default_tools_approval_mode, which takes auto, prompt, writes or approve. The docs say writes "prompts for tools that aren't marked read-only".

Elaichi marks search_tools read-only and marks execute_tool as destructive, because its real effect depends on the tool it runs. Under writes, a search runs freely, and every call into a connected app prompts, reads included.

Codex's enabled_tools and disabled_tools lists name tools too. Every connected Elaichi tool arrives through execute_tool, so those lists cannot tell a Jira read from a Jira delete. Elaichi's restrictions can, and they bind whichever client the engineer uses.

What do roles, restrictions and the audit log add for Codex?

Elaichi checks every Codex call against the engineer's role, shares and restrictions, whatever approval mode Codex runs in. The role must carry tool:execute, which gates the whole endpoint. Restrictions decide which connectors and which individual tools a target may reach. A restricted tool is withheld from the tool list and cannot be called. Search names it, flagged restricted, with no schema, so Codex finds nothing to call. A role or restriction change takes about two minutes to apply.

The audit trail writes one entry for each connected-tool call that reaches execution (a call refused earlier writes none), under the engineer who signed in, naming the account the call reached. It keeps the one path argument that names the object, as the target id, and nothing else about the arguments. Each entry also records the OAuth client. Codex CLI signs in through a loopback address, so the trail shows the name Codex registered with, marked unverified. MCP for coding agents across an engineering org covers frozen arguments and the rest of the case.

Which MCP gateway works with both Codex and Claude Code?

Elaichi does, because both clients speak the same remote MCP and the same OAuth sign-in. An engineering team adds one address to each agent, and one set of rules covers both.

That address is the one the rest of the company uses. Clients point at it and sign in: Claude, ChatGPT, Cursor and any MCP client. The setup differs per client, not the URL. The Claude Code setup and the ChatGPT setup use it unchanged.

Where do Jira, Slack and GitHub fit in a Codex setup?

Jira and Slack go through Elaichi, and GitHub does not. An admin or engineer connects each SaaS account once, from a catalog of 600+ connectors that Elaichi serves, most of which it writes itself. A separate credential service holds each account's secrets, encrypted at rest, so no Jira or Slack token sits in an environment variable. Replacing personal MCP servers on laptops covers the cleanup of tokens already out there.

No shared service account is needed. Each engineer's own grant authorizes their calls, and the audit trail names them. A shared Jira connection still reaches Jira as the account that connected it. Where Jira's own permissions must be the engineer's, each engineer connects their own account. The Jira connector and the Slack connector list every tool a rule can name.

GitHub is not in Elaichi's connector catalog. GitHub's guide for Codex (checked October 2026) adds GitHub's own server with a personal access token in bearer_token_env_var. Calls to it skip Elaichi's restrictions and audit trail.

What goes wrong when Codex connects to Elaichi?

Most failures are the URL, an expired request or a missing checkbox. Each has a quick fix:

• Sign-in never starts. Check the URL for a trailing slash or the app host. With no browser, sign-in cannot finish.
• The consent screen says the request is no longer valid. It expired or was used. Run codex mcp login elaichi again.
• A tool error names a checkbox. Run codex mcp logout elaichi, then log in again and tick the box.
• The list is empty for a whole role. The role may lack tool:execute, which an admin fixes.
• A 429 mid-task. Elaichi allows 120 MCP requests a minute per token. Wait a minute.

What each OAuth error means covers the rest, with who fixes each one.

How do you disconnect Codex from Elaichi?

Log out in Codex, then end the grant in Elaichi. codex mcp logout elaichi removes the OAuth credentials Codex stored for the server. To be sure the grant has ended, disconnect it in Elaichi under Settings, then Connected apps. When an admin removes or suspends a member, removing or suspending a member revokes every live grant in the same transaction as the membership change, so that engineer's next Codex call fails.

When does a Codex user not need Elaichi?

When one engineer uses Codex against one app they own. That app's own MCP server, signed in with OAuth, is enough. Revisit when a second app arrives, a contractor joins, or someone asks which agent changed a ticket. When you don't need an MCP gateway yet lists the signals.

Gold lists at $15 per user per month in USD, and the pricing page shows your region's price. Gold starts with a 14-day trial, no credit card to start. Checkout does collect a card, and it sets the paid trial to the remaining days rather than granting a fresh 14, so it is one continuous trial rather than two. For the wider picture, read what an MCP control plane is.

FAQ

Is there an MCP gateway that supports Claude Code and Codex for engineering teams?

Elaichi serves one organization-wide MCP endpoint over Streamable HTTP behind OAuth, and both Claude Code and Codex connect to it. Each engineer adds https://api.elaichi.ai/mcp once and signs in as themselves. Roles, restrictions and one audit trail then apply to both agents, because both reach company apps through the same address.

Does one MCP server URL work in Claude, ChatGPT, Cursor, Claude Code and Codex?

Yes, with Elaichi. Its endpoint, https://api.elaichi.ai/mcp, is the same for every client and every member of the organization. Each client adds it once, and each person signs in with their own OAuth grant. The address never changes, and only the grant behind it differs.

How do you give Codex access to SaaS apps without a shared service account?

Point Codex at one endpoint that each engineer signs in to with their own OAuth grant. With Elaichi, that grant authorizes every call, the audit trail names the engineer, and removing the engineer ends the grant without touching anyone else. Where the app itself must see the engineer, each engineer connects their own account once.

Can Codex use Elaichi in CI?

Not unattended. Elaichi's sign-in needs a browser, so a Codex run in CI or in a terminal with no access to a browser cannot complete it. Engineers sign in on their own machines, where a browser can open.

Is it safe to commit an Elaichi entry to .codex/config.toml?

Yes. The entry holds a public URL and nothing else: no token, no header and no client secret. Codex reads a project's .codex/config.toml only in trusted projects, and each engineer still signs in as themselves.

A platform team rarely gets to pick one editor. Half the engineers run GitHub Copilot in agent mode inside VS Code, and the other half run Windsurf. Both agents want Jira, Slack and Sentry. The vendor examples show the usual answer. Windsurf's MCP docs configure a Slack server with a SLACK_BOT_TOKEN in its env block. VS Code's reference shows an Authorization header. Forty engineers and four apps means a lot of tokens in a lot of dotfiles.

How do you connect Elaichi to VS Code and Windsurf without personal API keys?

To connect Elaichi to VS Code and Windsurf, point both editors at one URL, https://api.elaichi.ai/mcp, and have each engineer sign in with OAuth. The config entry holds no key, no header and no client ID. That is how Windsurf and VS Code Copilot reach internal tools without a personal API key on any laptop.

MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. Elaichi serves every connected SaaS account through one organization-wide endpoint, POST /mcp, behind OAuth (a sign-in standard that issues each person a grant instead of a shared password). VS Code Copilot and Windsurf (Devin Desktop) both connect to it.

Sign-in needs a browser. An editor agent or CLI running headless in CI cannot complete it, so plan on interactive use only.

How do you add Elaichi to VS Code?

Run MCP: Add Server from the Command Palette, or add one entry by hand. The guided flow offers .mcp.json, a portable file at the workspace root, or Copilot Global, saved in ~/.copilot/mcp-config.json by default. VS Code's docs say to prefer those portable destinations for new servers (VS Code MCP servers, checked October 2026).

The portable format keeps servers under mcpServers, and the configuration reference lists two required fields for a remote server, type and url:

{
  "mcpServers": {
    "elaichi": {
      "type": "http",
      "url": "https://api.elaichi.ai/mcp"
    }
  }
}

The older .vscode/mcp.json file uses a top-level servers key instead. Leave out headers, and leave out the oauth block too. That block exists to supply a client ID, and Elaichi needs none, because clients register themselves through dynamic client registration (RFC 7591).

Copy the URL exactly. With a trailing slash the endpoint returns 404, and on app.elaichi.ai it returns 405. Neither starts sign-in. A workspace .mcp.json inherits Workspace Trust, so the server starts once the engineer trusts the repository.

What does a VS Code engineer see at sign-in?

A browser window opens on Elaichi's sign-in, then its consent screen. VS Code's security page says it "implements the MCP authorization specification" for OAuth between VS Code and outside services (VS Code security).

On Elaichi's consent screen, the engineer picks one organization. Then come up to four checkboxes: read data, create and change data, run connected tools, and delete data. Everything requested starts ticked except delete, which never does. Keep Run your connected tools ticked, or the agent reaches no connected app. The request lasts 30 minutes and works once.

To confirm, select Configure Tools in the chat input. If the server fails to start, run MCP: List Servers, pick it and choose Show Output for its logs. Expect a short list. In Elaichi, connected tools are never listed one by one, however few there are. Copilot calls search_tools to find a Jira or Slack tool, then execute_tool to run it.

That shape matters for one VS Code limit. A chat request can have at most 128 tools enabled (VS Code tools), and connected apps add nothing to that count. VS Code may also ask the engineer to confirm tool calls. Every connected app runs through execute_tool, so a prompt on it covers every app. Keep the per-tool decisions in Elaichi's restrictions.

How do you add Elaichi to Windsurf?

Add one entry with url to the MCP config file. Windsurf is named Devin Desktop (Devin Desktop), and it has two agents. Devin Local is the default for new tabs, and Cascade is the legacy agent.

Both agents' docs put the user file at ~/.config/devin/mcp_config.json, or %APPDATA%\devin\mcp_config.json on Windows. Cascade accepts serverUrl or url for a remote server (Cascade MCP docs). Devin Local reads the Devin CLI files, where url is the required field (Devin CLI MCP configuration). So this entry fits both:

{
  "mcpServers": {
    "elaichi": {
      "url": "https://api.elaichi.ai/mcp"
    }
  }
}

In Cascade, open the file from the ... menu at the top right of the Cascade panel, then Open MCP config file. For Devin Local, a project's .devin/mcp_config.json is shared through version control. With Devin CLI installed, devin mcp add -s user elaichi https://api.elaichi.ai/mcp writes the user entry for you.

What does a Windsurf engineer see at sign-in?

The same Elaichi consent screen, opened in the browser. Devin's docs say an OAuth server prompts for sign-in the first time it is used, and devin mcp login elaichi starts it directly. Devin's CLI docs say it registers itself through dynamic client registration, so nobody enters a client ID.

Each editor registers itself and signs in on its own, so an engineer signs in once per editor.

To confirm, open the MCPs section of Cascade's ... menu, which shows each server and its enabled tool count. With Devin CLI, devin mcp list shows the configured servers. When stored sign-in credentials expire, the Devin Local MCP list shows Needs auth, and Authenticate runs the browser flow again.

Two Windsurf limits apply. Cascade has a limit of 100 total tools at a time, and Elaichi's connected apps add nothing to it. Devin Local asks for approval before any MCP tool call by default. A permission rule on mcp__elaichi__* covers every connected app at once, because every app runs through execute_tool.

How do you stop engineers pasting personal API keys into editors?

Give them a config with nothing to paste, then close the side door. A committed .mcp.json and .devin/mcp_config.json each hold a public URL and no secret. Every clone carries the same entry, and each engineer still signs in as themselves.

The app credentials live in Elaichi, not on laptops. A member connects each SaaS account once, from a catalog of 600+ connectors served through Elaichi. A separate credential service holds each account's secrets, encrypted at rest.

Then use each editor's policy so personal servers stop running:

• VS Code. The ChatMCP policy can limit MCP servers to a curated registry or turn MCP off. Copilot Business and Enterprise organizations can also set MCP access in GitHub organization settings (VS Code AI settings).
• Windsurf. Once a team admin allowlists one server, every server not on the list is blocked. The allowlist's Server ID must match the entry's key, so name the entry elaichi in every file.

Editor policy decides which servers may run. It cannot see inside Elaichi, so it cannot tell a Jira read from a Jira delete. OAuth versus API keys for AI agents covers the wider case against long-lived keys, and replacing personal MCP servers on laptops covers the cleanup.

Which admin controls cover Claude, ChatGPT, Cursor and both editors?

Elaichi's, because they sit at the endpoint every client shares. Claude, ChatGPT, Cursor, VS Code and Windsurf all reach the same address, so one set of rules governs them.

• Roles. Each member holds exactly one role, and a role without tool:execute reaches no connected tool.
• Restrictions. They decide 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. A change takes about two minutes to apply.
• Audit log. Elaichi writes one entry for each connected-tool call that reaches execution (a call refused earlier writes none), naming the engineer and the account the call reached. Each entry records the surface and the OAuth client. VS Code's vscode.dev redirect forwards the code to whatever the request names, so Elaichi cannot verify the client name. Its calls show the name VS Code registered with, marked unverified.
• Revocation. In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change, so that engineer's next call from either editor fails.

MCP for coding agents across an engineering org goes further into frozen arguments and team rollouts.

Which errors come up most in VS Code and Windsurf?

Most failures are the URL, an expired request or a missing checkbox. Each has a quick fix:

• Sign-in never opens. Check for a trailing slash or the app host. Devin CLI retries over SSE after a 404 or 405, so a wrong URL there can surface as an SSE error.
• The consent screen says the request is no longer valid. It expired or was used. Start the sign-in again from the editor.
• A tool error names a checkbox. Reconnect and tick it. In Windsurf, run devin mcp logout elaichi, then devin mcp login elaichi.
• The list is empty for a whole role. The role may lack tool:execute, which an admin fixes.
• A 429 mid-task. Elaichi allows 120 MCP requests a minute per token. Wait a minute.

What each OAuth error means lists who fixes each one, and the missing-tools checklist walks an empty list in order.

When is Elaichi more than an editor team needs?

When one engineer uses one app that runs its own OAuth MCP server. That server is enough until a second app, a contractor or an audit question arrives. When you don't need an MCP gateway yet lists the signals.

GitHub is not in Elaichi's connector catalog. VS Code's own docs use GitHub's server as their example, and that server sits beside Elaichi, outside its restrictions and audit log.

Gold lists at $15 per user per month in USD, and the pricing page shows your region's price. Gold starts with a 14-day trial, no credit card to start. Checkout does collect a card, and it sets the paid trial to the remaining days rather than granting a fresh 14, so it is one continuous trial rather than two. The same address works in the Cursor setup, the Claude Code setup and the Codex setup. For the wider picture, read what an MCP control plane is, or start from the Jira connector and the Slack connector.

FAQ

How do you give Windsurf and VS Code Copilot access to internal tools without personal API keys?

Connect each app once in Elaichi, then point both editors at Elaichi's endpoint, https://api.elaichi.ai/mcp. Each engineer signs in with OAuth in the browser, so the config file holds only a URL. The app credentials stay in Elaichi's credential service, encrypted at rest, and never reach a laptop.

What admin controls does IT get for MCP connectors across Claude, ChatGPT and Cursor?

With Elaichi, one set: roles decide what each person may do, restrictions decide which connectors and individual tools a role or user may reach, and the audit log records each tool call that reaches execution, with the person and the account it reached. All of it applies at the one endpoint every client uses, so Claude, ChatGPT, Cursor, VS Code and Windsurf share the same rules.

How do you stop employees from sharing personal API keys with AI tools?

Remove the reason to have one. Give each AI client a config that holds only an OAuth-protected URL, connect the apps once in a control plane such as Elaichi, and use the client's own policy to stop other servers from running. VS Code has an MCP access policy, and Windsurf has a team allowlist that blocks every server not on it.

Can VS Code or Windsurf use Elaichi in CI?

No. Elaichi's sign-in needs a browser, so an editor agent or CLI running headless in CI cannot complete it. Each engineer signs in from a machine where they can open the browser.

Why do VS Code and Windsurf show only a few Elaichi tools?

In Elaichi, connected tools are never listed one by one, however few there are. The agent finds a connected tool with search_tools and runs it with execute_tool, so a short list is expected. It also means adding Jira, Slack or Sentry adds no tools to the editor's tool count.

Docker MCP Gateway vs a managed MCP platform: which fits a whole company?

Docker MCP Gateway vs a managed MCP platform comes down to who runs the servers. Docker's gateway runs MCP servers as containers on a machine you operate, usually a developer's laptop. A managed MCP platform such as Elaichi serves the connectors itself, so staff in support, finance and sales connect an AI client and sign in.

The request usually starts in engineering. A few developers switched on Docker's MCP Toolkit and gave Cursor a GitHub tool. It worked, so IT is asked whether the same setup can serve the whole company. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. The answer turns on whether the people asking can run containers, and whether you need one record of every call.

What is Docker's MCP Gateway, in Docker's own words?

It is an open source proxy that starts MCP servers in containers and routes client requests to them. Docker's MCP Gateway page (checked October 2026) describes it as a centralized proxy that manages configuration, credentials and access control.

Three parts work together, per Docker's MCP Catalog and Toolkit overview (checked October 2026). The MCP Catalog lists 300+ verified servers packaged as container images. The MCP Toolkit is the Docker Desktop interface for adding servers and connecting clients. Underneath, the gateway starts a server's container when a tool is called, injects credentials and forwards the request.

The code is MIT-licensed in the docker/mcp-gateway repository. Docker's profiles page marks profiles as Early Access on Docker Desktop 4.63 or later, and the Toolkit and Catalog as Beta (both checked October 2026).

Where does Docker's gateway run, and who keeps it running?

It runs wherever Docker runs, and someone on your side operates it. With the MCP Toolkit enabled, it runs in the background in Docker Desktop. On Docker Engine alone, you install the binary yourself (MCP Gateway docs, checked October 2026).

The default transport is stdio, which is local to the client that launched the gateway. Docker's gateway guide on GitHub also shows it under Docker Compose, serving several clients over HTTP on any Docker engine. Per Docker's security model, those HTTP requests need a Bearer token by default, set in an environment variable or generated (both checked October 2026).

So a company gets two shapes: a gateway on each laptop, or a shared one on a server. The first means one configuration per machine. The second means one token that every client presents.

How does Docker's gateway handle secrets and OAuth?

Credentials stay with the Docker installation that runs the gateway. API keys go into Docker Desktop's secrets store, or a local .env file as a fallback. Docker's security model says each server receives only the secrets it declares (checked October 2026).

For apps such as GitHub and Notion, the MCP Toolkit runs OAuth in the browser. It lists authorized services in an OAuth tab, where each one can be revoked. Docker's profiles page adds two details that matter for a rollout (both checked October 2026). OAuth credentials are shared across all profiles, so a second account means revoking and authorizing again. And a pushed profile carries no credentials, so each teammate configures OAuth after pulling it.

So each person authorizes each service in their own Docker installation, on whichever machine they use.

What do profiles, tool filters and call logs give an admin?

They give a developer, or a team sharing a profile, control over which tools are offered. A profile is a named set of servers whose Tools tab can switch single tools on or off. Teammates can pull a profile from an OCI registry (MCP Profiles, checked October 2026).

A custom catalog narrows Docker's list to approved servers and can add private ones (MCP Catalog, checked October 2026). Per the MCP Toolkit page, each tool runs in its own container, capped at 1 CPU and 2 GB of memory, with no host files unless the user grants a mount.

Call logging and secret blocking are on by default. Per Docker's security model, the call log holds the tool name and the shape of its arguments, never raw values. Docker's gateway page also says the gateway as part of Docker AI Governance is invite-only, through Docker Sales (all checked October 2026). Ask Docker what it adds.

What does a company-wide rollout to non-engineers need?

It needs one address, a personal sign-in, nothing to run, and rules an admin sets once. Here is how Elaichi meets each need for Claude, ChatGPT, Cursor and any other MCP client.

• One URL per organization. Every client connects to https://api.elaichi.ai/mcp, standard MCP over Streamable HTTP. The client registers itself through OAuth, so nobody types a client ID, secret or token.
• A personal sign-in. Each member connects once and signs in with their own OAuth grant, an access approval that belongs to that person.
• Connectors, not containers. Elaichi serves 600+ connectors, and authors and maintains most of them on its own infrastructure. A separate credential service holds account secrets, encrypted with AES-256-GCM, and owns token refresh.
• Roles and restrictions. Each member holds exactly one role. Restrictions decide which connectors and which individual tools a target may reach, for a role or one user. A change takes effect within about two minutes.
• Frozen parameters. An admin can fix an argument so the model cannot change it. Note that a freeze binds only calls made through its toolbox entry, so share the toolbox with the people it governs, not the connection itself.
• One audit log. It keeps one entry for each connected-tool call that reaches execution (a call refused earlier writes none). Each entry names the account reached and the AI client used, and stores the one path argument that names the object, as the target id, and nothing else about the arguments.
• Offboarding. Removal or suspension ends access on the next call. In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change.
• Region. Pick eu, us or apac when the organization is created; it is fixed afterwards. 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.

A restricted tool is withheld from the tool list and cannot be called. Search names it, flagged restricted, with no schema. Frozen arguments on a payment tool show the freeze in practice.

How do Docker's gateway and Elaichi compare, row by row?

Docker's gateway gives developers control of local runtimes; Elaichi gives admins control of company-wide access. The Docker column comes from Docker's documentation and its GitHub repository, both checked October 2026.

Managed MCP connectors vs open-source MCP servers: what changes for a company?

The difference is who writes, runs and repairs the code. With Docker's catalog, the code comes from many authors and your side runs it. With managed connectors, one vendor writes, runs and repairs them.

Docker's MCP Catalog holds Docker-built local servers, partner servers, and remote servers that run on the provider's infrastructure (checked October 2026). New servers are submitted through Docker's public registry repository on GitHub. That breadth is its strength.

Three things move for a company. Upkeep: an app's API change becomes the connector author's work, not your deploy. Rules: Elaichi pins each rule to the underlying operation, so renaming a tool does not slip it past a restriction. Record: every call that reaches execution lands in one audit log with one shape, whichever connector made it. The trade is that Elaichi, not you, fixes the connectors it authors. You can fork one as a custom connector if you need your own change. Registries and first-party connectors are compared in more depth elsewhere.

Is there a hosted MCP service for all our business apps, so we run nothing?

Yes, and that is the job a managed MCP platform does. Elaichi serves 600+ connectors, most of them from its own infrastructure and the rest from their vendors' own MCP servers, so there is no server, container or token to look after.

Check the catalog against your app list first. As of October 2026, GitHub is not in Elaichi's catalog. Jira, Slack, Salesforce and the Google Workspace apps are, and Datadog and Linear are there as their vendors' own MCP servers. For a missing app, use the app's own MCP server, or build a custom connector from JSON config. The connector catalog shows what is there.

Hosted also means someone else keeps tokens fresh. The refresh and credential costs are priced in that post.

When is Docker's MCP Gateway the better choice?

Choose Docker's gateway when the users are developers and the tools are local. In these cases Elaichi is the wrong fit, per Docker's catalog and gateway guide (checked October 2026):

• The tools touch the developer's own machine. A filesystem, a local database or a browser automation server belongs in an isolated container on that machine. Elaichi is hosted and does not run local tools.
• The work stays offline or inside your network. Docker says its local catalog servers work offline once downloaded.
• You want code you can read and run. Docker's gateway is MIT-licensed open source.
• Agents run unattended. Elaichi's sign-in needs a browser, so a headless agent in CI cannot complete it. Docker's guide shows the gateway under Docker Compose for other services to use.
• The app is GitHub. Docker's catalog lists it, and Elaichi's catalog does not.

Can you run Docker's gateway and Elaichi side by side?

Yes, and the clean split is by audience and by where the tool runs. Developers keep Docker's gateway for local, container-isolated tools. Everyone, developers included, reaches the company's SaaS accounts through Elaichi.

In Cursor, that means two entries: the Docker gateway for local tools, and Elaichi's URL for Jira, Slack and Salesforce. Keep each business app in one place only. If Salesforce is reachable through both, Elaichi's restrictions and audit log miss the path through the laptop. Finding personal MCP servers on laptops covers the inventory step.

Which questions should you ask Docker before a company rollout?

Ask the questions a rollout to non-engineers depends on, and get the answers in writing. Docker's MCP Toolkit and gateway repository describe developer workflows (checked October 2026). Five questions close the gap:

1. How does an employee without Docker Desktop, on a managed laptop, connect Claude or ChatGPT?
2. On a shared gateway with one Bearer token, how is each call tied to a named person?
3. Where does an admin see every call from every machine in one log, and what does Docker AI Governance add?
4. When someone leaves, how are the OAuth authorizations on their machine revoked, and how fast?
5. Can a rule fix an argument's value, not only switch a tool on or off?

Put the same five to Elaichi. The full cost of running MCP servers yourself prices the self-run side, cloud API gateways with MCP are another option, and team-by-team starting points show where to begin.

FAQ

Docker MCP Gateway vs a managed MCP platform: which is better for a company?

It depends on who will use it. Docker's MCP Gateway runs MCP servers as containers on a machine you operate, which suits developers who already run Docker Desktop (Docker docs, checked October 2026). A managed MCP platform such as Elaichi serves the connectors itself behind one organization-wide URL, and each employee signs in with their own OAuth grant. For staff in support, finance or sales, Elaichi also gives admins per-tool restrictions, frozen parameters and one audit log. Removing a member cuts their access on the next call.

Should a company use managed MCP connectors or open-source MCP servers?

Use open-source MCP servers when developers need local tools, want to read the code, and can run and patch it themselves. Use managed connectors when many non-engineers need the same SaaS apps. Then one vendor writes, hosts and repairs the connectors, holds the credentials, and records each call that reaches execution in one audit log. Elaichi is a managed option: it authors most of its connectors and governs vendors' own MCP servers for the rest, so nobody at the company runs a server or a container.

Is there a hosted MCP service for all our business apps so we do not have to run servers?

Yes. Elaichi serves its connectors behind one URL, https://api.elaichi.ai/mcp, so there is no server, container or token to host. Claude, ChatGPT, Cursor and any other MCP client connect to it, and each person signs in once. Check the catalog against your app list first: as of October 2026, GitHub is not in it, while Jira, Slack, Salesforce, the Google Workspace apps, and Datadog's and Linear's own MCP servers are.

Can Docker MCP Gateway and Elaichi be used together?

Yes. A clean split gives developers Docker's MCP Gateway for local, container-isolated tools such as a filesystem or a browser automation server, and gives everyone Elaichi for the company's SaaS accounts. Keep each business app in one place only, so restrictions and the audit log cover its calls.

A support lead in Munich wants Claude on the help desk. A finance team in Dublin wants ChatGPT on the accounting system. The data protection officer asks whether customer data stays in the EU. A US company with EU customers hears the same question in every security review.

What does EU data residency for AI agents actually cover?

EU data residency for AI agents is three promises, made by three different vendors. The SaaS app keeps its records where its vendor hosts them. The control plane between the agent and the app keeps its own records. The model provider processes the prompt and every tool result the agent reads. Each leg has its own region setting, and no single setting covers all three.

MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. Elaichi is a governed MCP control plane. Each SaaS account is connected once, and its tools are served through one organization-wide endpoint, the single address every AI client points at: https://api.elaichi.ai/mcp. Claude, ChatGPT, Cursor and any other MCP client all use it. Each member signs in with OAuth, which gives the client a revocable grant instead of a password.

This post describes the mechanism, not the law. For the legal reading, start with the regulation. Chapter V allows a transfer to a third country only when its conditions are met (GDPR Article 44, EUR-Lex). Article 28 requires a binding contract with every processor. The European Data Protection Board's Recommendations 01/2020 cover the measures that supplement transfer tools. A map of the legs is where that work starts.

How do we keep data in the EU when employees use AI agents on SaaS tools?

Pin each leg separately, then write down the legs you cannot pin. No vendor owns all three legs, so no vendor can do this for you. Work in this order:

1. The app. Check where each SaaS vendor hosts your tenant. If the help desk tenant sits in the US, no agent setup moves it.
2. The model provider. Check which region the AI client offers for prompts, conversations and inference on your plan. Tool results enter the model's context, so whatever the agent reads is processed here.
3. The control plane. Choose a vendor whose region covers its own records: who connected what, which rules apply, and the log of each call that reaches execution. In Elaichi, that is the eu region.
4. The gaps. List every leg that is not pinned, with the safeguard your lawyers rely on for it. Article 46 names standard contractual clauses as one such safeguard (GDPR text).

The fourth step carries the most weight. A rollout can include a leg outside the EU, but not one nobody wrote down.

Which leg does Elaichi's eu region cover?

The control plane leg, and no other leg. In the eu region, the organization's data store and the execution of its org-scoped requests and tool calls are pinned to the EU. Elaichi has three regions, eu, us and apac, chosen when the organization is created and fixed afterwards. The eu region is available on every plan.

The data store. Elaichi keeps one data store per organization, and for an eu organization it is pinned to the EU. It holds the members, teams, roles, sharing grants, connection records, toolboxes, restrictions, access requests, OAuth grants and Elaichi Agent conversations.

The credentials. Connections created since 2026-10-05 have their credentials placed in the organization's region, inside the EU for an eu organization. Older connections stay where they were until they are reconnected, which copies them into the region. Credentials are encrypted at rest with AES-256-GCM, and each ciphertext records the ID of the key that wrote it, so keys can be rotated.

The execution. Requests and tool calls that act inside an eu organization run in the EU. That covers the REST API inside the organization, POST /mcp, SCIM, file downloads, invites and OAuth callbacks. Requests that do not act inside an organization run at the edge, wherever the request lands. Those are sign-in and sign-up, a person's own profile, creating and listing organizations, OAuth server endpoints and webhook intake.

The audit trail. Every organization's audit trail, whatever its region, is stored in one log instance in the EU (see the privacy policy). An eu organization's records go only to the EU endpoint.

Stored tool files. Files Elaichi keeps from tool results go to one private bucket in the EU for every organization, whatever its region.

Kept globally. User accounts, the organization record, sign-in sessions, API tokens, SSO settings and MCP OAuth token records are global stores, not part of the EU region. List them in your vendor review and your transfer records.

The region is fixed at creation, so choose it before the first member joins.

Read the region as a statement about the control plane, not about every system in the path. The model provider and the app are separate legs.

Where does the model provider process the prompt?

Wherever the AI client's vendor processes it, under that vendor's settings on your plan. Elaichi has no say in it.

Anthropic's API documentation lists two inference geographies, global and us, and says workspace geo, where data is stored at rest, is us only (Anthropic data residency, checked October 2026). This covers the Claude API. Ask Anthropic separately about Claude Team or Enterprise workspaces. On Amazon Bedrock and Google Cloud, the same page says, the endpoint sets the region. Claude also reaches a custom connector from Anthropic's cloud, not from the user's device, on every Claude client.

OpenAI offers European data residency for new ChatGPT Enterprise and Edu workspaces and for new API Projects (OpenAI, data residency in Europe, checked October 2026). Its help center lists Europe as an inference residency region for eligible ChatGPT Enterprise and Edu customers. The same page excludes data processed outside OpenAI's infrastructure "through external integrations (e.g., Apps & MCP, Web Search, if enabled)" (OpenAI Help Center, checked October 2026).

That exclusion is why the MCP leg, where the agent reaches your apps, needs its own answer.

The Elaichi Agent, which works inside the app, is the one place where you choose the model leg yourself. Its model access is bring-your-own-key only. An admin sets a key for Anthropic, OpenRouter, Fireworks, or an OpenAI-compatible gateway at a base URL the admin enters. So a team can use a provider endpoint whose processing location it already has under contract.

Why does the control plane leg matter if it is only one of three?

It holds the records a regulator or a customer asks about first: who reached what, through which account, and when. It also holds the credentials and runs the calls. Those records describe your people and your customers' accounts, even without the payload.

The audit trail. Elaichi writes one entry for each connected-tool call that reaches execution (a call refused earlier writes none), and each names the account the call actually reached. Of the arguments, it keeps the one path argument that names the object, as the target id, and nothing else about the arguments. The error text in the trail is never derived from the third party's response, so a remote error body cannot carry customer data into the log. Every region's audit trail is stored in one EU log instance, with each organization's records kept apart, and a free read-only Auditor seat can review it. Beyond the in-app trail, export to your own Datadog comes with the Black plan, which is launching soon.

What the agent can reach. Restrictions decide which connectors and which individual tools a target may reach. They are enforced on the server, not left to the model. A tool you withhold keeps its schema out of the model's context, so this leg also shrinks what the model provider receives.

Credentials. Connector credentials never live in the organization store. A separate credential service holds them, encrypted with AES-256-GCM, and owns refresh. Connections created since 2026-10-05 are placed in the organization's region. A connect URL is a one-time session that carries no token.

Deletion. Deleting an organization tears down the rest of the workspace and deletes every connected account's credential. Three stores keep residue: the audit history, the analytics events, and the credential service's organization, environment and installed-connector configuration rows. Elaichi has no purge path for them and returns that residue by name. Deletion does not purge the audit history. Each record ages out under the log server's 90-day retention, counted from when it was written. Describe it that way in an erasure answer, with all three stores named.

Is there an enterprise MCP platform with EU data residency?

Yes. Elaichi offers it for the control plane leg, on every plan. Choose eu when the organization is created. The data store and the execution of its org-scoped requests and tool calls are then pinned to the EU, and the audit trail is stored there. User accounts and sign-in sessions are kept globally. The model provider and the apps keep their own regions.

One address serves every client, so there is no per-team or per-user server to place in a region. Elaichi authors and serves most of its connectors from its own infrastructure, and the rest are vendors' own MCP servers, so you do not run MCP servers in your own EU cloud.

SAML and OIDC sign-in are built in-house, with SCIM v2 provisioning and group-to-role mapping. A role or restriction change takes effect within about two minutes. Offboarding holds on the next call: removing or suspending a member revokes every live grant in the same transaction as the membership change.

Where do I check Elaichi's compliance statements?

Check the Trust Center at trust.elaichi.ai, the page Elaichi points to for what it attests. Attribute any SOC 2 or HIPAA statement for a compliance file to that page. For the control mapping, see SOC 2 evidence for CC6 and CC7. For ChatGPT, OpenAI's residency excludes Apps and MCP, so the endpoint's region is a separate question. The ChatGPT setup guide covers connecting that endpoint.

When does Elaichi's eu region not solve the problem?

When the leg that breaks your policy is not the control plane. Elaichi's region cannot move a model, an app tenant or a retention clock.

• Your policy requires EU inference for Claude through Anthropic's API. Anthropic's page lists global and us as the geographies (checked October 2026). The region is chosen at the provider, for example through a cloud endpoint, not in Elaichi.
• The app tenant is hosted outside the EU. Moving it is a conversation with that vendor.
• An erasure deadline requires everything purged on request. Three stores survive organization deletion: the audit history, the analytics events, and the credential service's organization, environment and installed-connector configuration rows. Deletion does not purge the audit history. Each record ages out under the log server's 90-day retention, counted from when it was written.
• No AI client points at company data. Then the work is policy first, as laid out in when you may not need an MCP gateway.

For what a good record should hold, see what an AI audit log must capture. For the wider category, start with what an MCP gateway is, and browse the 600+ connectors at /connectors/.

FAQ

Is there an enterprise MCP platform with EU data residency?

Elaichi offers EU data residency for the control plane, on every plan. An organization created in the eu region has its data store and the execution of its org-scoped requests and tool calls pinned to the EU, and its audit trail is stored there. User accounts and sign-in sessions are kept globally. Claude, ChatGPT, Cursor and any other MCP client reach the apps through one endpoint, https://api.elaichi.ai/mcp, under roles, restrictions and an audit log. The model provider and each SaaS app keep their own region settings, which Elaichi does not control.

How do we keep data in the EU when employees use AI agents on our SaaS tools?

Pin each leg of the data path separately. Check where each SaaS vendor hosts your tenant. Check which region the AI client's vendor offers for prompts, conversations and inference on your plan. Choose a control plane with an EU region for its own records. Then document every leg you could not pin, with the transfer safeguard your lawyers rely on for it. No single vendor setting covers all three legs.

Does choosing an EU control plane keep prompts in the EU?

No. The prompt, the conversation and every tool result the agent reads are processed by the model provider, such as Anthropic or OpenAI, under that provider's own region settings. An EU control plane such as Elaichi's eu region pins the organization store and the execution of its org-scoped requests and tool calls to the EU, and stores the audit trail there. It cannot move inference.

Can an existing Elaichi organization move to the eu region?

No. The region is chosen when the organization is created and is fixed from then on. The choices are eu, us and apac. The eu region is available on every plan. For EU and US, the data store and the execution of the organization's org-scoped requests and tool calls stay in that jurisdiction. APAC uses best-effort placement and is not a residency guarantee. So an EU commitment needs the eu region from day one.

How do you get human approval for AI agent actions like CRM writes and email?

Human approval for AI agent actions comes in two kinds. The first is a prompt in the AI client, answered by the person who asked. The second is a decision an admin makes ahead of time about which roles may run the write at all. Elaichi handles the second kind, and its audit log records how each call was approved.

A RevOps lead sees the request coming. Reps want Claude to update close dates in Salesforce and to send follow-up email from Gmail. The lead wants a person to sign off before either happens. Security wants the same thing, written down somewhere an auditor can read.

MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. Elaichi serves every connected app through one organization endpoint, the single address each client signs in to. Claude, ChatGPT, Cursor and any other MCP client all use it. The MCP specification asks for a human in the loop who can deny a tool call. It also says servers must implement proper access controls. Approval needs both halves, and they live in different places.

What does an approval prompt in Claude, ChatGPT or Cursor check?

It checks with the person in front of the client, at the moment of the call. That is useful, and it is not a second pair of eyes. The approver is the same person who asked for the action.

Each client handles it differently (all checked October 2026):

• Claude. Each connector has tool permissions set to Always allow, Needs approval or Blocked, per tool or per group (Claude Help Center). On Team and Enterprise plans, owners can restrict a connector's tool actions for the whole company, and members cannot override that.
• ChatGPT. For a write, ChatGPT may ask for confirmation, depending on the app's permissions and the context. Some risky actions are refused rather than offered for approval (OpenAI Help Center).
• Cursor. "Cursor asks for approval before using MCP tools by default" (Cursor docs). In its Auto-review mode, allowlisted tools run without asking, and Enterprise admins can limit which tools may run automatically.

There is one catch with Elaichi behind any of them. In Elaichi, connected tools are never listed one by one, however few there are. The model finds a tool with search_tools and runs it with execute_tool. A client permission therefore names execute_tool, so one setting covers a Salesforce read and a Gmail send alike. The real tool name sits inside the call's arguments.

A client prompt suits a careful person double-checking their own request. It is not a second person's decision on that call.

Does the Elaichi Agent ask before it writes?

Yes. In the Elaichi Agent, a write stops at an approval card before it runs. The card offers Deny, Allow once and Always allow. The person can also edit the arguments first, and the button then reads "Save & allow once".

Deletes get stricter treatment. Always allow is offered for writes only, so a delete asks every time. Always allow is remembered per person and per operation.

Calls from Claude, ChatGPT or Cursor take a different route. Over MCP, Elaichi cannot put an approval step in the client's own window. So the approval is the OAuth grant (the permission a person gives a client at sign-in). On Elaichi's consent screen, the person ticks what the client may do. "Create and change data" covers writes, and "Delete data and remove access" is never ticked in advance. Without the write box, a client cannot change Elaichi's own records. A connected app's create and update tools ride on "Run your connected tools", and only its deletes need the delete box. Holding a connected app to reads is a restriction on the role, not a consent checkbox.

Both routes still ask the person who started the request. The layers below are the ones an admin holds.

How do you take a write away from a role?

Write a restriction. A restriction decides 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. Restrict the write on the Sales role, and no rep's client is offered it again.

For a sales team, the rule names four tools. update_a_salesforce_opportunity_by_id changes close dates, stages and amounts. create_a_gmail_message sends a message straight away, and gmail_drafts_send sends a saved draft. create_a_gmail_batch groups Gmail requests, including sends, into one call. Reads stay, and so does create_a_gmail_draft.

That is the answer to read but not delete or send. Restrict the send and delete tools by name, and keep the reads. A restricted tool is withheld from the tool list and cannot be called. Search names it, flagged restricted, with no schema. A block always beats an allow.

Here, the draft is where the human approval happens. The agent writes the email into Gmail. The rep reads it there and presses send. While the send tools are restricted, the agent cannot send. It can only save a draft. No setting in a client can skip that step.

This follows OWASP's guidance on excessive agency. It advises putting authorization in the downstream system, not in the model's judgment. Its mailbox example makes the same cut: read, do not send. A saved restriction reaches every surface within about two minutes. Restricting one tool or the whole app covers when to name tools and when to name the connector.

Can you narrow a write instead of removing it?

Yes, with frozen parameters. A frozen parameter is a value an admin fixes on one tool inside a toolbox, a saved set of tools paired with connected accounts. Elaichi removes the field from the schema the model sees. It then writes the frozen value over the call's arguments, so sending the field anyway changes nothing.

Take a support team that hands leads to sales and holds no Salesforce login. RevOps connects its own Salesforce account and keeps that connection unshared. It pins create_a_salesforce_task into a toolbox and freezes the owner field to the deal desk's Salesforce user, using the field name from the tool's schema. It then shares the toolbox with the support team at use. Every task the support team's agent creates lands with the deal desk. The write itself becomes the request for a person to look.

A template carries the same tool list, with renames, defaults and frozen values, and no account. In Elaichi, a freeze binds only calls made through its toolbox entry, so share the toolbox with the people it governs, not the connection itself. A rep with their own Salesforce connection reaches the same tool unfrozen. Locking a tool argument works the payment version through.

What happens when someone needs a restricted tool?

They file an access request, and someone else decides it. Any member can file one with no permission needed. Resolving it needs member:manage, which People Admin, Org Admin and Org Owner hold. An admin cannot decide their own request.

Approving a request caused by a restriction creates an access grant for that one requester. A rep restricted through the Sales role has that one tool lifted out of their role rules, so the role's other rules still bind them and nobody else changes. No rule is written and the role is not edited. Like any restriction change, it reaches every surface within about two minutes.

Two limits keep this honest. First, no access request can be approved or denied from the Elaichi Agent or an MCP client. Restrictions stay read-only on every AI surface, so a model cannot approve its own access. Second, an approval is a standing grant, not approval of one call. It lasts until the member is removed or an admin approves a replacement.

What does the audit log show after the fact?

Every call that reaches execution, and how it got past the approval step. The audit log is the record Elaichi keeps of each action. It holds one entry for each connected-tool call that reaches execution (a call refused earlier writes none), naming the person, the client and the account reached.

Each tool call states its approval in plain words:

Elaichi logs the one path argument that names the object, as the target id, and nothing else about the arguments. So the log shows that an opportunity update ran, through which account. It does not show the new close date. Give the reviewer an Auditor seat, which is read-only, cannot call tools and costs no license. What an AI audit log must capture covers the full record.

How does the setup look for a sales team?

Two roles, four restricted tools and one review habit. Each member holds exactly one role, so a role describes a whole job. Custom roles are a Gold feature.

Set it up in this order:

1. Create both as custom roles carrying Member's permissions, including tool:execute.
2. Restrict update_a_salesforce_opportunity_by_id, create_a_gmail_message, gmail_drafts_send and create_a_gmail_batch on the Sales role.
3. Have each rep connect Salesforce and Gmail under their own login. Each rep's own Salesforce permissions then apply to what they reach.
4. Wait about two minutes. Then, as a test rep, search for a restricted tool and confirm it comes back only by name, flagged restricted.
5. Each month, filter the audit log by the Salesforce connection and read the writes.

The same shape answers how to give sales, engineering and HR different AI tool access. Give engineering and HR their own roles and restrict the Salesforce connector for both. The CRM then cannot be reached from their clients. Designing roles for AI agents covers the role chain. For the full Salesforce tool list a sales role should lose, see the sales team playbook.

When is a client prompt enough?

When one team uses one client, and the source app already says no. A Claude Team owner can restrict a connector's tools for the whole company in Claude's own settings. If reps hold a read-only Salesforce profile, the write fails at Salesforce too. A restriction layer on top would add review work and little safety.

The admin layers earn their cost later. That point comes when more than one client reaches more than one app, and a reviewer asks who approved last Tuesday's change. The MCP control plane overview explains where Elaichi sits. The risks these layers answer are listed in the MCP security risks guide, and pricing has the price for your region.

FAQ

Can an admin approve AI agent actions before they run?

In Claude, ChatGPT and Cursor, an approval prompt goes to the person using the client, who is usually the person who asked for the action. In Elaichi, an admin decides ahead of time instead. A restriction takes a tool away from a role, and a member who needs it files an access request that someone with the member:manage permission approves or denies. Each call that reaches execution is then recorded in the audit log with how it was approved.

How do I let an AI agent read the CRM but not send email?

In Elaichi, write a restriction on the role that withholds the send tools, which for Gmail are create_a_gmail_message, gmail_drafts_send and create_a_gmail_batch, and leave the read and draft tools alone. A restricted tool is withheld from the tool list and cannot be called. Search names it, flagged restricted, with no schema. The person then reviews each draft in Gmail and sends it by hand.

Does a Needs approval setting in Claude work per tool through Elaichi?

Not per connected tool. Elaichi serves connected tools through two tools, search_tools and execute_tool, so a Claude tool permission on execute_tool covers every connected tool at once. Use the client setting as a prompt for the person in the chat, and use an Elaichi restriction on the role to decide which tools that role can reach at all.

Who can approve an access request in Elaichi?

Anyone whose role holds the member:manage permission, such as a People Admin, Org Admin or Org Owner, and never the person who filed it. Any member can file a request. Approving a request creates an access grant for that requester only, and lifts exactly the approved tool or connector out of their role rules. No access request can be approved or denied from the Elaichi Agent or an MCP client.

How do you give sales, engineering and HR different AI tool access?

In Elaichi, give each department its own role and write restrictions for each role. Each member holds exactly one role, so a rule on the Sales role reaches every rep and nobody else. Custom roles are a Gold feature. A role or restriction change reaches every surface within about two minutes.

Your platform team already runs Kong in front of the company's APIs, or your network sits on Cloudflare. Then operations asks for Claude to reach Salesforce, Jira, Slack and Google Workspace for three hundred people, most of them outside engineering. Both vendors document MCP features (Kong and Cloudflare, checked October 2026), so the Kong vs Cloudflare MCP gateway question looks like the whole decision. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps.

It is not the whole decision. The harder question is who writes the tools for each SaaS app, who signs each person in to it, and who keeps it working when the app changes. For the general gateway shape, this comparison of API gateways and MCP-native servers covers it. This post is the narrower buyer's version, for Kong and Cloudflare by name.

Kong vs Cloudflare MCP gateway, or a managed connector platform?

Pick Kong or Cloudflare when the tools are your own: APIs you already run, or MCP servers you write. Pick a managed connector platform such as Elaichi when the request is a list of SaaS apps and the people asking are not engineers.

The split follows from what each product starts with (vendor docs checked October 2026). Kong starts from your APIs and asks you to describe them as tools. Cloudflare starts from MCP servers, either ones you deploy on Workers or remote ones you add to a portal. Elaichi starts from the apps. It serves 600+ connectors, most of which it authors, through one organization-wide endpoint, https://api.elaichi.ai/mcp. An endpoint here is the one address every client points at.

Between the two, Kong fits when the tools are APIs you already run behind it, and Cloudflare fits when engineers build servers on Workers or put remote servers behind a portal. Cloudflare's gateway-style MCP product is MCP server portals.

None of these is better in general. Each fits a different upstream, and the sections below show where each one's work lands.

What does Kong AI Gateway do with MCP?

Kong AI Gateway turns APIs into MCP tools and proxies MCP traffic, inside a gateway your team operates. Kong's AI Gateway documentation (checked October 2026) says it "is managed through Konnect", with data plane nodes running "in your environment". It lists the job as "Turn existing APIs into tools an AI agent can discover and call over Model Context Protocol".

The building block is the AI MCP Server entity (checked October 2026). Kong's page says "Each tool needs at minimum a description and an HTTP method". Kong's API-to-tools tutorial has the reader write each tool's name, description, method and path, against the Swagger Petstore sample. The AI MCP Proxy plugin can also pass MCP requests through to an upstream MCP server. Kong marks that plugin "only available as part of our AI Gateway Enterprise offering".

Kong's access control is fine-grained. The proxy plugin evaluates allow and deny lists against Kong Consumers and Consumer Groups, at a default level and per tool. The AI MCP OAuth2 plugin (checked October 2026) validates tokens by introspection or JWKS. It also notes that "Access tokens are not forwarded to upstream services by default".

What does Cloudflare offer for MCP servers?

Cloudflare documents two MCP products that matter here: a place to run MCP servers you write, and a portal that puts several remote MCP servers behind one address. Cloudflare's remote MCP server guide (checked October 2026) deploys a server to a workers.dev subdomain. In its authentication example, "your users are redirected to GitHub to authenticate".

The second product is MCP server portals, part of Cloudflare Access in Cloudflare One. Cloudflare's MCP server portals page (checked October 2026) says a portal "centralizes multiple Model Context Protocol (MCP) servers onto a single HTTP endpoint". Users sign in through Access and "are prompted to authenticate separately to each server that requires OAuth". Admins choose and rename tools per portal, and Access logs each tool request.

The same page sets the limits. "Only remote HTTP MCP servers are supported", and "Each portal supports up to 80 MCP servers." An admin adds each server by its URL. So the portal works best when every app already publishes a remote MCP server, or when your team builds one on Workers.

Who writes the Salesforce, Jira and Slack tools on each path?

On Kong and Cloudflare, your side builds or adds the tools. On Elaichi, Elaichi writes and maintains most of the connectors, the app vendor runs the rest, and your side connects accounts.

With Kong AI Gateway, someone describes each tool: name, description, method and path, per endpoint, per app. When Salesforce changes an endpoint, that description is yours to fix. With Cloudflare, a Workers server is code your engineers write and deploy. A portal can instead front an app's own remote MCP server, such as Atlassian's for Jira or Slack's (both checked October 2026). Each one still needs adding, an OAuth setup and a check on its tool names.

Elaichi starts from the other end. It serves 600+ connectors and authors most of them, including Salesforce, Jira and Slack, and serves them from its own infrastructure. Google Workspace arrives as several connectors, such as Gmail, Drive and Calendar. A missing app can be a custom connector, written from JSON config or forked from a public one. Why first-party authorship matters covers the repair path in detail.

How does each path sign a person in to the SaaS app?

In Elaichi, each person signs in to each app with their own account, and a separate service holds and refreshes those tokens. On Kong and Cloudflare, the per-person path to the app is something you configure.

Kong's AI MCP Server page says that, by default, "AI Gateway proxies these requests without adding credentials", and config.upstream.auth sets what Kong adds. Kong's OAuth2 plugin can swap the client's token for another one before forwarding (both checked October 2026). Ask Kong which token endpoint would issue a per-person Salesforce token, and who registers that app. On Workers, Cloudflare's authorization docs (checked October 2026) say "the MCP Server (your Worker) generates and issues its own token to the MCP client" when a third-party provider signs the user in. Cloudflare's portal supports per-user OAuth to each upstream server through its "Require user auth" setting. With it disabled, users reach the server through its admin credential. Ask Cloudflare which account each tool call reaches in each mode.

In Elaichi, a Member can connect any catalog app with their own account unless a restriction stops it. Credentials live in a separate credential service, encrypted at rest with AES-256-GCM, and that service owns refresh. A failed refresh marks the connection needs_reauth, so the failure shows. An OAuth connector connects through a default OAuth app that every organization inherits unless it brings its own. Where none exists, the catalog marks the connector, and an admin with connector-management permission stores the organization's own client ID and secret first.

How do Kong, Cloudflare and Elaichi compare side by side?

They differ most on who supplies the tools and how a person reaches each app. Vendor columns come from Kong's AI Gateway docs and Cloudflare's portal docs, checked October 2026.

Can you connect a whole tech stack to AI assistants without building MCP servers?

Yes, if the platform already wrote the connectors. That is the case a managed connector platform is built for, and the case where a gateway leaves the most work on your side.

In Elaichi, an admin adds https://api.elaichi.ai/mcp once, each member signs in with their own OAuth grant, and members connect their apps from the catalog. On the other paths, you describe each tool in Kong, or add each server to a Cloudflare portal by its URL. The endpoint, sign-in and audit details are covered in the gateway comparison.

Two Elaichi points matter next to Kong and Cloudflare. Frozen parameters lock an argument, such as a Slack channel, so the model cannot change it. The model can still see a short frozen value in the tool description. One condition: a freeze binds only calls made through its toolbox entry, so share the toolbox with the people it governs, not the connection itself. And the organization picks a region, EU, US or APAC, when it is created. 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.

When is Kong or Cloudflare the better choice?

Kong is the better choice when the tools are your own APIs and Kong already fronts them. Cloudflare is the better choice when your engineers are building MCP servers and want them on Workers, or want one portal over remote servers they already trust.

With Kong, an internal order API becomes tools through an AI MCP Server entity, with Consumer allow and deny lists your team already knows how to review. With Cloudflare, an engineering team writing custom servers gets Workers hosting, OAuth options and Access in one account (checked October 2026). If your apps all publish remote MCP servers, a portal over them is a reasonable shape too.

Elaichi does not fit those cases well. It is not built to front a fleet of servers you run, and it governs an app's own MCP server only when that server is in its catalog or added as your own remote MCP connector. The cost of running your own servers is the honest test for the build path.

How does Elaichi run alongside Kong or Cloudflare?

Split by who owns the upstream: internal APIs stay behind Kong, servers your engineers write stay on Cloudflare, SaaS accounts go through Elaichi. Kong keeps request policy over APIs you deploy, and Cloudflare keeps hosting and Access for servers you build, so neither has to front Salesforce. The side-by-side split is covered in the gateway comparison.

To compare more shapes, read what an MCP gateway is, the shortlist of MCP gateways, or the Docker MCP Gateway comparison. To check your own stack, browse the connector catalog and the team rollouts.

FAQ

Should we use Kong or Cloudflare as an MCP gateway, or a managed connector platform?

Use Kong AI Gateway or Cloudflare when the tools are yours: APIs you already run behind Kong, or MCP servers you write and deploy on Cloudflare Workers. Use a managed connector platform such as Elaichi when the request is a list of SaaS apps like Salesforce, Jira and Slack. Kong's docs have you describe each tool, and Cloudflare's portal fronts MCP servers that already exist (vendor docs checked October 2026). Elaichi authors most connectors itself and serves them through one organization-wide endpoint.

Are there managed MCP connectors for hundreds of SaaS apps?

Yes. Elaichi serves 600+ connectors and authors most of them on its own infrastructure, including Salesforce, Jira and Slack, and serves them through one MCP endpoint at https://api.elaichi.ai/mcp. Each person signs in to each app with their own account, and a separate credential service holds and refreshes the tokens. No one at the customer runs an MCP server.

How do we connect our whole tech stack to AI assistants without building MCP servers?

Pick a platform that already wrote the connectors. With Elaichi, an admin adds one MCP address in Claude, ChatGPT or Cursor where the client allows it, and each member connects their apps from the catalog with their own sign-in. Roles and restrictions decide who reaches which tools, and every tool call that reaches execution lands in one audit log that names the account it reached.

Can Elaichi run alongside Kong or Cloudflare?

Yes. Internal APIs stay behind Kong, MCP servers your engineers write stay on Cloudflare Workers, and third-party SaaS accounts go through Elaichi. Assign each tool to exactly one of them, so a policy change is made once and never has to be reconciled across products.

A sales lead asks to connect Claude to the CRM, and the request lands on the security team's desk. This MCP security review checklist is the set of questions to send before approving an MCP server, or a gateway or control plane in front of several. Each comes with what a good answer looks like, and with the answer Elaichi gives.

MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. An MCP server exposes one app's actions as tools. A gateway or control plane puts one address and one set of rules in front of several. Either way, the review asks the same thing: who can make an AI act in which system, and what record is left behind. The same ten questions are the CISO's approval checklist for an MCP server or control plane, and the evidence table below turns them into go or no-go items.

What belongs on an MCP security review checklist?

Ten questions, in seven areas: sign-in and tokens, consent, how narrow access can get, how fast it ends, what the record holds, where data lives, and what the product does not cover. Copy the table into your vendor review and ask for every answer in writing.

How does each person sign in, and where do tokens sit?

Each person should sign in with their own OAuth grant, and no token should travel in a URL. OAuth is the standard for delegated sign-in that never hands the client a password. The MCP authorization specification requires authorization on every HTTP request and bans tokens from the query string. It also says a server must not accept or pass along tokens issued for anything else.

Elaichi has one address for every organization, https://api.elaichi.ai/mcp. There are no per-toolbox URLs and no embedded tokens. Clients register themselves through dynamic client registration (RFC 7591), and PKCE with S256 is required. The redirect address must match the registered one exactly (a loopback address may change port, never host), and a resource on any other origin is refused with invalid_target. That resource check runs when the token is issued.

An access token lasts one hour. A refresh token lasts 30 days and rotates on every use, and reusing an old one revokes the whole grant. Elaichi stores only a keyed hash of each token, never the raw value.

App credentials are not in Elaichi at all. A separate credential service holds them with AES-256-GCM at rest and owns refresh. Each ciphertext records the ID of the key that wrote it, so the encryption key can be rotated. A failed refresh marks the connection needs_reauth instead of failing quietly.

One gap to record: the current specification prefers client ID metadata documents and keeps dynamic registration for backward compatibility. Elaichi does not advertise metadata documents. OAuth versus long-lived keys for agents covers why a per-person grant beats a shared key.

What does the consent screen ask a person to approve?

It should name the client, show where the tokens go, and leave destructive access unticked. The MCP security best practices require a proxy's consent page to name the requesting client, list the scopes and show the registered redirect URI.

Elaichi's consent screen names the requesting app and shows the host it sends the person to, with the full address one click away. It also warns that anyone can register an app under any name and logo. The person picks one organization, then chooses from four boxes: read data, create and change data, run connected tools, and delete data and remove access.

Every scope the client requested is pre-ticked except delete, which is never pre-ticked. A client that requests no scope gets read only. Consent can narrow a request but never widen it.

When "run connected tools" is ticked, a second step asks which toolboxes the grant reaches. "All my tools" is the default and includes accounts connected later. "Only the ones I pick" allows up to 50. If you want tighter grants, tell people which option to choose.

Can access be narrowed to one tool for one role?

It should be, and the rule should run on the server, not in the model. OWASP's LLM06 Excessive Agency traces agent damage to excessive functionality, permissions and autonomy. It recommends the minimum necessary permissions, enforced in downstream systems rather than left to the model.

Elaichi keeps three layers apart. Each member holds exactly one role. A member sees only what they own or what was explicitly shared with them. Restrictions then decide 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. A rule aimed at a member can only narrow what their role allows, and never replaces or loosens a role rule. Within each layer, blocks beat allows.

Rules bind the operation, not the advertised label, because whoever edits a connector's documentation can rename a tool. Enforcement runs at every place a member can reach a connector or tool, including listing, connecting, advertising, executing, the final outbound-request check and opening a stored tool file. A restricted tool is withheld from the tool list and cannot be called. Search names it, flagged restricted, with no schema. A delete also needs the mcp:destructive scope.

Test one trap before go-live: the allowlist stage engages on the presence of an allow rule, not its contents, so an allow rule that names nothing denies everything. Why blocks and allows match differently explains the operation rule.

How quickly does access end when someone leaves?

Removal should land on the next request, and the vendor should give a figure for rule changes. In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change. The grant is re-read on every call, so the removed person's next call fails. Revoking a share or disconnecting an account also takes effect on the next request.

A role or restriction change takes about two minutes, through a 60-second cache and edge propagation. Write that figure into the control description before a tester measures it. During an incident, suspend the member or revoke the grant. Do not edit a rule and wait.

SCIM is the standard an identity provider uses to provision and deprovision users. A SCIM deprovision in Elaichi suspends the member and never removes them. Suspension still ends every live grant. Removal is a separate step, with an offboarding preflight that refuses while a toolbox entry still references the leaver's personal connection. A contractor's last day, step by step walks through that sequence.

What should one audit record hold for an AI tool call?

The person, the client that made the call, the account actually reached and the outcome, with nothing secret in it. Elaichi writes one entry for each connected-tool call that reaches execution (a call refused earlier writes none). Each entry names the operation and tool, the connection, the classification, whether the call was approved, the outcome and an error code. The account recorded is the one the call reached, taken from the execution rather than the request.

Each entry also records which client made the call. Claude, ChatGPT and Cursor are marked verified. A loopback client such as Claude Code shows its self-registered name, marked unverified. Each person can see and disconnect their own clients in Settings, under Connected apps.

actor_kind is a stored field, not a guess. Its values include user, scim, api_token and ai_assistant, which marks Elaichi's own in-app agent. A call from Claude, ChatGPT or Cursor is recorded under the person who signed in, with the surface and the client named. The trail keeps the one path argument that names the object, as the target id, and nothing else about the arguments. The error written to the audit trail is never derived from the third party's response, which keeps a remote error body out of your log pipeline.

The trail is append-only, newest first, and kept apart for each organization. It is eventually consistent, so a row may take a moment to appear. A reviewer reads it from the Auditor role, a free read-only seat that cannot call tools. Beyond the in-app trail, export to your own Datadog comes with the Black plan, which is launching soon. The fields an agent audit log needs lists the full record.

Where does the data live, and what survives deletion?

A good answer names the region, says exactly what the region covers, and names what deletion leaves behind. Elaichi has three regions, EU, US and APAC, chosen when the organization is created and fixed after. For an EU or US organization, the data store is pinned to that jurisdiction, and so is the execution of its org-scoped requests and tool calls. That store holds members, roles, connections, restrictions and OAuth grants. APAC uses best-effort placement and is not a residency guarantee.

Connector credentials are encrypted with AES-256-GCM. Connections created since 2026-10-05 have their credentials placed in the organization's region: inside the EU or US jurisdiction for those regions, and by best-effort placement for APAC. Older connections stay where they were until reconnected, which copies them into the region.

Several things sit outside the region. User accounts, sign-in sessions, API tokens, SSO settings and MCP OAuth token records (as keyed hashes) are kept globally. Requests that do not act inside an organization, such as sign-in and sign-up, run at the edge wherever the request lands. Tool-result files go to one private EU bucket for every organization, whatever its region. Every organization's audit trail is stored in one log instance in the EU, as the privacy policy states. The EU region is available on every plan.

Deletion has a gap that belongs in your data map. Deleting an organization tears down the workspace and deletes the connector credentials. Three stores keep residue: the audit history, analytics events, and the credential service's connector configuration rows. Elaichi returns that residue by name rather than hiding it. Deletion does not purge the audit history. Each record ages out under the log server's 90-day retention, counted from when it was written. For key custody, customer-managed keys in AWS KMS come with the Black plan, which is launching soon.

Whether Elaichi holds SOC 2, ISO 27001 or HIPAA attestations is answered in the Trust Center. SOC 2 evidence for agent access maps a control plane's records to the criteria, and what a BAA reviewer asks about agents covers health data.

Which MCP security risks does a gateway or control plane leave open?

Prompt injection is the largest, and no gateway or control plane closes it. OWASP's LLM01 Prompt Injection describes the indirect kind: instructions hidden in a web page or file the model reads. OWASP adds that a fool-proof prevention may not exist. An MCP server never sees the user's prompt, so it has nothing to judge. The prompt-injection write gate lives in the Elaichi agent window and does not apply to a raw tool call.

What holds on Elaichi's side limits the damage. It enforces role-based permissions per operation, a forbidden classification that no OAuth scope can reach, output redaction, OAuth scope limits and an audit row for each call that reaches execution. OWASP recommends two defenses that match: least privilege, and human approval for high-risk actions. Approval belongs in the client, so switch it on for writes wherever the client offers it.

Two other risks sit outside any remote gateway. The MCP security best practices describe local server compromise, where a server installed on a laptop runs code with the client's privileges. A control plane never sees that server. Text pasted into a chat window never reaches it either. Both belong to endpoint controls, a CASB (cloud access security broker) and DLP (data loss prevention), as what a CASB can and cannot see explains.

What evidence does a CISO need before approving an MCP server?

Screenshots and log rows from a trial organization, not vendor assurances. These areas cover the decision, and each one has a pass condition a reviewer can mark go or no-go.

How do you test it in an afternoon?

Create two test members in a trial organization and run five tests. Each one checks a claim from the evidence table rather than a feature description.

1. Sign in from one MCP client with the first test member, and confirm the consent screen names the client and leaves delete unticked.
2. Call a tool the role should reach, then open the audit entry and check it names the account the call reached.
3. Restrict one tool for that role, then confirm a search_tools query returns it only by name, flagged restricted and with no schema, while the same query still finds the tools the role keeps.
4. Remove or suspend the second test member, then confirm their next call fails.
5. Change the first member's role, then confirm the new rule applies within about two minutes.

How do you take AI agents on company data through a security review?

Arrive with an inventory, the rules and a record, not a promise. Reviewers approve a design they can test, and six steps produce one.

1. List the AI clients people already use and the apps they have connected, including personal tokens.
2. Move everyone to one address with per-person sign-in, and retire shared tokens.
3. Write roles before access. Start everyone on Member and restrict destructive tools at the role level.
4. Add the reviewer as an Auditor. The seat is free and read-only.
5. Send the ten questions to each vendor and attach the written answers to the review.
6. Pilot with one team for two weeks, then sample the audit log against the roles you wrote.

On cost, Elaichi's Gold plan is $15 per user per month at the USD list price. Auditor, Guest and Billing Admin seats are free.

When is an MCP gateway the wrong control for the risk?

When nobody has connected an AI client to a system of record yet. Assistant use that is only reading, copying and pasting is a content problem. DLP is the right instrument for it, and a gateway adds an address that answers nothing you were asked.

One team using one app may not need a second vendor either. Many apps now ship their own MCP server that runs under the app's own permission model. That holds until a second app or client arrives, and the question becomes one set of rules and one trail across them.

The case for waiting on a gateway lists the signals that say you have waited long enough. When they appear, the connector catalog runs to 600+, and the rest of the governance writing covers the rules underneath.

FAQ

How should a security team evaluate an MCP gateway?

Ask every vendor the same written questions: how each person signs in, where app credentials live, what the consent screen pre-ticks, whether a rule can cover one tool for one role, where rules are enforced, how fast access ends, what an audit record holds and leaves out, where data lives, and what the product does not protect against. Then test the answers. Revoke a grant and confirm the next call fails. Change a rule and time it. In Elaichi, a role or restriction change takes about two minutes.

Is it safe to connect Claude to our CRM?

It can be, if three things hold: each person signs in with their own grant, the agent can reach only the tools its role needs, and every call that runs is recorded against the account it reached. The usual risks are a shared token, an agent that can delete records, a change nobody can attribute, and instructions hidden in CRM content. Through Elaichi, delete is never pre-ticked on the consent screen, a role can be restricted to read tools, and the audit log names the account each call that ran reached. Elaichi does not stop prompt injection, so keep approval for writes switched on in the client.

Is Elaichi SOC 2 certified?

This answer makes no certification claim. Whether Elaichi holds SOC 2, ISO 27001 or HIPAA attestations is published in its Trust Center at trust.elaichi.ai, and any statement for a compliance file should be taken from there. What the product's code backs can be described directly: an append-only audit trail kept apart for each organization, a per-organization store pinned to the EU or US jurisdiction for organizations in those regions, AES-256-GCM encryption at rest, SSO with SCIM provisioning, TOTP MFA, passkeys, and a free read-only Auditor role.

Does an MCP gateway protect against prompt injection?

No gateway closes it, because an MCP server never sees the user's prompt. The prompt-injection write gate lives in the Elaichi agent window and does not apply to a raw tool call. What limits the damage is least privilege and approval: role-based permissions per operation, a forbidden classification no OAuth scope can reach, no delete scope unless someone ticks it, human approval for writes in the client, and an audit log that shows what happened afterwards.

How fast can we cut off an employee's AI access?

In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change. The grant is re-read on every call, so the person's next call fails. A SCIM deprovision suspends the member, which has the same effect. Editing a role or a restriction is slower, at about two minutes, so suspend the member during an incident rather than editing a rule.

What should a CISO do first if an MCP-connected agent misbehaves?

Suspend or remove the member whose grant the agent holds. In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change, so the agent's next call is refused. If the account behind the calls should stop for everyone, disconnect that connection, which also takes effect on the next call. Then tighten the role's restriction, which takes about two minutes, and read the audit trail to see which calls already ran and which account each one reached.

An engineer pastes a personal CRM token into a local MCP config. A support lead installs a community server from a registry. Neither asked security, and both agents now act inside company systems.

MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. MCP security risks come from three places: the content the model reads, the servers that hand it tools, and the credentials behind those servers. Each risk here has a source, an example, a fix and an owner.

What are the MCP security risks for companies, and how do you reduce them?

Nine risks recur across the MCP specification and OWASP's lists. Most are reduced by where credentials live and how narrow each grant is. Prompt injection is not, because it happens inside the model.

The sources are the MCP Security Best Practices, the OWASP MCP Top 10 (a beta release) and the OWASP Top 10 for LLM applications.

How does prompt injection reach an agent through tool results?

Through content the agent reads. A ticket, email or document can contain text written as an instruction, and the model may follow it. OWASP's LLM01 Prompt Injection calls this indirect injection, and says it is unclear whether any method prevents it fully.

Example: a support ticket tells the assistant summarizing it to email the customer list to an outside address. If the agent holds a tool that can do that, the instruction has somewhere to go.

Elaichi does not stop this, because an MCP server never sees the user's prompt. The prompt-injection write gate lives in the Elaichi agent window and does not apply to a raw tool call.

OWASP lists least privilege and human approval for high-risk actions among its mitigations. In Elaichi, a restriction can withhold named write tools, or a whole connector, from a role, and every call that reaches execution leaves a record. Approval for writes belongs in the client, as human approval for agent actions explains.

What are tool poisoning and rug pulls?

Tool poisoning hides instructions in a tool's description, which the model reads in full and the person rarely sees. A rug pull is a server changing a description after you approved it.

Invariant Labs described both in April 2025. Their test server offered a harmless-looking add tool to Cursor. Its description told the agent to read the user's MCP config file and SSH private key and pass them out. OWASP lists the same attack as MCP03, Tool Poisoning. Invariant recommends showing users full descriptions and pinning server versions by hash.

Elaichi authors, maintains and serves most of its connectors from its own infrastructure, and their tool descriptions come from one accountable vendor. A native MCP connector is different: its tool names and descriptions come from the vendor's own server, per connection, so that vendor is accountable for them. A custom connector is written by the organization that creates it. Allow rules also bind the operation, not the label, because whoever edits a connector's documentation can rename a tool.

A custom connector forked from a public one takes upstream changes only through a review, where conflicts and destructive removals start unchecked. A description is still text the model reads, so an accountable author narrows who writes it, not how the model treats it.

What are token passthrough and the confused deputy problem?

Token passthrough is a server forwarding a client's token to a downstream API without checking it was issued for itself. The MCP specification forbids it: a server must not accept tokens that were not issued for it.

In the confused deputy attack, a proxy holds one OAuth app (OAuth is the standard for delegated sign-in) at a third party, lets clients register themselves, and the third party remembers consent in a cookie. An attacker registers a client with their own redirect address and sends the user a link. Consent is skipped, and the code lands with the attacker. The specification's fix is per-client consent naming the client, its scopes and its redirect address, plus exact redirect matching.

In Elaichi, the client holds an Elaichi grant, never the app's credential, and each authorization request lands on a consent screen that names the app, requires PKCE and matches the redirect address exactly. The review checklist lists what a consent screen should show.

Why are personal API keys in local MCP configs a risk?

A key in a file is a long-lived secret that anyone with the file can use, and it does not end when its owner leaves. OWASP's MCP01, Token Mismanagement and Secret Exposure, names hard-coded secrets in config files, long-lived tokens and shared service accounts.

Invariant Labs' tool-poisoning test targeted exactly that file, so a key stored there can leave with it.

Elaichi puts no secret in the config. The address, https://api.elaichi.ai/mcp, is the same for every organization and carries no token. Each person signs in with OAuth.

Elaichi stores only a keyed hash of each token, and app credentials live in a separate credential service, encrypted at rest with AES-256-GCM (the checklist has the detail). As a backstop, tool results pass through a scrubber that replaces values under secret-named keys, such as api_key or password, with [redacted]. OAuth versus long-lived keys compares the two, and replacing personal MCP servers covers finding them on laptops.

Where do over-broad scopes and shared accounts go wrong?

A broad token turns one leak into access to everything it covers, and a shared account hides who acted. The MCP specification's scope minimization section warns that a stolen broad token enables lateral access. It recommends starting small and asking for more when needed. OWASP's MCP02 calls the slow version privilege escalation via scope creep.

The common failure is one admin-scoped service account in the CRM, used by five people's agents. The CRM's log then shows one name for every change.

On Elaichi's consent screen, delete is never pre-ticked and a client that requests no scope gets read only. The checklist's consent questions show what to ask any vendor.

The trade-off: a shared connection runs on its owner's credential, so calls through it reach the app as that account. Sharing one connection with the whole organization rebuilds the shared account. Where the app's own permissions matter, have each person connect their own account.

How do you enforce least privilege for AI agents across SaaS apps?

Run each call as the person who made it, then narrow it by role and by tool on the server, not in the prompt. OWASP's LLM06 Excessive Agency traces agent damage to excess functionality, permissions and autonomy. It recommends acting in the user's own context, with authorization enforced downstream rather than by the model.

Each Elaichi member holds exactly one role, and restrictions decide which connectors and which individual tools a target may reach. Rules are enforced at execution, and a change takes about two minutes. Restricting one tool or the whole app works through six cases.

Where a tool is right but one argument is dangerous, a frozen parameter locks it, such as the payee on a payment tool. One condition: a freeze binds only calls made through its toolbox entry, so share the toolbox with the people it governs, not the connection itself.

Why are unvetted community MCP servers a supply chain risk?

Installing a server means running someone else's code with your client's privileges, or sending your data to someone else's host. The MCP specification's local server section describes malicious startup commands and data exfiltration. It requires clients to show the exact command and get consent first, and recommends sandboxing.

OWASP's MCP09, Shadow MCP Servers, sets a blunt test: if security cannot list every active server, unapproved ones already exist.

Elaichi leaves nothing to install. The catalog runs to 600+ connectors, most authored and served by Elaichi and the rest vendors' own MCP servers it governs. A control plane never sees a server someone installs on a laptop, though. That stays with endpoint controls and client policy. First-party connectors against a registry covers the authorship trade-off.

Does tool sprawl make an agent less safe?

Yes. Every tool an agent does not need is functionality OWASP's Excessive Agency entry tells you to remove. Why long tool lists fill the context window has the detail.

Search also fails without a relevance floor, returning a tool from an app nobody asked about, which the model then calls. Elaichi's search requires a match to carry at least half the query's weight.

In Elaichi, connected tools are never listed one by one, however few there are. The model finds a tool with search_tools and runs it with execute_tool. A restricted tool is withheld from the tool list and cannot be called. Search names it only as restricted, with no schema.

What happens when nobody can say what an agent did?

The incident review stalls, and nobody can prove access ended. OWASP's MCP08, Lack of Audit and Telemetry, warns that without logs there is no trace of agent actions.

Elaichi records one entry for each connected-tool call that reaches execution (a call refused earlier writes none). Each entry names the person, the client that made the call, the account actually reached and the outcome. The trail logs the one path argument that names the object, as the target id, and nothing else about the arguments. The fields an agent audit log needs lists the rest.

In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change, so the person's next call fails, and a contractor's last day walks through the rest of the order.

Where do you start a vendor review?

Send every vendor the same written questions, then test the answers. Ask how people sign in, where credentials live, what consent pre-ticks and how fast access ends. Revoke a grant and confirm the next call fails. Then change a rule and time how long it takes.

The ten-question MCP security review has each question and what a good answer looks like.

When do you not need a control plane for these risks?

When nobody has connected an AI client to a company system yet. Copying and pasting into an assistant is a content problem, and DLP (data loss prevention) fits it better, as what a CASB can see explains.

One team using one app may not need one either, because many apps ship their own MCP server under their own permissions. That holds until a second app or client arrives and you need one set of rules across them. What an MCP control plane is sets out that shape, and the connector catalog shows which apps it covers.

FAQ

What are the main MCP security risks for a company?

The recurring ones are prompt injection through content the agent reads, poisoned or silently changed tool descriptions, token passthrough and the confused deputy problem, personal API keys in local config files, over-broad scopes and shared accounts, unvetted community servers, tool sprawl, and missing audit records. Most are fixed on the server side by per-person sign-in, narrow grants and a record of each call that runs. Prompt injection is the exception: it happens inside the model, so least privilege and human approval limit the damage rather than prevent it.

What is MCP tool poisoning?

Tool poisoning hides instructions in an MCP tool's description. The model reads the full description and the person usually sees only the tool's name, so the hidden text can steer the agent, for example toward reading a local key file and sending it out. A rug pull is the same attack delivered later, when a server changes a description after it was approved. The defenses are tools from an accountable author, showing the full description, pinning server versions, and access rules that bind the operation rather than the tool's label.

Is token passthrough allowed in MCP?

No. The MCP specification forbids it. An MCP server must not accept a token that was not issued for that server, and it must not forward a client's token to a downstream API. Passing tokens through breaks the audience boundary, lets a stolen token use the server as a proxy, and leaves the downstream log showing the wrong identity.

How do you enforce least privilege for AI agents across SaaS apps?

Run each call as the person who made it, with their own OAuth grant, and decide on the server which tools each role may reach. In Elaichi, every member holds one role, restrictions name which connectors and which individual tools a role or user may reach, delete access is never pre-ticked on the consent screen, and a frozen parameter can lock one argument, such as a payee, so the model cannot change it. A role or restriction change takes about two minutes to apply.

Does Elaichi protect against prompt injection?

No. An MCP server never sees the user's prompt, so it cannot judge whether an instruction came from the person or from content the model read. What Elaichi enforces limits what an injected instruction can reach: role-based permissions per operation, per-tool restrictions, OAuth scope limits with delete never pre-ticked, and an audit record for every call that reaches execution. Approval for writes belongs in the AI client.

A security lead wants to replace personal MCP servers with something the company can audit. First comes one list: every MCP server on a company laptop. Say the endpoint team's script comes back with config files on 90 machines. Most entries look like this one:

{
  "mcpServers": {
    "jira": {
      "command": "npx",
      "args": ["-y", "a-community-jira-server"],
      "env": { "JIRA_API_TOKEN": "<one engineer's personal token>" }
    }
  }
}

MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. That entry starts a program on the laptop and gives it one person's Jira token. The MCP transport spec calls this stdio: the client launches the server as a subprocess and talks to it over standard input and output. Jira sees only that engineer's token, no company system records which assistant made the call, and the token works until someone revokes it.

To replace personal MCP servers, connect each app once in Elaichi, point every client at https://api.elaichi.ai/mcp, then revoke the old tokens. This post covers both halves: finding the servers, then swapping them.

How do you find which MCP servers employees have installed?

Read the config files each AI client keeps on disk. Most store them in JSON and Codex uses TOML, at paths its vendor documents.

The sources are the MCP guide to local servers for Claude Desktop, Cursor's MCP docs, VS Code's MCP guide and Claude Code's MCP docs, Devin Desktop's MCP docs, Devin CLI's MCP configuration and Codex's MCP docs, all checked October 2026.

Project files matter as much as home-directory files. A .cursor/mcp.json or .mcp.json committed to a repository puts the same server on every clone.

What should an endpoint script report from each file?

Server names, the command or URL, and the names of credential keys. Never the values.

An entry with command is a stdio server that runs on the laptop. An entry with url is a remote server. The MCP authorization spec says stdio servers should take credentials from the environment, so look in env, in envFile, and in headers on remote entries. This loop reads every config under a home directory with jq and prints one line per server:

find "$HOME" \( -name claude_desktop_config.json -o -name mcp.json -o -name .mcp.json \
  -o -name .claude.json -o -name mcp_config.json -o -name mcp-config.json \) -not -path "*/node_modules/*" 2>/dev/null |
while read -r f; do
  jq -r --arg f "$f" '.. | objects | (.mcpServers? // .servers? // empty) | to_entries[]
    | [$f, .key, (.value.command // .value.url // "?"),
       ((.value.env // {}) + (.value.headers // {}) | keys | join(","))] | @tsv' "$f"
done

Codex keeps servers in TOML, so list them with grep -n '^\[mcp_servers' ~/.codex/config.toml.

It prints key names such as JIRA_API_TOKEN and leaves the secret on the laptop. Two cases hide the secret from the file. Cursor can interpolate ${env:NAME} from the shell, and VS Code can prompt for a password input and store it. A key name with no value still tells you a token exists.

What can device policy turn off, and what can it not see?

Some clients take a policy that turns local servers off. None of them tells you which tokens already leaked.

• Claude Desktop. On Team and Enterprise plans, isLocalDevMcpEnabled is a Boolean that defaults to true (Anthropic's enterprise configuration, checked October 2026). Set it through a configuration profile on macOS or Group Policy on Windows.
• VS Code. The ChatMCP policy sets chat.mcp.access to all, registry or none (VS Code enterprise settings, checked October 2026).
• Cursor. Enterprise teams can allowlist the MCP servers members may use. Adding a server "does not push it to users' machines" (Cursor's enterprise docs, checked October 2026).

The limits are real. A personal laptop, a token in a shell profile, or a client you have not listed sits outside this view. Elaichi does not scan laptops either, and it has no feature that lists local servers. The inventory is your device management tool's job. The wider set of MCP security risks covers what a local server can do beyond holding a token.

How do you replace personal MCP servers with company-managed ones?

Connect each app once in Elaichi, then point every client at one organization endpoint where each person signs in with OAuth. The new config entry holds a URL and no token.

Elaichi is a governed MCP control plane. Its endpoint is https://api.elaichi.ai/mcp, the same address for every organization and every person. OAuth (the sign-in standard that gives a client a scoped grant instead of a password) ties each call to the person who approved it. Claude, ChatGPT, Cursor and any other MCP client all use that one address.

The app credentials leave the laptop. A separate credential service holds each connected account's secrets, encrypted at rest with AES-256-GCM, and owns token refresh. If a refresh fails, the connection is marked needs_reauth instead of failing silently.

Three layers decide what each person reaches:

• A role sets what a member may do, and each member holds exactly one.
• Sharing decides what they can see: their own connections and those shared with them.
• A restriction decides 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.

Restrictions are checked at every place a member can reach a connector or tool, including listing, connecting, advertising, executing, the final outbound-request check and opening a stored tool file. A role or restriction change applies within about two minutes. Running your own MCP servers compares the hosted path with keeping servers in-house.

In what order should the migration run?

Inventory, pick the top apps, connect them, swap the configs, then revoke the old tokens. Revoking last means nobody loses access mid-week.

1. Inventory. Run the script and count servers by app. Start with the three to five apps that appear most often.
2. Pick the top apps. Check each one in the connector catalog, which lists 600+ connectors, most of them written by Elaichi. Jira, Notion and Sentry are all in it.
3. Connect them in Elaichi. With no restriction in place, a member can connect any catalog app with their own account. A shared connection runs on its owner's credential, so decide which apps should be personal and which shared. Write restrictions before people switch.
4. Swap configs to the one URL. In Cursor the entry becomes "url": "https://api.elaichi.ai/mcp". In Claude, an owner on Team or Enterprise adds it once as a custom connector, and members connect it. Each person signs in once.
5. Revoke the old personal tokens. Do it in each app's own token settings, then delete the old entries and run the inventory again.

Rolling out Claude and ChatGPT to employees covers the client-side steps per department.

What does each person do on switch day?

Delete the old entry, add the one URL, and sign in. Nothing else goes in the config file.

The client registers itself with Elaichi through OAuth dynamic client registration, so nobody types a client ID, a secret or a header. A browser opens Elaichi's sign-in, and the person lands on a consent screen. With several organizations, they pick one, and that connection sees only that one.

The consent screen lists four boxes: read data, create and change data, run connected tools, and delete data. Every scope the client asked for is pre-ticked except delete, which never is. With "Run your connected tools" ticked, the person chooses all their tools or only the toolboxes they pick. Each person can later see and disconnect their own grants under Settings, then Connected apps.

How do you stop employees from sharing personal API keys with AI tools?

Give them a path that needs no key, then close the old one. A ban without a replacement moves the token to a shell profile.

The sanctioned path removes the reason to paste a key. In Elaichi, the person signs in with OAuth and the app credential sits in the credential service, not in a file on the laptop. Revocation is one action: removing or suspending a member revokes every live grant in the same transaction as the membership change, so that person's next call is refused.

Close the old path in three moves. Revoke the personal tokens the inventory found. Turn off local servers through device policy where the client supports one. Then rerun the inventory each month, because new configs appear when new tools ship.

Expect people to hit a rule they did not know about. In Elaichi, any member can file an access request when a restriction stops them, with no permission needed. Someone with member:manage resolves it, and approving it opens that connector or tool for that one person. A request is slower than a personal key, but it leaves a record and keeps the old path closed. OAuth or API keys for AI agents sets out why a revocable grant beats a long-lived string.

What does the audit log show after the switch?

Every connected-tool call through the endpoint that reaches execution, filed under the person who approved the sign-in, with the account it reached. A local server leaves only the app's own record of a personal token.

Elaichi writes one entry for each connected-tool call that reaches execution (a call refused earlier writes none). Each entry names the connection the call actually reached and the outcome. It records the one path argument that names the object, as the target id, and nothing else about the arguments. It also records the surface, here mcp, and the OAuth client the call came through.

Claude, ChatGPT and Cursor show as verified client names. A client that signs in through a loopback address, such as Claude Code, shows the name it registered with, marked unverified. The call is recorded under the person, not as an AI actor. That settles the first question after an unexpected change: which of two Notion workspaces did the write reach. A compliance reviewer can read the trail from the free, read-only Auditor seat.

When should a personal MCP server stay?

When it reaches something only the laptop can reach. Elaichi is hosted, so it cannot read local files or a service on the developer's own machine.

A filesystem server, a local database or a build tool belongs on the laptop. So does an internal server for one team's own system. Some apps are not in the catalog at all. GitHub is one, so a team that needs it uses GitHub's own MCP server, which Elaichi does not govern, or writes a custom connector. Keep those servers on a short, named list and leave them out of the token revocation step.

For everything else, the swap is one URL per client. The offboarding guide covers what happens to that access when someone leaves, and the wider Shadow AI series covers the rest of the paper trail.

FAQ

Where do Claude Desktop, Cursor and VS Code store MCP server settings?

Claude Desktop uses claude_desktop_config.json, under ~/Library/Application Support/Claude on macOS and %APPDATA%\Claude on Windows. Cursor reads ~/.cursor/mcp.json for every project and .cursor/mcp.json inside a project. VS Code reads .vscode/mcp.json or a root .mcp.json in a workspace, plus an mcp.json in the user profile. Claude Code keeps servers in ~/.claude.json and in a project's .mcp.json.

Can Elaichi detect the MCP servers installed on employee laptops?

No. Elaichi is a hosted MCP control plane and does not scan devices. Use your device management tool to read each client's config file. Elaichi covers the other half: once people use its one organization endpoint, every connected-tool call that reaches execution lands in its audit log, attributed to the person who connected.

Is a local stdio MCP server a security risk?

It can be. A stdio server is a program the AI client starts on the laptop, and it runs with that user's permissions. The MCP specification says stdio servers take their credentials from the environment, so the token usually sits in a config file or shell profile. The app it calls sees only the token's owner, not which assistant made the call.

How do you stop employees putting personal API keys in AI tools?

Give them a path that needs no key, then close the old one. A governed endpoint signs each person in with OAuth and keeps app credentials in a separate service. After the swap, revoke the personal tokens in each app and use device policy, such as Claude Desktop's isLocalDevMcpEnabled or VS Code's ChatMCP policy, to turn off local servers.

The usual starting point is a pile of tickets. Sales pastes pipeline notes into ChatGPT. An engineer runs a Jira server on a laptop for Cursor. HR asks whether Claude can read Rippling. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. The job is to replace that pile with one path the company owns.

How do you roll out Claude and ChatGPT to employees without a server per person?

Connect each approved app once, behind one organization-wide endpoint, and let each person sign in to it from their own client. Then decide reach with team sharing, roles and restrictions, and check the result in the audit log.

Elaichi is built for that path. Claude, ChatGPT, Cursor and any other MCP client all reach the same address, https://api.elaichi.ai/mcp. There are no per-person URLs, tokens or servers. Each member still connects once and signs in with their own OAuth grant, the revocable permission a client receives at sign-in. For the engineering case, see what happens when engineers already have ChatGPT.

How does a head of IT approve which apps employees can connect to Claude?

Write an allow rule for each role that names the approved connectors. In Elaichi, a connector the rule does not name is then refused at every place a member can reach a connector or tool, including listing, connecting, advertising, executing, the final outbound-request check and opening a stored tool file. A member cannot connect it or call it, from any client.

Start with a list of the apps people already use with AI. Mark each one approved for everyone, approved for one department, or not yet. The connector catalog holds 600+ connectors, most authored by Elaichi and some run by the app's own vendor.

Then turn the list into restrictions. A restriction decides 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. That default matters here. The Member role holds connection:create, so with no rule a member can connect any app in the catalog with their own account.

One trap: the allowlist stage engages on the presence of an allow rule, not its contents, so an allow rule that names nothing denies everything. Save the allow rule with its connectors already in it.

A member who meets a restricted connector can file an access request. Approving a request opens that connector or tool for that one person only, and the role's other rules keep binding them. An administrator cannot decide their own request, so a second person signs off.

Which IT admin controls do Claude, ChatGPT and Cursor give you for MCP?

Each client controls how a server reaches its own users. Elaichi controls what is behind the server. You add the one address in each client, and the rules on roles, apps and tools live in one place behind it.

Here is what each vendor documents:

• Claude. On Team plans, only Owners and Primary Owners add a custom connector, under Organization settings > Connectors > Add > Custom > Web. Members then connect it themselves under Customize > Connectors (Anthropic's help center, checked October 2026).
• ChatGPT. Full MCP support, including write actions, is a beta on Business, Enterprise and Edu. An admin creates the app under Workspace settings > Apps > Create and publishes it. It then appears in users' Apps settings labeled custom, and OpenAI says functionality, UI and permissions may change (OpenAI's help center, checked October 2026).
• Cursor. Enterprise admins can allowlist MCP servers, but the allowlist does not push a server to anyone's machine. Team admins can instead distribute a server through a team marketplace, where teammates install and configure it themselves (Cursor's enterprise docs and MCP docs, checked October 2026).

Those are distribution controls, one per client. Elaichi's restrictions sit behind the endpoint, so one rule holds for every client. The per-client steps are in the Claude setup guide, the ChatGPT walkthrough and Cursor for a whole team.

How does a platform team centrally manage MCP servers for the whole company?

By not running any. Elaichi runs the connectors it authors and governs vendors' own MCP servers for the rest, so the platform team manages connections, sharing and rules instead of servers, versions and tokens.

Connect each company account once. Connector credentials do not live in Elaichi. A separate credential service holds them, encrypted at rest with AES-256-GCM, and owns token refresh. A failed refresh marks the connection Needs sign-in rather than failing silently.

Ownership is the next decision. A connection can stay private to one person, or be shared at use with a team or the whole organization. A shared connection runs on its owner's credential, so every call through it reaches the app as that account. Share one team-wide only when the whole team is meant to act as that account. For per-person access, share a template and let each person stamp it against their own account. A member sees only what they own or what was shared with them, admins included. Treat connector:create as high trust, because a custom connector can be pointed at any destination.

How do you give sales, engineering and HR different AI tool access?

Use teams for what each department uses, and roles with restrictions for what each department may reach. In Elaichi, a team is a named group you share connections, toolboxes and templates with.

A toolbox is a saved set of tool entries, each pairing one tool with one connected account. A template is the same tool list with no accounts in it, carrying tool renames, defaults and frozen arguments. Teammates with use on a template stamp their own toolbox from it and pick their own connections. Stamping copies the template once, so a later edit leaves stamped toolboxes alone.

A workable split for three departments:

• Sales. Build a Salesforce template and share it with Sales at use. Each rep stamps a toolbox against their own Salesforce account, so Salesforce's own permissions still apply per rep. The sales playbook covers which tools to restrict.
• Engineering. Build a Jira template with the issue tools engineers use, renamed in the team's own words. Share it with Engineering, and each engineer stamps a toolbox against their own Jira account.
• HR. Connect Rippling as a private connection, pin it into a toolbox with frozen arguments, and share only the toolbox with HR. Every call runs on the owner's Rippling account, so choose an owner whose access fits the whole team and who will stay. One condition: a freeze binds only calls made through its toolbox entry, so share the toolbox with the people it governs, not the connection itself. The HR team's setup works through it.

Teams carry shares, not rules. Restrictions target roles and users, never teams. Where two departments need different restrictions, give each its own custom role. Each person can also narrow a client at consent, from the default All my tools to Only the ones I pick, up to 50 toolboxes.

Which roles and restrictions should each department start with?

Start every working seat on Member, and add a custom role only where a department's restrictions must differ. Each member holds exactly one role, so a department role has to describe a whole job.

Member is the working seat. Team Admin adds managing teams, and People Admin adds managing members. Guest, Billing Admin and Auditor lack tool:execute, so they cannot call a tool at all. Auditor is a free, read-only seat. Designing one role per person covers the reasoning.

If your directory is the source of truth, map groups to roles. SCIM is how a directory pushes users and groups into an app, and in Elaichi each group mapping can confer at most one role. The Sales group lands on the sales role, Engineering on the engineering role. Where SCIM provisioning stops explains what a group cannot express.

Then write the rules for each role. Allow the approved connectors, and restrict the destructive tools a role does not need. A rule aimed at a member can only narrow what their role allows, and never replaces or loosens a role rule. Within each layer, blocks always beat allows. Tool rules versus app rules works through six cases.

A role or restriction change takes effect within about two minutes, on MCP, the console and REST alike.

What should a one-team pilot prove before the company-wide rollout?

It should prove that the rules match the calls people actually make. Pick one team with a clear need, run it for two weeks, and read the audit log instead of collecting opinions. If the pilot keeps stalling, read why AI pilots fail.

Sales makes a good pilot, with one main app and clear read and write tools. Before day one, give one reviewer the Auditor seat, so the record has a reader who cannot act.

The audit log is the chronological record of who did what. Elaichi writes one entry for each connected-tool call that reaches execution (a call refused earlier writes none), and each entry names the account the call actually reached. A call from Claude, ChatGPT or Cursor is recorded under the employee who signed in, with the client it came through. The trail logs the one path argument that names the object, as the target id, and nothing else about the arguments.

Read the log for three things. Tools nobody called can leave the toolbox. Access requests show a rule that is too tight. Calls to an unexpected account show a sharing gap. What an AI audit log must capture lists the fields to check.

How does a new hire's assistant get the right app access automatically?

Through the role and the shares they arrive with. Elaichi has four ways in, and each one sets a role on day one.

Where no default role is configured, an automatic join lands on Member. Anything shared with the whole organization reaches the new hire at once. A team share reaches them within about two minutes of being added to the team. SCIM and group mapping set the role, not team membership, so a Team Admin or above adds the person to their team. Keep that step in the joiner checklist.

The new hire then connects each client once and signs in. The default consent choice, All my tools, also picks up connections shared with the person later, so team shares arrive without reconnecting.

How do you close AI access when an employee leaves?

Suspend or remove the member, and their very next call is refused. In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change, and the grant is re-read on every call with no cache.

A SCIM deprovision suspends the member and never removes them. Removal is a separate step in Elaichi, and it runs a preflight. A shared connection can go to one colleague, or be deleted if the admin asks. Nothing transfers to the organization or a team. A private connection that nothing beyond the person depends on cannot be transferred and is deleted with them. A private connection that a shared toolbox depends on blocks removal until an administrator transfers it to a member. So the person who connects HR's private Rippling account should be someone who will stay.

Removal ends access through Elaichi, nothing more. The person's account inside each app still exists, and it is closed there or through the identity provider. The offboarding runbook walks through a contractor case. Then check the audit log, where a removed member's past calls stay, labeled Former member.

When do you not need a control plane for this rollout?

When one team uses one app and that app's own MCP server already does the job. Several vendors now host one, and it runs under the app's own permissions with no second vendor.

Notion is a fair example. Notion describes its server as "a remote MCP server hosted by Notion", where the client can read and update content the person can access. Workspace owners manage client access under Settings > Connections (Notion's docs, checked October 2026). For a product team living in Notion alone, that may be enough.

The case changes at the second app or the second team. Then you want one address across vendors, rules written once per role, and one audit trail. If no assistant can write to a company system yet, read the case for waiting first. Know one limit as well. The prompt-injection write gate lives in the Elaichi agent window and does not apply to a raw tool call.

As of October 2026, SSO, SCIM, group-to-role mapping and custom roles are on Gold, and the 14-day trial unlocks all of them. Gold lists at $15 per user per month in USD, and pricing shows your local price and the trial terms. More governance posts sit under governance, and team-by-team starting points are on the use cases page.

FAQ

As head of IT, how do I approve which apps employees can connect to Claude?

In Elaichi, write an allow rule for each role that names the approved connectors. A connector the rule does not name is then refused when a member browses for it, connects it or calls it, from Claude, ChatGPT, Cursor or any other MCP client. Save the rule with its connectors in it, because an allow rule that names nothing denies everything. A member who needs an app that is not approved can file an access request, and an administrator approves or denies it.

What IT admin controls exist for MCP connectors across Claude, ChatGPT and Cursor?

Each client's admin console decides how an MCP server reaches that client's users. Elaichi decides what is behind the server. Point all three clients at the one Elaichi endpoint, and the same roles, restrictions and audit log apply whichever client makes the call. A restriction can name a whole connector or single tools, and it targets a role or one user.

How does a platform team centrally manage MCP servers for the whole company?

With Elaichi, a platform team runs no MCP servers. Elaichi authors most connectors and governs vendors' own MCP servers for the rest, every client uses one organization-wide endpoint, and the team manages connections, sharing, roles and restrictions in one console. Connector credentials sit in a separate credential service that owns token refresh, and a failed refresh shows the connection as needing sign-in instead of failing silently.

How do I onboard a new hire so their AI assistant gets the right app access automatically?

In Elaichi, every onboarding path sets a role on day one. An emailed invite can preset both the role and the teams. Verified-domain auto-join and just-in-time SSO apply a configured default role, and SCIM applies the role mapped to the person's directory group. Anything shared with the whole organization reaches the new hire at once. A team share reaches them within about two minutes of being added to the team, and SCIM does not set team membership, so keep that step in the joiner checklist.

How long does a role or restriction change take in Elaichi?

A role or restriction change in Elaichi takes effect within about two minutes, on MCP, the console and the REST API alike. Removing or suspending a member is faster: the grant is re-read on every call, so the person's next call is refused. Revoking a share and disconnecting an account also take effect on the next call.

Why are companies asking for an MCP control plane?

Because the number of AI setups grew faster than anyone could govern them. Support wants its help desk inside Claude. Finance wants the ledger inside ChatGPT. Engineering already works in Cursor. Many apps now ship an MCP server of their own, each AI client needs its own setup, and each person signs in to each pair. An MCP control plane is the category built to replace that grid with one address and one set of rules.

MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. An MCP server is the service that offers those tools. An endpoint is the address a client is pointed at. Four AI clients and fifteen apps can mean sixty separate setups for one person, and sixty to undo on their last day.

The request that reaches IT usually sounds like this: one MCP endpoint for all our company apps, not dozens of separate servers, with SSO and a record of what the AI did. That request describes a control plane.

What is an MCP control plane?

An MCP control plane is the one place a company decides which people, through which AI clients, may call which tools in which accounts. It is the one MCP address clients use. It holds the connections, serves the tools, and makes the access decision on every call.

The name comes from networking. In a router, the control plane builds the routing table that says what to do with incoming packets. The data plane, also called the forwarding plane, processes them (Wikipedia). The MCP version keeps that split. The decisions about who may reach what live in one place. The calls themselves run against many SaaS accounts.

Elaichi is a governed MCP control plane. Every SaaS account a company uses is connected once. Claude, ChatGPT, Cursor and any other MCP client reach those accounts through one organization-wide endpoint, https://api.elaichi.ai/mcp. Governed means the roles, restrictions and audit log ship with that address, rather than being a project you add later.

Four properties separate a control plane from the products it gets confused with:

1. One address for the organization. The person's grant varies. The URL does not.
2. The control plane serves the connectors. Nobody at your company runs an MCP server.
3. Access is decided where the tool is served, on every call, not only at sign-in.
4. One record per executed call, naming the person and the account that was actually reached.

MCP control plane vs MCP gateway vs MCP registry: what is the difference?

A registry lists MCP servers, a gateway sits in front of MCP servers, and a control plane is the MCP server. Self-hosted servers are the do-it-yourself baseline all three are measured against.

A registry answers "which servers exist". The official MCP Registry describes itself as a central store of metadata about publicly accessible MCP servers. It points to packages hosted elsewhere and leaves security scanning to package registries and the marketplaces built on top of it. It was marked as a preview when checked in October 2026 (MCP Registry). Who fixes a registry server when it breaks is the question that follows.

A gateway answers "how do I put one door in front of the servers I already have". The name covers several products with different mechanics, and the four gateway shapes are sorted separately. A control plane answers "how does the whole company reach its apps under one set of rules, without running servers".

Elaichi sits in the last column. It authors, maintains and serves most of its connectors from its own infrastructure, and governs vendors' own MCP servers for the rest. It is not a marketplace of third-party servers, not a gateway you deploy, and not an API gateway that added MCP as a feature. If your team already runs MCP servers, what running them yourself really costs is worked through cost by cost.

What should a governed MCP control plane for enterprises include?

At minimum: per-person sign-in, connectors the vendor maintains, layered access rules, an audit record per call, identity from your directory, and a clean offboarding path. Each item says how Elaichi does it, so a trial can check it.

• Per-person OAuth with nothing to paste. OAuth is the sign-in standard that lets software act for a named person without holding their password. The MCP authorization spec builds on OAuth 2.1 for HTTP transports. It lets a client obtain a client ID through metadata documents, pre-registration or dynamic client registration (MCP authorization spec). The 2026-07-28 version of the spec marks dynamic client registration as deprecated and keeps it for backwards compatibility. Clients register themselves with Elaichi through dynamic client registration, with PKCE S256 required. There is no client ID, secret or header to enter.
• Connectors the control plane runs or governs. Elaichi serves 600+ connectors and authors most of them. Account credentials sit in a separate credential service, encrypted at rest, that owns token refresh.
• Three access layers kept apart. Role permissions, sharing on each resource, and restrictions on connectors and single tools.
• A record of each call that runs. Elaichi writes one entry for each connected-tool call that reaches execution (a call refused earlier writes none), and the entry names the account the call reached.
• Identity from your directory. SAML or OIDC single sign-on (SSO) and SCIM provisioning, with groups mapped to roles.
• An offboarding path. Suspension or removal cuts every live grant on the next call.
• Residency. Elaichi has three regions, EU, US and APAC, chosen when the organization is created. 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. EU data residency, leg by leg lists what each region covers and what it does not.

How does one MCP endpoint replace dozens of separate servers?

The address stays fixed and the grant changes per person. Every client points at https://api.elaichi.ai/mcp, and each member signs in once per client. That person's grant, role and shares decide what their calls can reach.

The mechanism is standard MCP. The endpoint is POST /mcp, speaking Streamable HTTP and JSON-RPC 2.0, stateless, behind OAuth. A client that calls it without a token gets a 401 with a challenge that starts sign-in. The person signs in, confirms the organization, and lands on a consent screen with four boxes: read data, create and change data, run connected tools, and delete data. Delete is never ticked in advance. With "Run your connected tools" ticked, the person picks All my tools or Only the ones I pick, up to 50 toolboxes. A toolbox is a saved set of tools and the accounts behind them.

flowchart LR
  A["Claude"] --> E["One endpoint: api.elaichi.ai/mcp"]
  B["ChatGPT"] --> E
  C["Cursor"] --> E
  E --> G{"Grant still valid?"}
  G -- "no" --> X["401: sign in again"]
  G -- "yes" --> R{"Role, sharing and restrictions allow this tool?"}
  R -- "no" --> W["Call refused"]
  R -- "yes" --> K["Connector Elaichi authors"]
  K --> S["The connected SaaS account"]
  K --> L["Audit log entry"]

From then on, every call takes the same path. The grant is re-read on each call. The role must hold tool:execute. Sharing decides which accounts the person can reach. One resolver (the code that decides allow or deny) then applies restrictions. Only then does the connector reach the account.

A big catalog does not become a long tool list. In Elaichi, connected tools are never listed one by one, however few there are. The model finds a connected tool with search_tools and runs it with execute_tool, which passes the same checks as a direct call. A restricted tool is withheld from the tool list and cannot be called. Search names it, flagged restricted, with no schema. One address against one per team works through what this saves at 200 people.

Can a centralized MCP server for the whole company use SSO and SCIM?

Yes, and it should. Elaichi has SAML and OIDC single sign-on built in-house, plus SCIM v2 for users and groups, with group-to-role mapping. SSO means people sign in through your identity provider. SCIM means the directory pushes joiners, leavers and groups to Elaichi.

SCIM is a standard HTTP protocol for managing identities across separate systems, such as a company directory and a cloud service (RFC 7644). It moves people and groups. It does not decide what an AI client may do once a person is in. In Elaichi, that decision belongs to the role the group maps to, plus sharing and restrictions.

Two details matter during rollout:

• SSO can be enforced. Domains are verified with a DNS TXT record. If a person's email domain belongs to an organization that enforces SSO, other sign-in methods are refused with "Your organization requires signing in with SSO".
• A SCIM deprovision suspends; it never removes. Suspension revokes every live grant, and the next call is refused. Removing the member, with its offboarding preflight, is a separate step an admin takes in Elaichi.

Where SCIM stops and MCP grants begin covers the boundary in detail.

Which control plane fits a company using Claude, ChatGPT and Cursor?

One that serves all three from the same address, with each member's own grant. Elaichi gives Claude, ChatGPT and Cursor one URL. An admin adds it once where the client allows, and each member then connects and signs in.

Each client has its own admin step. On Claude Team or Enterprise, an owner adds the address as a custom connector for the organization, and members connect it. In Cursor, team admins can share an MCP server with the team, and each developer can also add the URL to mcp.json. In ChatGPT, an admin on a Business plan creates the app in workspace settings and publishes it to members. Full MCP support with write actions is a beta on Business, Enterprise and Edu plans, and OpenAI says the details may change (OpenAI help center, read October 2026). The steps differ, but the address and the rules behind it do not.

Each member still connects once per client. What an admin avoids is a per-person URL, a pasted token, a per-team endpoint or a separate fork for each client. A fourth MCP client follows the same shape. The setup guides walk through connecting Claude, connecting ChatGPT and rolling Elaichi out to a Cursor team.

How does the access decision work on each call?

Three layers decide every call, and Elaichi keeps them separate. Roles say what a person may do. Sharing says which resources they may touch. Restrictions say which connectors and which individual tools a target may reach.

Roles. Elaichi groups 58 permissions into roles, and each member holds exactly one. The built-in chain runs Guest, Member, Team Admin, People Admin, Org Admin and Org Owner, each holding everything below it. Billing Admin and Auditor sit off the chain. Guest, Billing Admin and Auditor lack tool:execute, so the endpoint lists no tools for them.

Sharing. A grant of view, use or edit on a resource goes to a user, a team or the whole organization. A member sees only what they own or what was shared with them. Org owners and admins are no exception.

Restrictions. In Elaichi, restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything. A rule aimed at a member can only narrow what their role allows, and never replaces or loosens a role rule. Within each layer, block rules beat allow rules. Note that the allowlist stage engages on the presence of an allow rule, not its contents, so an allow rule that names nothing denies everything. Enforcement runs at every place a member can reach a connector or tool, including listing, connecting, advertising, executing, the final outbound-request check and opening a stored tool file.

Timing differs by change. A role or restriction change takes about two minutes. Revoking a grant, removing or suspending a member, revoking a share, or disconnecting an account takes effect on the next call. If an incident needs access cut at once, suspend the person rather than editing a rule.

What does the audit log record for each call that runs?

One entry per executed call, naming who called, what ran and which account it reached. An audit log is the append-only history of those calls, and in Elaichi it is the same record shape for every connector.

Elaichi writes one entry for each connected-tool call that reaches execution (a call refused earlier writes none). The connection recorded is the account the call actually reached, taken from the execution, not from the intent. Each entry also names the surface and the client a call came through, so a reviewer can tell a Claude call from a Cursor call. The trail records the one path argument that names the object, as the target id, and nothing else about the arguments.

The audit history is scoped to each organization. A compliance reviewer can read the trail from the Auditor seat, which is free. Beyond the in-app trail, export to your own Datadog comes with the Black plan, which is launching soon. The fields an AI audit log must hold sets out what a reviewer should expect.

How do you compare the best MCP control plane platforms in 2026?

Compare mechanics, not feature lists. Ask each vendor five questions and get a number or a name for each answer.

1. How many addresses does a rollout create? One for the company, one per team, or one per member. Elaichi has one.
2. Who writes the connector for your most important app? And who fixes it when that app's API changes. Elaichi writes most of its connectors itself. For a native MCP connector, the app's own vendor writes the tools.
3. Where is access decided? Only at sign-in, at a gateway in front of the server, or where the tool is served. Elaichi checks against one resolver, everywhere a member can reach a tool.
4. How long does a change take? In Elaichi a role or restriction change takes about two minutes. Revoking a grant applies on the next call.
5. What does one audit entry hold? Elaichi's names the person, the tool, the outcome and the account reached.

Sort each vendor by these answers before reading its feature grid. A vendor whose setup asks you to run or register servers is a gateway. One that runs the connectors itself, serves one address and decides access on each call is a control plane. A dated, vendor-by-vendor shortlist applies the same questions to named products.

What does Elaichi cost?

Gold has a USD list price of $15 per user a month, or $120 per user a year. Elaichi has two plans, Gold and Black, and Black is launching soon. Visitors in some countries see a regional price, so the pricing page shows what you would pay.

Gold starts with a 14-day trial, no credit card to start. Checkout does collect a card, and it sets the paid trial to the remaining days rather than granting a fresh 14, so it is one continuous trial rather than two. Suspended members are not billed, and neither are the Guest, Billing Admin and Auditor roles. If a trial ends without checkout, the workspace pauses, and nothing is deleted.

At list price, 50 seats cost $6,000 a year on annual billing, or $9,000 billed monthly. Black adds customer-managed keys and audit export to your own Datadog, and neither is part of Gold. How vendors meter MCP access compares per-seat and per-call pricing.

What does an MCP control plane not do?

It is not built to front a fleet of MCP servers you already run, it does not see prompts, and it does not run inside your network. Each limit has a workaround or a better-fitting product.

Elaichi is the server for the connectors it authors. An internal MCP server your platform team built keeps its own address and sits beside Elaichi in the client, unless it is reachable over public HTTPS and added on Gold, or on Black once it launches, as a remote MCP connector. If the internal system is an HTTP API, a custom connector written from JSON config brings it under the same resolver and audit trail.

No MCP server sees the user's prompt, because the protocol does not carry it. The prompt-injection write gate lives in the Elaichi agent window and does not apply to a raw tool call. What holds on the endpoint is per-operation role permissions, OAuth scope limits, output redaction, a forbidden classification no scope can reach, and an audit row for each call that reaches execution.

Elaichi is hosted, so a requirement to deploy inside your own network points to self-hosted servers or a self-hosted gateway. A control plane is also a bet on one vendor's connector roadmap.

When is an MCP control plane more than you need?

When one person uses one AI client against one account. The client's own connector signs that person in, the app logs what was touched, and there is nothing to reconcile.

The same holds for a small engineering team calling two internal services from one client. A gateway in front of the servers it already runs fits that team better.

The case changes with the second of anything. A second AI client, a second account of the same app, a second team with different access, or a leaver whose access lives in more than one place. That is when one address, one rule set and one record start to pay for themselves. When an MCP gateway is premature lists the signals, and native client connectors set against one endpoint covers the stage in between.

For more on the protocol underneath, browse how MCP works. The team use cases show where rollouts usually start.

FAQ

What is an MCP control plane?

An MCP control plane is a single organization-wide MCP server that holds a company's connected app accounts, serves their tools to AI clients, and decides on every call whether the person calling may use that tool. It differs from an MCP gateway, which forwards calls to MCP servers that somebody else runs. Elaichi is a governed MCP control plane: every app account is connected once, and AI clients reach it through one address, https://api.elaichi.ai/mcp, with roles, restrictions and an audit log.

What is the difference between an MCP control plane, an MCP gateway and an MCP registry?

A registry lists MCP servers so clients and marketplaces can find them, and the official MCP Registry stores metadata that points to servers kept elsewhere. A gateway sits in front of MCP servers that a vendor or your own team runs, and adds one place for sign-in, policy and logging. A control plane serves the connectors, authoring most of them itself, holds the connections, and makes the access decision where the tool is served. With a control plane such as Elaichi, nobody at your company runs an MCP server.

Can one MCP endpoint serve Claude, ChatGPT and Cursor for a whole company?

Yes. Elaichi serves every organization from one address, https://api.elaichi.ai/mcp, and Claude, ChatGPT and Cursor all point at it. An admin adds the address once where the client allows it, and each member then connects and signs in with their own OAuth grant. No toolbox gets its own URL and no token sits in a client config, so adding a fourth MCP client follows the same steps.

Does Elaichi support SSO and SCIM?

Yes. Elaichi has SAML and OIDC single sign-on built in-house, plus SCIM v2 for users and groups with group-to-role mapping. Domains are verified through a DNS TXT record. A SCIM deprovision suspends the member rather than removing them, and suspension revokes every live OAuth grant, so that person's next call to the MCP endpoint is refused. Removing the member is a separate step an admin takes in Elaichi.

How much does Elaichi cost?

Elaichi has two plans, Gold and Black. Gold has a USD list price of $15 per user a month, or $120 per user a year, and visitors in some countries see a regional price on the pricing page. Black is launching soon. Gold starts with a 14-day trial, no credit card to start. Checkout does collect a card, and it sets the paid trial to the remaining days rather than granting a fresh 14, so it is one continuous trial rather than two. Guest, Billing Admin and Auditor seats are not billed, and neither are suspended members.

How do I connect Elaichi to Claude?

Add one URL, https://api.elaichi.ai/mcp, as a custom connector, then sign in with OAuth. To connect Elaichi to Claude on Team or Enterprise, an Owner adds the connector once and each member connects it. On Pro and Max you do both yourself. There is no API key to paste and no server to run.

A company's Claude rollout usually starts with one team asking for one app. The second request is a different app, and the third comes from someone who should only read. Adding each app's own connector means one setup per app, each with its own permissions model. One Elaichi connector covers every app the company connects, with one set of rules.

MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps, and the specification is public. Elaichi serves every connected SaaS account through one organization-wide endpoint, POST /mcp, behind OAuth.

Which Claude plans allow a custom connector?

All five. Anthropic's help center lists custom connectors on Free, Pro, Max, Team and Enterprise, in Claude on the web, Claude Desktop and Cowork, and limits Free to one custom connector (Anthropic's guide to custom connectors, checked October 2026).

Who adds it differs by plan. On Team and Enterprise, an Owner or Primary Owner adds custom connectors for the whole organization. Enterprise also lets a custom role that manages the organization's libraries add one (Anthropic's connector docs). Everyone else asks an Owner.

How does a Team or Enterprise Owner add the connector?

Once, for everyone, in the organization's settings. As of October 2026 the path is:

1. Open Organization settings, then Connectors.
2. Select Add, hover over Custom, and choose Web.
3. Paste https://api.elaichi.ai/mcp as the server URL.
4. Leave Advanced settings empty, and select Add.

Then each member opens Customize, then Connectors, finds the Elaichi connector, which usually carries a Custom label, and selects Connect. That sign-in is theirs alone. Nobody shares a credential, and what each member can reach is decided by their own role in Elaichi.

How do you add it on Pro, Max or Free?

From your own settings, in one pass. Open Customize, then Connectors, select the + button, then Add custom connector. Paste the URL, leave the advanced settings empty, and select Add. Anthropic gives these steps for Pro and Max, and Free plans can add one custom connector.

The advanced settings take an OAuth client ID and secret, and Elaichi needs neither. Anthropic's authentication docs say Claude uses a client ID metadata document only when the server advertises one, and otherwise falls back to dynamic client registration (how Claude authenticates connectors). Elaichi advertises no metadata document and supports registration under RFC 7591, so Claude registers itself.

Which address do you paste, exactly?

https://api.elaichi.ai/mcp, with no trailing slash, on the api host. That address answers an unsigned request with the challenge that starts sign-in. Two near misses do not.

• With a trailing slash, https://api.elaichi.ai/mcp/ returns 404.
• On the app host, https://app.elaichi.ai/mcp returns 405.

Neither carries the challenge, so Claude never reaches Elaichi's sign-in, and the connector looks broken for no visible reason. If sign-in never opens, check the URL first. Fixing OAuth errors when adding an MCP connector covers what to do when the sign-in itself fails.

What will Elaichi's consent screen ask you?

Which organization, and what the connector may do. If you belong to one organization, it is chosen for you. If you belong to several, nothing is preselected, and the one you pick is the only one Claude will see. Changing it later means connecting again.

The permissions arrive as up to four checkboxes:

• Read your organization's data
• Create and change data
• Run your connected tools
• Delete data and remove access

Everything Claude requested starts ticked except delete, which never does. Untick anything the person should not have. With Run your connected tools ticked, a second step asks which toolboxes Claude may use: All my tools, the default, or only the ones you pick.

How do Claude's tool permissions apply to Elaichi?

They apply to Elaichi's two discovery tools, not to each app's tools. In Elaichi, connected tools are never listed one by one, however few there are. Claude finds a tool with search_tools and runs it with execute_tool.

Claude lets you set each connector's tools to Always allow, Needs approval or Blocked, and its chat prompt offers Allow once or Always allow (Anthropic's getting-started guide). Because every connected tool runs through execute_tool, a permission on it covers every app at once. Leave it on Needs approval if you want a prompt before each call, and put the per-tool decisions in Elaichi's restrictions, which can tell a Jira read from a Jira delete.

Where does Claude connect from?

From Anthropic's servers, not the user's machine. The help center says Claude reaches a custom connector "from Anthropic's cloud infrastructure, rather than from your local device", on every Claude client. Elaichi's endpoint is public, so there is nothing to allowlist on your network for it.

The SaaS accounts are reached by Elaichi, not by Claude. A member connects each account once, from a catalog of 600+ connectors. Elaichi writes most of them, and the rest are the app vendors' own MCP servers. A separate credential service holds each account's secrets, encrypted at rest, and marks a connection needs_reauth when a refresh fails.

Does a member have to switch Elaichi on in each chat?

There is a switch per conversation. Under the chat's + button, then Connectors, each connector has a toggle that decides whether Claude may use it in that conversation. Turning it off does not disconnect anything: Claude stays signed in, and the toggle can come back on in any chat.

If Elaichi's tools seem to vanish in one conversation, check that toggle before anything else. If they are missing everywhere, MCP tools not showing up? Start here walks the checks in order.

What limits what Claude can do through Elaichi?

The member's role, what has been shared with them, and restrictions, checked on every call. Restrictions decide 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. A rule aimed at a member can only narrow what their role allows, and never replaces or loosens a role rule.

Frozen arguments pin a value the model must not choose, such as the workspace a team writes to. One condition: a freeze binds only calls made through its toolbox entry, so share the toolbox with the people it governs, not the connection itself. A role or restriction change takes about two minutes to apply, so test a new rule after that window, not straight away.

Elaichi keeps an audit trail of connected-tool calls. It writes one entry for each connected-tool call that reaches execution (a call refused earlier writes none), naming the account the call reached, and what an AI agent audit log must capture lists the fields.

How do you take Claude access away from someone?

Remove or suspend them in Elaichi, and their next request from Claude fails. In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change. A person can also disconnect Claude under Settings, then Connected apps, in Elaichi, which ends that one grant.

Disconnecting inside Claude signs Claude out of the connector, and the row then offers Connect again. To be sure the access is gone, end it on Elaichi's side. Offboarding AI access, contractors included covers the rest of a departure.

When is Claude's own connector for an app enough?

When one team needs one app and that app's own connector does what you need. Claude's connector directory lists connectors from many vendors. If a team needs only one of them, with that vendor's permissions and nothing across apps, use it. When you don't need an MCP gateway yet lists the signals that change the answer.

Elaichi's Gold plan is $15 per user per month in USD, and your region's price is on the pricing page. Gold starts with a 14-day trial, no credit card to start. Checkout does collect a card, and it sets the paid trial to the remaining days rather than granting a fresh 14, so it is one continuous trial rather than two.

The same address serves the company's other clients: the ChatGPT setup and the Cursor setup use it unchanged. To choose a first team, start from the connector catalog.

FAQ

Which Claude plans can connect to Elaichi?

Free, Pro, Max, Team and Enterprise can all add a custom connector, in Claude on the web, Claude Desktop and Cowork. Free is limited to one custom connector. On Team and Enterprise, an Owner or Primary Owner adds it for the organization, and members then connect it themselves.

Do I need an OAuth client ID to connect Elaichi to Claude?

No. Leave the advanced settings empty. Elaichi supports dynamic client registration and publishes no client ID metadata document, so Claude registers itself and each person signs in with their own identity.

Why does Claude list only a few Elaichi tools?

In Elaichi, connected tools are never listed one by one, however few there are. Claude finds a connected tool with search_tools and runs it with execute_tool, so a short list in the connector's settings is the expected view.

How do I stop someone using Elaichi from Claude?

Remove or suspend them in Elaichi. In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change, so their next request from Claude fails. A person can also disconnect the app under Settings, then Connected apps, which ends that grant.

What causes most OAuth errors when you add an MCP connector?

Four things: the address, the account, an expired request, or a missing permission. OAuth errors when adding an MCP connector look alike in every client, because the client only reports that sign-in failed. Elaichi's side says which step failed, and almost every fix is on the screen in front of you.

OAuth is the standard that lets Claude, ChatGPT or Cursor act for you without holding your password. The client registers itself, opens Elaichi's sign-in in your browser, and asks for a grant: a record of what it may do, for whom. OAuth 2.0 defines the flow, and its error names, such as invalid_grant, are the ones Elaichi returns.

What if sign-in never opens?

Check the address before anything else. Elaichi's endpoint is https://api.elaichi.ai/mcp, exactly. An unsigned request to it returns 401 with a pointer to Elaichi's sign-in details, and that 401 is what starts sign-in. Two near misses return no pointer:

• https://api.elaichi.ai/mcp/, with a trailing slash, returns 404.
• https://app.elaichi.ai/mcp, on the app host, returns 405.

Anthropic's docs say Claude needs that 401 to start sign-in (how Claude authenticates connectors). Its troubleshooting page names the two errors you see when it is missing or sign-in stalls: "Couldn't reach the MCP server" and "Authorization with the MCP server failed" (troubleshooting a connector). ChatGPT and Cursor word it differently, but the fix is the same address.

What does "Your organization requires signing in with SSO" mean?

Your company makes everyone sign in through its identity provider. When your email's domain belongs to an Elaichi organization that enforces SSO (single sign-on), Google, Microsoft, GitHub and email-code sign-in are refused with that message. The login screen then starts the SSO sign-in for you, and you land back on the same connection request.

Nothing is broken, and nothing needs an admin. Sign in the way your company asks, and continue.

Why does the consent screen say the request is no longer valid?

Because it expired or was already used. A connection request lasts 30 minutes and works once. Leaving the tab open over lunch, or double-clicking Allow, ends it. The screen says the request is no longer valid and offers a way back to Elaichi.

Start the connection again from the client: Claude's Connect, ChatGPT's app, or Cursor's server entry. That opens a fresh request. The 30 minutes are long enough to build a toolbox in another tab and come back, if the step that picks toolboxes sends you off to make one.

What if you are signed in to the wrong account or organization?

Use Not you? for the account, and connect again for the organization. The consent screen shows the signed-in email at the top. Not you? signs you out and returns you to the same request after you sign in as someone else.

The organization is chosen once per connection. With one membership it is chosen for you. With several, nothing is preselected, and the client will see only the organization you pick. Picking the wrong one means disconnecting and connecting again, and a second organization means a second connection.

If your account belongs to no organization yet, Continue and Allow stay disabled. The screen asks you to join or create one, then start the connection again.

Why are Continue and Allow greyed out?

Usually because nothing can be granted yet. Four cases disable them:

• No organization. The account has nothing to give access to.
• No organization picked. With several memberships, Continue waits until you choose one.
• No active plan. The screen says the organization requires an active Gold or Black subscription. An Owner or a Billing Admin fixes that.
• Nothing ticked. Untick every checkbox and the screen asks you to allow at least one thing or deny the request.

What does a "Not authorized" tool error mean after connecting?

The connection is missing a permission. The consent screen offers up to four: Read your organization's data, Create and change data, Run your connected tools, and Delete data and remove access. Everything the client requested starts ticked except delete, which never does. A client that asks for nothing gets read only.

When a tool needs a box that was not ticked, Elaichi answers the call with an error naming the checkbox and telling you to reconnect. It does not reject your login, because nothing is wrong with it. That answer arrives as a normal response, and Anthropic's docs say Claude ignores a sign-in challenge on such a response, so Claude will not ask on its own. Disconnect, reconnect, and tick the box. This works only if the client requested that permission in the first place.

Why did a working connection stop with invalid_token or invalid_grant?

Because the grant behind it was revoked, or its refresh token lapsed. An access token lasts one hour, and the client refreshes it quietly. A refresh token lasts 30 days and is replaced on every use. A client unused for more than 30 days therefore has to reconnect, and the grant itself never expires while it is used.

Other things end a grant too. You disconnect the app under Settings, then Connected apps, the client revokes it, an admin removes or suspends you, or an old refresh token is used twice. In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change, and the next request returns invalid_token. Elaichi deliberately makes unknown, expired and revoked tokens look the same, so the fix is the same: reconnect.

What does a 429 mean?

Too many requests in a minute. Elaichi accepts 30 OAuth requests a minute, counted per client for most of the flow and per network address for registration, and 120 MCP requests a minute per token. Over either limit you get 429 with a Retry-After of 60 seconds. Wait a minute and try again.

Which errors can you fix yourself, and which need an admin?

An empty tool list after a clean sign-in is not an OAuth error at all. MCP tools not showing up? Start here walks those checks in order.

What should a custom MCP client send?

The standard flow, with PKCE (Proof Key for Code Exchange) on every request. Register at the endpoint the discovery document names, under RFC 7591. Then send a code_challenge with code_challenge_method=S256, as RFC 7636 defines. Elaichi does not assume S256 when the method is missing, and it refuses plain.

Three more rules catch hand-built clients:

• The redirect URI must match. It must be exactly one you registered. The only allowance is a loopback address changing its port.
• The resource must be Elaichi's. If you send one, it must be on https://api.elaichi.ai, or the request fails with invalid_target.
• Scopes come from a fixed list. Ask only for mcp:read, mcp:write, mcp:destructive, mcp:tools, openid and email. Anything else, such as offline_access, returns invalid_scope.

The MCP authorization specification describes the discovery steps a compliant client follows.

What does sign-in not decide?

Which tools the person can call. A clean sign-in proves who they are and what the connection may attempt. Their role, what is shared with them and restrictions decide the rest. Restrictions decide which connectors and which individual tools a target may reach, and a role or restriction change takes about two minutes to apply.

To set the connector up from the start, follow the Claude setup, the ChatGPT setup or the Cursor setup. Elaichi's Gold plan is $15 per user per month in USD, with your region's price on the pricing page.

FAQ

Why does sign-in never open when I add the Elaichi connector?

The address is usually wrong. https://api.elaichi.ai/mcp answers an unsigned request with the 401 challenge that starts sign-in. With a trailing slash it returns 404, and on the app host it returns 405, and neither carries the challenge.

How long does an Elaichi sign-in last?

An access token lasts one hour, and the client refreshes it. A refresh token lasts 30 days and is replaced on every use, and the grant itself never expires. A client left unused for more than 30 days has to reconnect.

Why does a tool say I am not authorized after I connected?

The connection is missing a permission, such as running connected tools or deleting. The message names the checkbox. Reconnect in the client and tick it on Elaichi's consent screen. Your login is fine.

Which Elaichi sign-in problems need an admin?

Having no organization, no longer being a member, a role without the tool:execute permission, a restriction, or an organization without an active Gold or Black plan. The person connecting cannot fix those.

Why are my MCP tools not showing?

Usually because they are not supposed to show. With Elaichi, MCP tools not showing in the client's tool list is the design. In Elaichi, connected tools are never listed one by one, however few there are. Claude, ChatGPT or Cursor sees two tools, search_tools and execute_tool, and uses them to find and run every connected tool.

Hundreds of tool definitions crowd a model's context, and a long list makes the wrong pick likelier. So Elaichi lists only what the model needs to find a tool, and ranks each search against what the person can reach. The MCP context window problem, and a fix explains the trade-off.

So start with what the list should contain. If it matches, the connection works, and a missing tool is one of the five checks below.

What should an Elaichi tool list contain?

Three kinds of entry, and the connected tools are never among them:

• Elaichi's own operations, whose names start with elaichi__, listed individually when the person's role and the connection's permissions allow them.
• search_tools and execute_tool, present while at least one connected tool is reachable.
• Nothing per app. A Jira or Zendesk tool never appears in the list itself.

If search_tools and execute_tool are both missing, no connected tool is reachable yet, and the first two checks below are the likely reason.

Is the app connected at all?

Check under Connections in Elaichi. If the app is not there, nothing can find its tools, and the fix is to connect it from the connector catalog.

Search makes this case visible. A search naming an app the person never connected returns no results, with a line naming up to six apps the connection does reach. That empty answer is deliberate: a tool from the wrong app would be worse than none, because the model would call it.

Is the connection active?

A connection that is not active contributes no tools at all. It is missing from the results, not present and failing. In the console a broken connection shows Needs sign-in, and one nobody finished shows Awaiting sign-in.

Open the connection under Connections and select Reconnect, or Finish sign-in for one that never completed. Then complete the app's own login. Reconnecting rebinds the same connection to the same account, so its shares and toolbox entries survive.

Who may do it is narrow. The owner, someone with edit access, or an admin over a shared connection can reconnect. Only the owner can finish a connection that never completed, because finishing it binds a new identity.

Could a restriction withhold the tool?

Yes. A restricted tool is withheld from the tool list and cannot be called. If the assistant searches for it, it sees only the name, flagged restricted, with no description or schema. Restrictions decide which connectors and which individual tools a target may reach. A connector restricted whole shows as one row for the connector.

The console marks restricted tools too. Anyone who can view the connector sees each tool flagged restricted, so confirming one needs no restriction permission. Only an admin can change the rule. Watch for one trap when allow rules are involved: the allowlist stage engages on the presence of an allow rule, not its contents, so an allow rule that names nothing denies everything.

A restriction change takes about two minutes. Test it after that window.

Does the connection have permission to run tools?

It needs one checkbox on Elaichi's consent screen: Run your connected tools. Without it, the connection can use Elaichi's own operations but no connected app. A tool call answers with an error naming that checkbox and asking you to reconnect and tick it.

Two narrower cases look the same from the client:

• Delete tools hide without the delete permission. A tool that deletes is left out of search entirely unless Delete data and remove access was ticked.
• A connection limited to chosen toolboxes reaches only their tools. If none of those toolboxes can be used any more, it reaches nothing, never everything. Edit the choice under Settings, then Connected apps, in Elaichi.

Fixing OAuth errors when adding an MCP connector covers reconnecting and the consent screen in detail.

Did the search name the tool?

Search matches words, not meaning, so phrase the request the way the tool is named. Ask for "list Jira issues" rather than "what is the team working on". The model searches with search_tools and calls the result through execute_tool.

A search returns nothing rather than a weak match from another app. That floor keeps the model from running a Notion tool when you asked about Cal.com. How MCP tool search picks one tool from hundreds explains the ranking.

Why is the whole list empty?

The person's role lacks tool:execute. Without that permission the list is empty at every level of access the connection holds, and every call answers with an error naming the permission and saying that reconnecting will not help. Guest, Auditor and Billing Admin lack it, while Member and above hold it.

That fix belongs to an admin, who changes the role. A Billing Admin or an Auditor who signs in to look at Elaichi from Claude will always see an empty list, and that is correct.

An organization can also switch off Elaichi's own operations. They then disappear from every list, while connected tools keep working.

Why did the tools not appear after a change?

Because the client is holding an old list. The MCP specification lets a server declare whether it will send a notification when its list of tools changes. Elaichi declares that it will not, so a client keeps whatever list it last read.

Most changes do not need a fresh list, because connected tools are found by search, not by the list. The exception is the first app. search_tools and execute_tool appear only once a connected tool is reachable, so a client that read its list before then does not have them. Start a new conversation, or disconnect and reconnect, to make it read the list again.

In Claude, also check the conversation's own switch. Each chat has a toggle per connector under the + button, then Connectors, and a connector switched off there sends nothing (Anthropic's getting-started guide). Cursor offers a similar per-server switch under Customize (Cursor's MCP docs).

Who fixes which cause?

Once tools appear, the Claude setup and the ChatGPT setup cover what to set before a team relies on it.

FAQ

Why does my MCP client show only search_tools and execute_tool?

Because that is how Elaichi works. In Elaichi, connected tools are never listed one by one, however few there are. The client looks a tool up with search_tools and runs it with execute_tool, so those two in the list mean the connection is working.

Why is my Elaichi tool list completely empty?

Your role probably lacks the tool:execute permission. Without it the list is empty whatever the connection allows, and every call says so. Guest, Auditor and Billing Admin lack it. An admin has to change the role.

Does Elaichi tell my client when the tool list changes?

No. Elaichi declares that it sends no list-changed notifications, so a client keeps whatever list it last read. Start a new conversation or reconnect if a newly connected app's tools do not appear.

How long does a restriction change take to show up?

Role and restriction changes take about two minutes, on every surface. Grant revocation, member removal and suspension take effect on the next call.

Elaichi vs Composio: what is the difference?

Elaichi vs Composio comes down to who writes your connectors and how many MCP addresses your company hands out. Elaichi writes, maintains and serves its own connectors. Every AI client reaches them through one organization-wide endpoint, and each member signs in with their own grant. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps.

Take twenty people who want Claude or ChatGPT to read the CRM, file tickets in Jira and pull invoices from Xero. Several products answer that request, and these two answer it with different designs.

Composio's docs describe Composio Connect as an MCP server at connect.composio.dev/mcp that gives an agent access to "1000+ apps". It does so through seven meta-tools rather than one listed tool per app action. Each app is approved through an OAuth link in the browser (Composio Connect docs, checked October 2026).

Its MCP Gateway page describes the shape Composio offers a company: "one gateway, every server", where "each team gets its own MCP endpoint carrying only the tools it is permitted to use". That page counts "1,500+ apps available" (Composio MCP Gateway, checked October 2026). These are two coherent designs for two different buyers, and neither is a strict upgrade of the other.