Jira controls for AI agents

The control gap

An operations agent can silently change workflow state or remove the incident history teams rely on.

Jira workflows often encode operational authority in status transitions. Moving an incident to resolved, closing a security finding, changing an assignee, or editing a severity can affect response obligations even when no record is deleted. Normalize transition identifiers and project classification so policy does not depend on a mutable button label.

For incident projects, include current and requested status, severity, service owner, linked change, and whether the request would stop an SLA clock. Keep comments and evidence attachment automatic where appropriate, but route resolution and destructive operations to the incident commander or project owner.

What good looks like

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

• Classify read_issue and comment_issue separately from transition_issue and delete_issue.
• Scope policy to site, project, issue instead of granting one undifferentiated Jira capability.
• Require project-owner approval for destructive changes and production incident transitions.
• Preserve the delegated user, agent, request payload hash, decision, reason, and policy version.

A production workflow

1. The agent asks Endram to evaluate a Jira action before execution.
2. Endram matches the agent, delegated user, action, and target site.
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

Jira 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: jira-high-impact
match:
  tool: jira
  action: ["transition_issue", "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 site 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 Jira actions must never run without a human?
• Can policy restrict individual site or project or issue?
• How are user delegation and service credentials represented?
• What evidence will incident response need after an unexpected action?