That means Linear access now works as code access. The text an agent reads in an issue is also an attack surface.
Summary
Factory now lets teams assign a Linear issue to Factory, or mention @Factory in an issue comment, to start a Droid session. The session reads the issue's title, description, labels and comments, runs on remote compute and posts its progress and results back in Linear. The run does not use the requester's personal connections. It uses a shared organization delegation configuration: a service-account identity with its own Git credentials, connectors, plugins and compute. Factory links the person who asked to their Factory account by matching work emails.
What happened
Factory's documentation describes two ways to delegate from Linear. You can assign the issue to Factory's agent entry, or you can mention @Factory in a comment. Either one starts Droid. The session receives the issue title, description, labels and comments, runs on remote compute and reports progress and results in Linear.
The key detail is whose identity the work runs under. The docs say execution uses the delegation configuration's service account, Git credentials, connectors, plugins and compute, not the requester's own connections. An org admin connects the app under Settings → Delegations using "Set Up for Org." Anyone who delegates must have a Factory account in the connected organization, and Factory asks people to use the same email in Factory and in the connected app so it can match the requester. According to the docs, changes to this shared configuration can affect other delegation apps. Factory's navigation lists Slack, Jira and Microsoft Teams next to Linear as delegation surfaces.
Factory says a good delegated issue should state the repository, the intended outcome, acceptance criteria and verification steps. It also says to review the changes and test results before merging. The source contains no adoption, reliability, completion or review-burden figures.
What the archive adds
The dossier explains why Linear is the obvious place to plug this in. According to Linear's changelog (d2), Linear launched its agent platform on May 20, 2025. That made agents assignable, mentionable and trackable as workspace participants, and came with a developer API and an integration directory. Linear's developer documentation (d3) says its agent APIs support issue delegation, agent sessions and agent activities. It also says workspace admins install and manage agent apps and can revoke or change a team's access. The same docs label these APIs a Developer Preview. An archived item (d1) shows that other vendors are also adding Linear triggers that start an agent automatically when an issue is assigned, so assignment-as-trigger is becoming standard. Factory's own Delegations page adds the identity rules that matter for this analysis: delegation is configured once for the organization, and requesters are matched to Factory accounts by email.
Trend signal
Coding agents are moving out of their own chat windows and into the queues where work already lives. Linear's platform work (d2, d3) is the reason this has become cheap. Linear supplies the assignee slot, the mention handling, the session and activity surface where progress shows up, and the admin install-and-revoke flow. A vendor no longer has to build a handoff UI, a progress feed or a permissions screen. It implements a session handler against Linear's API. Once every agent can be triggered the same way, the trigger no longer sets vendors apart. The difference shifts to what happens after the trigger fires: which identity the run uses, which credentials and connectors it has, and which environment it executes in. Factory's documentation spends most of its words on exactly that layer. Our read is that Factory sees the shared org runtime, not the Linear button, as its product.
Why now
1) Linear's platform cut integration costs. Since May 2025, agents have been assignable and mentionable workspace participants with a developer API (d2). The session, activity and admin-install APIs (d3) mean a vendor gets the trigger, the progress surface and the permission flow without building them. Factory only needs to connect its existing runtime. 2) Because the platform makes the trigger the same for everyone, differentiation moves down to identity, credentials and environment. Factory's docs focus on that layer: one org configuration with a service account, Git credentials, connectors and compute, reused across Linear, Slack, Jira and Teams. 3) There is parity pressure. Archived coverage (d1) shows other vendors shipping Linear assignment triggers, so a coding-agent vendor without a Linear entry point would leave a gap where teams already queue work.
Connections to other events
Follow the shared identity one step further and it changes who can reach what.
1) Linear access now acts as code access. If a person has a Linear workspace seat and a Factory account with a matching email, they can start work that runs with the service account's Git credentials and connectors. Their own repository permissions never come into it. A teammate with no write access to a repo can still get Droid to push a branch or open a PR there. Merge review remains the gate, but the access boundary for starting code changes is now the overlap of Linear membership and Factory membership, not your Git ACLs.
2) Email matching tells you who asked, not whether they were allowed to. The docs use the shared email to link the Linear user to a Factory account. Our inference is that this records who triggered a run. It does not check whether that person should be able to touch that repository or connector. Commits are made by the service account, so the human audit trail sits in Linear's activity log and Factory's match record, not in Git history.
3) Issue text becomes an instruction channel that carries org-level privileges. The session reads the description, labels and every comment. Anyone who can write into an issue, including people outside the delegating team, influences an agent that holds the organization's credentials. This suggests prompt injection through tickets is no longer a theoretical risk for teams that turn this on.
4) Configuration changes reach more than one tool. The docs say changes to the shared delegation configuration can affect other delegation apps. Widening a connector to fix one Linear workflow can therefore also widen what Slack- or Jira-triggered runs can reach.
There is a platform-risk angle too, but treat it as a hypothesis. The only evidence for it is that Linear calls its agent APIs a Developer Preview and that Linear admins can revoke agent access (d3). If that is the risk, Factory's org-level runtime is the part that would survive a change of trigger.
Why it matters
For security teams: treat the delegation service account as a production identity that a population of users can trigger. Give it least privilege. Scope its Git credentials to the repositories delegated work actually needs. Put changes to the Delegations settings through change control, because those changes can spill into other apps. For Linear admins: review who has workspace seats, guests included, and who can comment on issues in teams where Factory is installed. Those people now shape agent work. For engineering leads: Factory's checklist (repo, outcome, acceptance criteria, verification) works as an execution contract, so enforce it with an issue template. Keep human review before merge, as Factory itself advises. For buyers comparing agents: judge the identity and environment model, not the trigger, because the trigger is now standard through Linear's platform.
What happens next
- By 2027-04-21, Factory's documentation will describe scoping delegation credentials per app or per team, for example a separate service account or connector set for Linear than for Slack. (6 months, 35%). Watch for: The Factory Delegations docs or changelog mention per-app or per-team service accounts, credential scopes or connector allowlists. Rationale: the docs currently state that the configuration is shared and that changes can affect other apps, which enterprise least-privilege reviews will push against. We have no roadmap evidence, so the probability stays below even.
- By 2027-01-21, Factory will publish quantitative completion, merge or failure rates specifically for Linear-delegated issues. (3 months, 15%). Watch for: A Factory blog post, docs page or changelog entry with a percentage for delegated Linear issues. Rationale: the current docs contain no outcome metrics, and agent vendors rarely release per-integration success data within a quarter of launch.
- By 2027-10-21, Linear's developer documentation will no longer label its agent APIs a Developer Preview. (12 months, 45%). Watch for: The 'Developer Preview' label disappears from linear.app/developers/agents, or a GA or versioned-stability announcement appears in Linear's changelog. Rationale: the platform has been live since May 2025 (d2) with several integrators, which pushes toward stabilization. Preview labels often stay well beyond a year, though.
Limits and uncertainty
This take uses only Factory's public docs and three dossier findings. It does not cover whether Factory offers finer controls the excerpts omit, such as per-team or per-repo scoping of delegation, or approval steps before execution. If those exist, the access-widening argument gets weaker. We have not seen how email matching handles guests, aliases or accounts with mismatched domains. The prompt-injection risk is inferred from the fact that comments are passed in. There is no documented incident behind it. We have no outcome data on completion, merge rate or review burden for Factory or any other Linear-delegated agent. The platform-risk point rests only on the Developer Preview label and admin revocation (d3). Linear may keep its API contract stable.
Skill to build now
Practice threat-modeling an agent identity that many people can trigger. First exercise: pick one Linear team where you would enable Factory. List who can comment there, guests included. List what the delegation service account's Git token and connectors can reach. Then write one adversarial issue comment, for example one asking the agent to read a secret or edit a CI file, and check whether your merge review and branch protections would catch the resulting PR.
Reader takeaway
Before you enable Factory's Linear delegation, write out the effective access list: every person who can assign or comment on issues in the enabled Linear teams and also has a Factory account with a matching email, plus every repository, secret and connector the delegation service account can reach. If that list shows someone without repo write access can start work that pushes to that repo, narrow the service account's scope or limit which Linear teams have the app installed before rollout.
Open question
Should the agent's permissions match those of the person who triggered it, with each run limited to what that requester's own Git access allows, or is an org-level service account plus mandatory merge review a sufficient control once anyone with a tracker seat can start a run?