# Unsanctioned Automation AI Tools: Finding One

> Unsanctioned automation AI tools usually start as one teammate's personal Zap. How to inventory it, and why per-member accounts become an offboarding risk.

**TL;DR** Unsanctioned automation AI tools are usually one capable person's personal account doing real work for the team. Inventory it by naming the trigger, the apps, the account and the credential behind each step. Then move the work onto connections and toolboxes an admin can see in Elaichi. Every call there runs as a known person and lands in one audit log.

## The situation

A weekly report stops arriving. You ask around and someone on the team says, "Oh, that's my Zap, I'll fix it when I'm back." It pulls from the CRM, writes to the finance sheet and posts to Slack. It has run every Monday for eleven months. Nobody filed a ticket for it, nobody reviewed it, and it sits in an account you cannot open.

This is what unsanctioned automation AI tools usually look like in practice. Not a rogue deployment. One capable person solved a real problem with the tools in front of them, on their own login. They never had a reason to tell IT. The automation works. That is the part that makes it awkward: you cannot simply switch it off, because something downstream now depends on it.

The response has two halves. First, find out exactly what it does and what it runs as. Second, move the work onto access an administrator can see, without breaking the report in the meantime.

## What counts as unsanctioned automation ai tools, and what does not

An automation is unsanctioned when no administrator can see what it reaches or change who it runs as. The test is not which vendor it uses. It is whether you, today, can answer two questions about it: which accounts does it touch, and whose credentials does it use.

By that test, a Zap built on one person's connected apps is unsanctioned. So is a Python script on a laptop running on a personal API token. So is a scheduled agent task somebody set up in their own chat app against their own connected accounts. OpenAI says scheduled tasks in ChatGPT can use connected apps such as Gmail, Slack and GitHub ([help.openai.com](https://help.openai.com/en/articles/10291617-scheduled-tasks-in-chatgpt), checked October 2026). Anthropic says a Claude Code routine includes every MCP connector the user has currently connected, by default. During a run, Claude can use any tool from an included connector, writes included, without asking permission ([code.claude.com](https://code.claude.com/docs/en/web-scheduled-tasks), checked October 2026).

A workflow running in a shared company account that your identity provider provisions is not unsanctioned, even if nobody reviewed its logic. You can at least see it and take it over.

Make the distinction out loud when you talk to the person who built it. They did not break a rule that existed. The gap is organizational, not personal, and the conversation goes better when you say so first.

## How to inventory the automation

Inventory it step by step. Write down four things per step: the trigger, the apps it touches, the account each step acts as, and the credential behind that account. Everything else is detail.

Work through it with the builder at their screen, not from a description. Ask for each step:

- **What starts it.** A schedule, a webhook, a form submission, a message in a channel. A schedule means it runs with nobody watching.
- **Which apps it reads and which it writes.** Reads are an exposure question. Writes are a blast-radius question. A step that posts a message and a step that updates a deal record need different levels of care.
- **Whose account each step acts as.** In most personal automations the answer is the builder, for every step. Confirm it rather than assuming it.
- **What credential sits behind that account.** An OAuth connection the builder approved, [a personal API key pasted into a field](/blog/stop-sharing-personal-api-keys-with-ai-tools/), a service account somebody made two jobs ago.
- **Who reads the output.** This tells you how urgent the handover is. A report three people glance at is different from one that feeds a month-end close.

Two things are worth capturing beyond the steps. Note any value the automation hard-codes: a folder id, a spreadsheet tab, a channel. Those are the arguments somebody will have to get right again when the work moves. And note anything the automation has silently accumulated reach into, such as a folder shared with the builder's account after the automation was built.

Finding the MCP servers people installed on their own machines is a separate sweep. [The inventory for local MCP servers](/blog/find-mcp-servers-employees-installed/) covers that method.

## Why per-member automation accounts become an offboarding problem

The problem is structural. In most automation platforms the unit of ownership is per person. The automation and its credentials live inside one member's account, not in a shared place an administrator controls.

