Linear controls for AI agents

The control gap

Triage automation is useful, but status changes can alter delivery commitments and deletions can erase operating context.

Linear is frequently used as a high-velocity planning surface. The sensitive boundary may be changing a project milestone, moving committed work out of a cycle, modifying an initiative, or deleting the issue history that explains a product decision. Team and project identifiers should remain visible even when agents use natural-language issue references.

A practical policy can permit labels, summaries, and triage comments while requiring the relevant team lead for protected workflow states. Record the before-and-after state, cycle, project, issue identifier, and agent rationale so planning changes can be reviewed without replaying the agent conversation.

What good looks like

Routine Linear work continues automatically while sensitive actions are denied or held for a named reviewer.

• Classify read_issue and comment_issue separately from change_status and delete_issue.
• Scope policy to workspace, team, issue instead of granting one undifferentiated Linear capability.
• Require team-owner approval for deletions and changes to protected project states.
• Preserve the delegated user, agent, request payload hash, decision, reason, and policy version.

A production workflow

1. The agent asks Endram to evaluate a Linear action before execution.
2. Endram matches the agent, delegated user, action, and target workspace.
3. Low-risk requests proceed; sensitive requests create a time-bound approval.
4. The approved request executes once, and its outcome is attached to the original decision.

A policy you can test

Linear high-impact approval is a concrete starting point, not a claim that one generic rule fits every environment. Replace example identities and selectors, validate the request shape, and begin in shadow mode.

name: linear-high-impact
match:
  tool: linear
  action: ["change_status", "delete_issue"]
  environment: production
decision: require_approval
approval:
  expires_in: 15m
  reviewers: ["security-on-call"]

Endram keeps the policy version with every decision. A later change creates new evidence instead of rewriting why an earlier request was permitted.

Evidence to require

• A searchable record of attempted read_issue and delete_issue operations.
• The exact workspace and issue targeted by each request.
• Which policy version matched and why the request was allowed, denied, or escalated.
• Who approved the action, when approval expired, and whether execution succeeded.

Buyer checklist

• Which Linear actions must never run without a human?
• Can policy restrict individual workspace or team or issue?
• How are user delegation and service credentials represented?
• What evidence will incident response need after an unexpected action?