What does MCP connector lineage identity mean?
MCP connector lineage identity is a connector's own slug plus the forks that declare descent from it. Nothing else. Not the hostname it calls, not the shape of its config, not how closely it resembles another connector in the catalog.
The situation that makes this matter is ordinary. An admin writes a block rule on a role, naming one connector. A week later a member with the connector:create permission forks that connector, renames half its tools, and starts using the copy. Whether the original block still applies is not a matter of judgment. It is decided by the lineage recorded on the fork.
Some vocabulary, once. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. A connector is the thing Elaichi runs an app through. Elaichi authors and runs most of the ones in its catalog. A team on Gold can also author its own, or bring a remote MCP server under the same rules. A restriction is a rule on a role or on one member. It says which connectors and tools that person may reach. A fork copies a source connector's config, method documentation, category, logo and icon into a new connector owned by whoever forked it. The fork records the source as its upstream.
That recorded upstream is the lineage. It is a declaration, not an inference. Elaichi never works out that two connectors look alike and treats them as kin.
Why isn't the host part of a connector's identity?
Because Elaichi checks a custom connector's config for shape, not for where it points. A connector built from scratch against the same API as a blocked connector is not caught by that block. The connector:create permission text says so in the role editor: a connector can be pointed at any destination.
This is the trade-off, and it is deliberate rather than an oversight. Host-based identity reads well in a policy document and fails in practice. One API answers on many hostnames, regional endpoints included. A proxy puts any host in front of any API. A connector config can be edited after the rule was written. A restriction that bound hosts would pass a security review. It would then let through the first new connector someone aimed at the same service under a different name.
So Elaichi binds the two things it can prove: the connector row itself, and the lineage declared on it. Everything else about new connectors is a permissions question, not a restriction question. That is why connector:create is the only permission Elaichi flags "High trust". Among the system roles, only Org Owner and Org Admin hold it. If a role should not be able to create a destination, the answer is to keep connector:create out of that role, not to write a cleverer block.
Client-side controls bind identity the same way, by what a server declares. Anthropic's managed MCP documentation says Claude Code matches allow and deny entries by a remote server's serverUrl, by an exact stdio command, or by serverName. It warns that a serverName entry is not a security control, because the name is a label the user assigns (checked October 2026).
Cursor's enterprise documentation says its MCP allowlist matches a stdio server's full command string, or a remote server's URL. Both accept * wildcards (checked October 2026). VS Code's enterprise settings documentation says a deny entry takes precedence over an allow entry in its per-server MCP policies (checked October 2026).
None of those matches a fork. Elaichi's lineage walk runs on the server side, against the descent a fork itself declares.
How far does Elaichi walk a fork chain?
Up to 8 hops toward the root. A block on a connector also blocks every fork that declares descent from it, including forks of forks, and the walk stops at 8.
A chain that runs longer than 8 hops, loops back on itself, or has a broken link is refused outright rather than checked partially. Failing closed here is the only honest option. A half-walked chain produces an answer nobody can act on. The cheapest way to defeat a lineage check would otherwise be to stack forks until the walker gave up.
The same posture shows up elsewhere in the restriction path. When the resolver gets an answer in a shape it does not recognize, it refuses the call. It does not cache that answer either. One case is an organization's data store still running older code during a deploy.
One consequence surprises people. Deleting a custom connector removes every share on it and its owner record, but its forks keep their place in the lineage. A restriction naming the deleted connector still binds those forks.
Why does lineage only ever add blocks?
Because an allow rule naming a connector does not admit its forks. Lineage carries blocks downward and nothing else. A fork has to be named on the allowlist itself before anyone can reach it.
The asymmetry follows from what each kind of rule is saying. A block names a capability somebody decided a role should not have, and a fork carries that capability forward by construction. An allow names a specific thing that was reviewed, and a fork is not that thing; its config can be edited the moment it exists.
The practical effect lands on allowlisted roles. Once a role carries any allow rule, everything none of its allow rules names is blocked for that role. That holds across the whole catalog, not only the connectors a rule mentions. So a fork of an allowed connector starts blocked for that role until an admin names it. For a block-only role, the same fork starts reachable unless the block on its ancestor catches it. That is exactly what the lineage walk is for.
How a rule matches an individual tool inside a connector is a separate mechanism, and the asymmetry there runs the same way. Blocks match a tool's name as well as its operation while allows match only the pinned operation.
What stops a forked tool from renaming its way out of a block?
Two further checks, both inside the declared fork chain.
First, Elaichi compares the HTTP method, path and host a called tool really sends with those of each blocked upstream tool in that chain. Renaming a tool does not escape the block. Neither does changing the resource and method keys inside the fork's config. The rule was written against an operation, and the operation is what gets compared.
Second, Elaichi runs the last check before a call leaves. It compares the fully resolved outbound URL, and every redirect hop, against tool-level block rules. Those rules are read from the called connector and from its declared ancestors. A match is refused.
Note what that final check does not do. It never refuses a request merely for reaching a host. The host appears only as one component of an operation a rule already named, inside a chain the fork itself declared. A block on a whole connector is enforced earlier, before the request is built at all, so a blocked connector never reaches the outbound stage.
Who can fork a connector, and what cannot be forked?
Forking a public catalog connector needs the connector:create permission, and the cases where forking is the right move are narrower than they look. Forking a connector the organization owns also needs at least view access to it. Without that, the answer is 404 rather than 403, so an invisible connector stays invisible.
Two things refuse to be forked. A remote MCP connector answers 409 connector_not_forkable, and so does a platform remote MCP connector, because the server belongs to the vendor rather than to the config. A connector that a restriction blocks for the caller, or a fork of one, answers 403. Restrictions are checked at the fork, not only at the call. That closes the obvious route of forking your way past a block you can see.
The audit log keeps the host information that identity deliberately ignores. Creating, forking or editing a custom connector records on the audit row the hosts its config calls. The row keeps up to 8 hosts plus the total count. An edit that changes them also records the previous hosts. Hosts are evidence for a reviewer. They are not an access control.
One timing note for anyone testing this. A restriction change takes effect within about two minutes, not on the client's next call. The same goes for a role or team-membership change. Write the rule, wait, then try the fork.
When connector lineage is not the control you need
For most organizations, lineage never comes up. Keep connector:create with Org Owner and Org Admin, and nobody else authors custom connectors. If every connection then runs on a catalog connector Elaichi authors, or on a vendor's own MCP server, no fork exists. A block has nothing to travel down. Writing rules against the catalog connectors people actually use is the whole job.
Lineage also does not solve the problem it is nearest to. It will not stop someone with connector:create from building a brand new connector against the same API as a blocked one. That connector declares no descent, and Elaichi does not guess at kinship. If that is the risk being reviewed, the control is the permission, plus the audit rows that record the hosts each new connector calls. A restriction cannot carry it.
And if the question is which role may reach which app at all, start with the rule layers rather than with forks. Restrictions target a role or one member; there is no organization-wide or team target. Within a layer, a block always beats an allow. How those layers decide a call is the wider picture. Choosing between a whole-app block and a single-tool block is the decision most teams face first. The connectors themselves, Elaichi's own and the vendors' native MCP servers, are listed in the connector catalog.
