TL;DR: The Linear MCP server has no CVE, authenticates properly through OAuth, and inherits your existing Linear permissions. That last part is the problem. It returns everything your account can see, and issue and comment text is written by other people. Scope the token to
readat authorization time and gate write actions, because those are controls the software will not apply for you.
Nothing is broken, which is the point#
There is no advisory to link here. Linear's MCP server does what it says: OAuth authentication, permissions inherited from your account, no known implementation flaw.
Reviewing it is still worth seven minutes, because the interesting security properties of an MCP server are usually not bugs. They are defaults. And the default here is that an agent connected to your Linear workspace can see everything you can see.
For an individual contributor on one team, that is a bounded set. For a staff engineer, an engineering manager, or anyone who has accumulated visibility across a few years and several reorgs, it is close to the whole company's product history, including the tickets nobody thought of as sensitive when they were filed.
Issue trackers are full of things you did not classify#
Ask what a Linear workspace actually holds and the honest answer is: whatever was convenient to paste.
Incident tickets contain infrastructure detail, log excerpts, and occasionally credentials that were rotated afterwards but never scrubbed from the description. Customer support escalations contain names, email addresses, account identifiers, and account balances. Security tickets contain unpatched vulnerabilities and their exploitation paths. Hiring and performance discussions leak into private team issues.
None of it is labelled. Nothing in the data model distinguishes a routine bug report from an incident postmortem containing a customer's personal data. When an agent asks for issues and the server returns everything the account can see, that distinction does not exist to be respected.
This is why the practical enterprise advice is to add redaction at the MCP layer rather than relying on the source system's permissions. Linear's permissions were designed for humans who read one ticket at a time, not for an agent that can pull five hundred and summarise them into a context window that then travels wherever the session goes.
The gap between the two bars is the exposure, and nothing surfaces it after authorization because everything works.
The text in the tickets is written by other people#
The second property matters more, and it is the same one that makes the GitHub MCP server interesting.
Issue descriptions and comments are attacker-writable. Inside a workspace, any member can write them. In workspaces that accept customer requests, run public intake forms, or sync from support tools, people outside the company can write them too. An agent asked to "triage the open bugs" reads that text and, if it acts on what it reads, is taking direction from whoever filed the ticket.
That is textbook prompt injection, and OAuth does not touch it. OAuth establishes identity and permission. It has nothing to say about whether the instruction driving an authorized call came from the user or from a comment the agent read thirty seconds earlier. Every resulting action is legitimately authorized, which is exactly why the audit log looks unremarkable afterwards.
Our error hypnosis research showed the sharper version of this: an agent can be steered through a multi-turn sequence in which no single step looks wrong. A ticket tracker is a comfortable place to stage that, because reading tickets in sequence is the normal behaviour.
Scoping, concretely#
Request only the read scope. If the agent's job is triage, summarisation, or search, it does not need write access. A token that cannot reach write APIs is a real boundary, unlike an instruction telling the agent not to write. Be aware of one operational wrinkle: Linear permits multiple active tokens only while they share a scope set, so requesting a different set revokes the application's existing app-actor tokens. Decide the scope before you roll it out broadly.
Or pass a restricted read-only API key. Against the standard MCP endpoint, a read-only key in the Bearer header achieves the same containment without going through the OAuth flow.
Do not authorize from an over-permissioned account. The server inherits the authorizing user's visibility. Connecting it as the person with the broadest workspace access is the most common and most consequential mistake, and it is invisible afterwards because everything works.
Gate the write verbs. Issue creation, comment creation, and status transitions are the actions with outward or destructive effect. If you only require confirmation on one class of action, require it on these.
Add redaction above the server. For regulated data, filter at the MCP layer rather than trusting that nobody pasted anything sensitive into a ticket in the last three years. They did.
What to ask before connecting any of these#
The Linear server is a good template for the general question, because it is well-built and still requires decisions. Three things determine your exposure, and none of them appear in a CVE feed.
Can people outside your trust boundary write content this server reads? Does the credential inherit more visibility than this task needs? Can the agent take actions with effects outside the system? Linear answers yes, usually, and yes. That is not a criticism of Linear; it is what an issue tracker is. It just means the controls have to sit above it. We cover that assessment in more depth in our MCP security guide.
FAQ#
Is the Linear MCP server safe?#
It has no published CVE, and it authenticates through OAuth while respecting the permissions your Linear account already holds. The risk is not a flaw in the server but the breadth of what that inherited permission covers: the server returns everything your account can see, which in most workspaces is every issue, comment, and attachment across every team. Safety here is a scoping decision you make at authorization time, not a property of the software.
What is the main security risk with the Linear MCP server?#
Issue descriptions and comments are attacker-writable text that an agent reads and may act on. Any workspace member can write them, and in workspaces that accept customer requests, support integrations, or public intake forms, people outside the company can write them too. An agent that reads a ticket and then takes actions based on its contents is following instructions from whoever wrote that ticket.
How do I give the Linear MCP server read-only access?#
Request only the read OAuth scope when authorizing, or pass a restricted read-only API key in the Bearer header against the standard MCP endpoint. Clients granted read cannot reach write APIs at the token level, which is a stronger guarantee than asking the agent not to write. Note that Linear ties active tokens to a scope set, so requesting a different set revokes the application's existing app-actor tokens.
Does OAuth make the Linear MCP server secure by itself?#
No. OAuth establishes who is calling and what they are permitted to do. It says nothing about whether the instructions driving those calls came from the user or from text the agent read a moment earlier. Every action in an injected sequence is fully authorized, which is precisely why authorization logs look clean afterwards.
What should an enterprise add on top of the Linear MCP server?#
Redaction at the MCP layer for regulated data, because the server returns whatever the account can see and issue trackers accumulate credentials, customer records, and incident detail nobody classified. Confirmation gates on high-risk write actions. And least-privilege tokens scoped per workspace or team rather than one token inheriting a senior employee's full visibility.
See what the token actually reaches#
An OAuth consent screen does not tell you that a token just inherited six years of workspace visibility, and nothing surfaces it afterwards because everything keeps working. Workstation Lens catches the MCP servers and skills reading credentials they never declared, across every Claude, Cursor and Copilot agent your developers run.
