Lanes Link vs Claude Tag

These are not the same kind of thing, and this page is not an argument that one replaces the other.

Claude Tag is an agent with a Slack surface. You tag it in a channel, it works for hours in a thread, and around that sit an org admin console, GitHub App repository grants, plugin distribution and spend limits.

Lanes Link is an endpoint that holds accounts behind a policy and an audit log. It has no Slack surface, no console, and nothing to say about long-running jobs.

They meet at exactly one point, and it is the interesting one: what the agent is allowed to reach. Claude Tag calls that unit an access bundle. Lanes Link calls it a profile.

So the honest comparison is a profile against a bundle's credential list. The two are close enough that most of this page is about where they agree.

At a glance

Dimension	Lanes Link profile	Claude Tag access bundle
Unit of access	A profile: connections, per-row rules, members	A bundle: credentials, repository grants, domains, plugins, instructions
Bound to	Any MCP client, by token	A Slack scope: organization, workspace, or channel
Scope inside a tool	Per connection, per capability, glob `allow` and `deny`	Not settable. Narrow the connected account instead
Narrowing one connector	One policy line	A new service account in the vendor, a new credential, its own bundle
A connection you left ungranted	Absent from the tool list, not merely denied	Not expressible. Every credential in an attached bundle is reachable there
Adding an account	`lanes link connect`, no console change	Another credential row in every bundle that needs it
Where credentials sit	Your machine, or your own GCP project	Anthropic's Agent Proxy, injected at the network boundary
Audit	One hash-chained log across every provider, refusals included	Each vendor's own log, attributed to the service account, plus the thread itself
Who may use it	`members:`, a Lanes identity per profile. Empty is nobody	Anyone in a channel the bundle covers
Reach beyond Slack	Every registered client shares the profile	Slack only. Personal claude.ai connectors apply in DMs only

Where they agree, which is most of it

It is worth being clear how much of Claude Tag's access model is the same model, because the differences only matter once you accept the design.

Both are a service identity, not per-user OAuth. Nobody brings their own privileges into a session. Anthropic's docs put it plainly: "The credential you connect is Claude's account in that tool, not yours."
Both are configured by an owner, not by whoever is typing. Editing what the agent may reach is deliberately not something the agent can do.
Both keep the key away from the model. Agent Proxy injects credentials at the network boundary, so the sandbox never holds them. Lanes Link's config holds only _ref pointers into a credential store, and its loader rejects a literal secret outright, naming the exact key.
Both compose access from named units. Several bundles or several profiles, picked per context, each credential defined once so a rotation touches one place.
Both restrict which hosts a credential may be sent to, and neither lets a bare wildcard carry one.
Both treat unlisted access as unreachable. Deny by default is the starting point in each.

That overlap is real and it is the right architecture. If you have set up Claude Tag thoughtfully, you have already done the hard conceptual part.

Where they diverge: how far a credential reaches

One line in Anthropic's documentation is the whole difference: "A connection has no setting for which pages, folders, or projects Claude can reach inside a tool. The connection's reach is whatever the connected account can access in that tool. To narrow Claude to a subset, narrow the account."

Scope, in other words, is not a property of the bundle. It is a property of the account you connected.

Expressing it means going into the vendor and creating a narrower service account, then a second credential for it, then a separate bundle so the narrow one does not leak into channels that should keep the broad one.

The host, path and method restrictions a bundle does offer control which endpoints Claude may call, not which records those endpoints return.

A profile puts that in the policy layer instead. grants: is one row per connection, each with its own allow and deny globs, so two accounts of the same provider can have different reach on the same profile: read one mailbox, write the other, edit the calendar.

lanes link policy deny gmail.send is the entire operation. It applies in about a second, and a deny beats an allow regardless of order.

A connection with no row is not denied so much as invisible, and a rule can carry expires_at when the access is meant to end.

The second-order effect is the one people feel. Because per-channel scope in a bundle costs a new identity, the path of least resistance is one broad account shared across channels, and that is over-provisioning arrived at by friction rather than by decision.

Where Claude Tag is the better answer

Reach is uniform. If every channel should see the same Notion and the same Datadog, a bundle is simpler and Lanes Link adds a hop for nothing.
The tool is a preset. Roughly 46 services have a Connect button, with the credential fields and allowed hosts already filled in. That is real time saved.
GitHub. The Claude GitHub App gives repository allowlists, branches, pull requests, review, and CI follow-up natively. Do not route GitHub through a generic connection to prove a point.
You want plugins and skills distributed by an admin. Bundles carry plugins, instructions, and an environment, and channel members install nothing.
The Slack surface itself. Long-running work you watch unfold in a thread is the product, and it is not something a self-hosted endpoint attempts.

Where Lanes Link fits

Inside the bundle, as one connection. That framing matters: this is not a replacement for Claude Tag, it is a different shape of credential to put in it.

Deploy a profile, add a plugin declaring the MCP server, add one Bearer credential for its host, and the channel gets whatever that profile grants and nothing else.

What you buy is that scope becomes editable. Channels that need different reach into the same tool become different profiles rather than different service accounts, and the bundle stops growing a row per tool per channel.

The boundary is yours, too. The tokens sit on your machine or in your own GCP project, the audit log is a set of objects you own, and the same profile serves Claude Code, Codex, a phone and the Slack channel from one set of rules.

Choose a Lanes Link endpoint inside your bundle if

Different channels need different reach into the same tool.
You would otherwise be minting service accounts purely to express scope.
You want the OAuth tokens on infrastructure you control.
You want one tamper-evident audit trail across every provider, refusals included.
You want the same grants to serve your terminal and your phone, not just Slack.

Stay with bundle credentials alone if

Every channel needs the same reach, so there is nothing to narrow.
The services you need are presets, and the presets fit.
GitHub is the main integration. Use the GitHub App.
You would rather not run and deploy an endpoint of your own.

Claude Tag is in public beta, so the behavior described here may change. Check it against the current docs before you build on it.