# Shadow AI at a Small Company: The Smallest Real Step > Shadow AI at a small company rarely needs a policy program. The smallest fix is one endpoint, read-only rules on two apps, and one audit screen you can read. **TL;DR** Shadow AI at a small company is usually two or three people pasting customer records into an assistant because no sanctioned path exists. The smallest real step is one MCP endpoint everyone signs into, read-only restrictions on the two apps that hold customer data, and an audit log you can read in one screen. Elaichi gives you all three without hiring an IT function, and if nobody is touching customer data yet, you do not need any of it. ## The founder's version of this problem You have 30 people. Nobody's job title contains the word "security". Somebody in support has a ChatGPT account they pay for themselves, somebody in sales pastes account notes into Claude to draft follow-ups, and an engineer [wired a local MCP server](/blog/replace-personal-mcp-servers/) to the production database on a Saturday. None of this was malicious. There was no sanctioned way to do the thing, so people did the thing anyway. That is shadow AI at a small company, and it does not look like the enterprise version. There is no CASB to tune, no identity team to escalate to, no quarter-long rollout. There is you, an afternoon, and the question of what the smallest honest step is. The answer is three things: one address everyone signs into, read-only rules on the two apps that hold customer data, and a log you can read in one screen. Nothing else. Not a policy document, not a vendor review, not a ban. ## Does shadow AI at a small company need any fix yet? Often, no. If your 30 people use one assistant, it has no connectors attached, and nothing with customer data has been pasted into it, you have an unsanctioned tool and not an unsanctioned data path. Those are different problems with different costs. The test is concrete, because each client documents its own path. On Claude Team and Enterprise, an Owner or Primary Owner adds a custom connector from Organization settings > Connectors, and each member then connects it under Customize > Connectors ([Anthropic](https://support.claude.com/en/articles/11175166-get-started-with-custom-connectors-using-remote-mcp), checked October 2026). OpenAI says full MCP support in ChatGPT, including modify and write actions, is rolling out in beta to the Business, Enterprise and Edu plans ([OpenAI](https://help.openai.com/en/articles/12584461-developer-mode-and-mcp-apps-in-chatgpt), checked October 2026). Cursor reads MCP servers from .cursor/mcp.json in a project and from ~/.cursor/mcp.json in the home directory ([Cursor](https://cursor.com/docs/mcp), checked October 2026). Ask three questions and answer them honestly: 1. Has anyone connected an app to their assistant, through a Claude connector, a ChatGPT app, or an MCP server on their laptop? 2. Does any of those apps hold customer records, contracts, payroll or payment data? 3. If a customer asked what their data was used for last month, could you answer? If the answers are no, no, and not-applicable, buy nothing. Write one paragraph saying what people may paste and what they may not, send it, and move on. Revisit it when somebody asks to connect an app, because that request is the real trigger. A post on [when an MCP gateway is premature](/blog/when-you-dont-need-an-mcp-gateway/) walks the same line in more detail. If the answer to question two is yes, keep reading. The gap between "people paste text" and "an assistant reads our CRM on its own" is where the real exposure starts. ## Step one: one endpoint instead of six setups The first move is to give people a sanctioned path, because a ban without one is a ban people route around. Elaichi serves MCP at one address, https://api.elaichi.ai/mcp, and it is the same string for every organization. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. Claude, ChatGPT and Cursor all sign into that one address with OAuth. There is no per-person URL, no per-team URL, no token in a query string for somebody to paste into Slack. Each person connects their client once, approves their own grant on Elaichi's consent screen, and from then on every call that client makes acts as them, in the organization they picked. That last part matters more than it sounds for a 30-person company. You are not creating a shared service account that everybody borrows. Each member's grant is their own, and every MCP request re-reads it, so revoking one person's grant stops their client on the next call. The setup cost for you is one connector per app you want reachable. The setup cost per person is signing in once, which they already do for every other tool. Walkthroughs for the two clients most people have live at [connect Elaichi to Claude](/blog/connect-elaichi-to-claude/) and [the ChatGPT setup](/blog/connect-elaichi-to-chatgpt/). The trade-off: one endpoint means the restriction work is now yours to do. Nothing about a single address makes anything read-only by itself. That is step two. ## Step two: read-only on the two apps that hold customer data Pick the two apps holding customer records. For most companies at this size it is a CRM and a support inbox, or a CRM and a billing system. Those are the two where a wrong write costs you a customer conversation rather than an internal cleanup. In Elaichi, a restriction says which connectors and tools a role or a member may reach. In Elaichi, restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything. So for a 30-person company, write the rules on the Member role, which is where almost everyone sits. There are two ways to make an app read-only, and the difference trips people up: - **Block rules naming every write tool on that connector.** A layer with only block rules has no allowlist, so everything it does not block passes. If you miss a tool, that tool stays reachable. On a connector with 150 tools this is tedious and easy to get wrong. - **An allow rule naming the read tools.** Cleaner, but an allow rule turns on the allowlist for its whole layer. Once the Member role carries any allow rule, every connector and tool that none of its allow rules names is blocked for that role, across the catalog. So the role also needs whole-connector allow rules for every other app it uses. For two apps and thirty people, the allowlist path is usually the right one, because it fails closed. Write allow rules naming the read tools on your two customer-data connectors, plus whole-connector allow rules for everything else the team legitimately uses. Anything new that appears in the catalog is blocked until you name it, which is the behavior you want. Two details that save a support ticket later. Allow rules match the operation a tool performs, pinned when you save the rule, not the label the tool is shown under. Block rules match by name or by operation. And a restriction change is not instant: it takes effect in about two minutes, because the resolved rules are cached per organization. Grant revocation, member removal and suspension are the exceptions and apply on the next call. What a restriction does not do: it does not hide the tool. A restricted tool still appears in Elaichi's tool search, named and flagged as restricted, with no schema and no way to call it. The model can see that it exists and tell the person to ask an admin. From the client, a person can file their own access request, which you then approve or deny in the console. For which rules suit which situation, [restrict one tool or the whole app](/blog/per-tool-vs-per-app-restrictions/) lays out six cases. ## Step three: an audit trail you can read in one screen Every connected-tool call that reaches execution writes an audit row. One screen, Governance in the console, shows the organization's whole log: newest first, 50 per page, with a free-text search, a category filter, an actor filter and four date ranges. Each row answers the questions you would actually be asked. The console's detail panel writes it as a sentence, for example "Using Claude, Emily Carter updated the page 'Q4 Roadmap' in Notion through the connection 'Acme Notion'." Alongside it sit lines for the connector, the connection, the toolbox, what it did (Read data, Changed data or Deleted data), how approval was given, and the outcome. Three things the log deliberately does not record, so promise a customer nothing that depends on them: - It records no argument values, with one exception: the single URL path argument that names the object becomes the target id. So you see which record was touched, not the body of what was written. - Scope refusals write nothing, because that refusal happens before any executor runs. Tool search and tool listing write nothing either. - Passkey sign-ins produce no sign-in audit event. Who can read it: anyone holding audit:view sees every event in the organization, and among the built-in roles that is Org Owner, Org Admin and Auditor. Everyone else sees their own events plus events on connections they own or can edit. The Auditor role is a free seat, so adding your accountant or a fractional security reviewer as an Auditor costs nothing in billing. Retention is 90 days. If you need longer, forwarding the log to your own Datadog comes with the Black plan, which is launching soon. At 30 people, 90 days of searchable history and a CSV export of the current view is usually the whole requirement. For the fuller list of what belongs in a record like this, see [what an AI agent audit log must capture](/blog/what-an-ai-audit-log-must-capture/). ## What this costs you in time and money Time: the endpoint is one string you paste into each client's settings, so the per-person cost is a sign-in. The restriction work is where the afternoon goes, mostly in reading your two connectors' tool lists and deciding which reads the team needs. Money: Gold lists at $15 per user per month in USD, or $10 per user per month billed annually, and every new organization starts on a 14-day Gold trial with no payment details. Elaichi sells two plans, Gold and Black, and nothing sits below them. Guest, Billing Admin and Auditor are free seats, so an auditor or a bookkeeper does not count toward billable members. Check [/pricing/](/pricing/) for your own country's price, since Gold is priced regionally. What you are not buying at this size: custom roles beyond the built-in eight, SSO enforcement, SCIM provisioning. All of those are on Gold, but a 30-person company usually does not need them in month one. Add them when you have an identity provider worth syncing from. ## The order to do it in Do not start with the restrictions. Start by finding out what is already connected, because the rules you write should answer a real path rather than an imagined one. [Finding the MCP servers employees have installed](/blog/find-mcp-servers-employees-installed/) covers the discovery side, and it is honest about what admin consoles cannot see. Then: endpoint, two apps, rules on the Member role, one look at the log a week later. If the log shows people reading things you did not expect, that is the rules working as designed, and the fix is a conversation rather than a lockdown. If the log is empty, nobody adopted the sanctioned path, and you have a rollout problem rather than a governance one. For the apps themselves, browse [the connector catalog](/connectors/) to see which of your two are already there. If one is not, an Org Owner or Org Admin can add its own remote MCP server as a connector on Gold. ## FAQ ### What is shadow AI at a small company? Shadow AI at a small company is employees using AI assistants with company data through paths nobody sanctioned: a personally paid ChatGPT account, a Claude connector attached to a work app, or an MCP server configured on a laptop. At 30 people it usually starts because no approved path exists, not because anyone is evading a rule. The exposure that matters is not the tool itself but whether it reaches apps holding customer records, contracts, payroll or payment data. ### Do I need an MCP gateway for 30 people? Not always. If everyone uses one assistant, no apps are connected to it, and nothing with customer data has gone into it, you have an unsanctioned tool rather than an unsanctioned data path, and a short written rule about what may be pasted is enough. The trigger to add governance is the first request to connect a real app, because that is when an assistant starts reading records on its own rather than reading what someone pasted. ### How do I make an app read-only for AI assistants in Elaichi? Write restrictions on the role the team holds. Two shapes work: block rules naming every write tool on that connector, which fails open if you miss one, or an allow rule naming only the read tools, which fails closed. The allow rule turns on an allowlist for that whole role, so the role also needs whole-connector allow rules for every other app it uses. A restriction change takes effect in about two minutes. ### Who can read the audit log in Elaichi? Anyone holding the audit:view permission reads every event in the organization. Among the built-in roles that is Org Owner, Org Admin and Auditor. Everyone else sees their own events plus events on connections they own or can edit. Auditor is a free seat and does not count toward billable members, so adding a reviewer or accountant for oversight costs nothing in billing. Elaichi keeps 90 days of audit history. ### Does a restriction hide the tool from the AI assistant? No. A tool a restriction blocks still appears in Elaichi's tool search for that person, named and flagged as restricted, with no schema and no way to call it. A connector blocked whole shows as one row for the connector. The person can file their own access request from the chat client, which an admin then approves or denies in the Elaichi console. Hiding the tool entirely is not how restrictions work. ## Read next - [Engineers using ChatGPT at work: block or scope it](/blog/shadow-ai-cto-engineers-already-have-chatgpt/) — For engineers using ChatGPT at work, scope access rather than block it. A block moves the paste to a phone; scoped access removes the reason to paste. - [Employees pasting customer data into AI](/blog/shadow-ai-coo-customer-emails-pasted/) — No single log records employees pasting customer data into AI. Measure it from three partial sources, report a range, and remove the reason to paste. - [Replace personal MCP servers on employee laptops](/blog/replace-personal-mcp-servers/) — Find the MCP servers employees run from each client's config file, then replace personal MCP servers and their tokens with one governed endpoint.