Zapier documents this plainly for its MCP product. In Zapier MCP the per-person unit is the server, not the address. Each user creates and owns their own servers on their Zapier account, one per named MCP client, and the endpoint URL is shared ([docs.zapier.com/mcp/manage/security](https://docs.zapier.com/mcp/manage/security), checked September 2026). Zapier also tells people to treat a connection token like a password and keep it in an environment variable or a secret manager. It advises giving each user their own server and token instead of sharing one ([docs.zapier.com/mcp/manage/security](https://docs.zapier.com/mcp/manage/security), checked September 2026). Its quickstart separately tells people not to distribute a connection token or a connection-token URL ([docs.zapier.com/mcp/get-started/quickstart](https://docs.zapier.com/mcp/get-started/quickstart), checked October 2026). That advice is sound for the credential. It also means the thing holding your weekly report together is bound to one person's account.

What happens to those servers when the member leaves is another matter. It is not documented on Zapier's security page, titled "Zapier MCP security: SOC 2 access controls & compliance" ([docs.zapier.com/mcp/manage/security](https://docs.zapier.com/mcp/manage/security), checked September 2026). Nor is it on its pages "Share access to your MCP server" or "Usage and billing". A certification named in a page title is the vendor's own claim; Elaichi's are published in its [Trust Center](https://trust.elaichi.ai). Put the offboarding question to Zapier for your own account rather than guessing at the answer.

The point for an ops lead stands either way: you cannot plan an offboarding around behavior nobody has told you about. A departure checklist that says "disable accounts" does not tell you which automations stop. Nor does it say which keep running on a credential nobody owns, or which reach an app with a token that outlives the person.

And this is the ordinary case, not the dramatic one. Somebody changes team, goes on leave, or just stops maintaining the thing. Three months later a number in a report is wrong and nobody can open the automation to see why.

## The shape of moving it onto shared governed access

Moving the work means three changes. The credential stops being personal. The identity each call runs as becomes a known person an administrator can see. The activity lands in one log.

In Elaichi, the pieces that do this are connections, toolboxes and restrictions. A connection is one connected account, held as a single row the organization reuses. The same connection can be pinned into any number of toolbox entries. A sharing grant extends it to a user, a team or the whole organization, without reconnecting. A toolbox is a named list of tool entries, each pinned to a connection. A restriction says which connectors and tools a role or a member may reach.

Three decisions decide the shape of the move.

**Who the calls should act as.** Where the app on the other end should see each person, the tools run on each person's own connections. A toolbox shared with a team runs each entry on the connection pinned in it, under the authority of whoever pinned it. One shared toolbox therefore cannot give everyone their own identity in the app. If the automation genuinely needs one fixed identity, a shared connection is the right answer. The person whose account backs it should be someone who will stay.

**What it may reach.** Write the restriction for the role that will use it. A block rule naming specific tools keeps the destructive ones out of reach. An allow rule is stricter. Once a role carries any allow rule, every connector and tool its allow rules do not name is blocked for that role. A role held to one app's read tools therefore needs allow rules for every other app it uses. [Blocks and allows match differently](/blog/block-matches-name-allow-matches-operation/), which is worth understanding before you write either.

**Which arguments are fixed.** The hard-coded values from your inventory become frozen parameters on a toolbox entry: argument values written into the entry that a caller cannot override. The AI client can see that they are set, and often what they are, but cannot change them. [Locking an agent's arguments](/blog/frozen-parameters-wire-transfer-receiver/) covers where that holds and where it does not.

One honest limitation about what moves and what does not. Elaichi's MCP endpoint serves tools to AI clients at one address; a scheduled, unattended job is not something it runs for you. Elaichi's MCP sign-in supports only the authorization-code grant with PKCE, plus refresh. A new connection always needs a person to approve a consent screen in a browser. If your automation's value is the schedule, you keep a scheduler. What changes is that the apps it reaches sit behind governed connections rather than one person's tokens. [Governing scheduled agent tasks](/blog/scheduled-ai-agent-tasks-safely/) sets out what is controllable in advance.

## When you do not need to move it at all

Sometimes the right answer is to leave it where it is and write it down. If an automation reads one low-sensitivity source, writes nowhere, and would cost nothing if it stopped, the governance work is not worth the disruption. Put it on a list, note the owner and the accounts, and move on.

The list matters more than the migration. An automation you know about, with a named owner and a recorded set of accounts, is manageable even on a personal credential. An automation you discover during an offboarding is not. Most of the value of an inventory sweep is the inventory, not the rebuild.

If you are deciding whether you need a control plane at all, [the case for not buying one yet](/blog/when-you-dont-need-an-mcp-gateway/) is worth reading first. And when the departure does come, [offboarding AI access](/blog/offboarding-when-the-agent-holds-access/) covers what one removal does and does not reach.

To see which of your apps Elaichi already carries, browse the [connector catalog](/connectors/).

## FAQ

### What makes an automation unsanctioned rather than just undocumented?

An automation is unsanctioned when no administrator can see what it reaches or change who it runs as. The test is not which vendor built it. It is whether an admin can answer two questions today: which accounts does it touch, and whose credentials does it use. A workflow in a shared company account that the identity provider provisions is reviewable even if nobody has reviewed it. A workflow on one person's personal login is not.

### How do you inventory an automation somebody built in a personal account?

Go through it step by step with the person who built it, at their screen. Record four things per step: the trigger, the apps it reads and writes, the account each step acts as, and the credential behind it. Also note every hard-coded value, such as a folder id or a channel. Those become the arguments somebody has to get right again when the work moves. Note who reads the output too, because that tells you how urgent the handover is.

### Does each Zapier MCP user get their own server?

Yes. Zapier's own documentation says that in Zapier MCP the per-person unit is the server, not the address. Each user creates and owns their own servers on their Zapier account, one per named MCP client, and the endpoint URL is shared. Zapier also advises giving each user their own server and token rather than sharing one, and treating a connection token like a password. See docs.zapier.com/mcp/manage/security, checked September 2026.

### What changes when automation work moves onto governed access in Elaichi?

Three things. The credential stops being personal and becomes a connection an organization reuses through sharing grants. The identity each call acts as becomes a person an administrator can see, because every connected-tool call runs as one specific person. And the activity lands in one audit log, with the person, the connector, the connection and the MCP client recorded for each call that runs.

### Can Elaichi run a scheduled automation in place of Zapier?

No. Elaichi serves MCP tools to AI clients at one address. Its sign-in supports only the authorization-code grant with PKCE, plus refresh. A new connection always needs a person to approve a consent screen in a browser, and nothing lets a client obtain one unattended. If the schedule is the point, keep a scheduler. What changes is that the apps it reaches sit behind governed connections rather than one person's tokens.

## Read next

- [Find the MCP servers employees have installed](/blog/find-mcp-servers-employees-installed/) — No admin console lists the MCP servers employees have installed. The order that works: a device sweep, the vendor logs that exist, then a direct ask.
- [Stop sharing personal API keys with AI tools](/blog/stop-sharing-personal-api-keys-with-ai-tools/) — Find where people sharing personal API keys with AI tools put them, lean on what the key issuers already catch, then remove the reason to paste one.
- [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.