Atlassian automates vulnerability fixes with AI coding agents
The company's engineering team deployed agentic pipelines that autonomously patch security issues, open pull requests, and close tickets—merging 55+ PRs with a 95% first-run success rate.
Atlassian automates vulnerability fixes with AI coding agents
Atlassian has deployed an AI-powered system that autonomously handles security vulnerability remediation—work that previously required engineers to context-switch, carve out sprint time, and manually close tickets. Between May and July 2026, the system resolved more than 120 security vulnerabilities and merged over 55 automated pull requests with a 95% first-run merge rate, according to details first reported by Atlassian.
The implementation uses three components built on Atlassian's own platform: a dispatcher agent that identifies and classifies eligible work, a coding agent that applies fixes and opens pull requests, and a closer agent that verifies deployment and transitions tickets to completion.
How the system works
The architecture relies on Bitbucket Agentic Pipelines, which define AI agents as versioned pipeline steps triggered by schedule or event. Each agent runs on Rovo Dev, Atlassian's AI coding runtime, and accesses Jira, Bitbucket, and Confluence through scoped MCP (Model Context Protocol) tools.
All agent logic lives in the repository alongside application code. The .rovodev directory contains prompt files that define each agent's instructions, a pipeline-config.yml that specifies model selection and tool permissions, and reusable skills that encode codebase-specific knowledge. This approach makes the entire system reviewable and versionable like code.
The dispatcher runs daily before working hours. It fetches eligible vulnerability tickets, classifies which can be automated versus which need human judgment, deduplicates items sharing the same underlying fix, and dispatches coding-agent runs with relevant context. The coding agent then applies the fix by invoking a fix-vulnerability skill—a structured decision tree that captures institutional knowledge about dependency patterns, platform constraints, and verification steps specific to Atlassian's codebase.
After deployment, the closer agent verifies the fix is live by confirming the corresponding change was merged and included in the deployed build. If it cannot establish that evidence, it leaves the ticket open rather than claiming false success.
Why it matters
This system demonstrates a practical application of agentic automation beyond chatbots or code completion. By targeting repetitive, well-defined engineering work—security patches that follow predictable patterns—Atlassian has shifted engineers from being the execution layer to the decision layer. Engineers now review pull requests rather than performing the mechanical work of finding vulnerabilities, making changes, running tests, and closing tickets.
The 95% first-run merge rate indicates the system produces production-ready code without rework. The agent runs full build and test suites before opening any PR, ensuring only verified changes reach human review. This level of reliability comes from encoding domain-specific knowledge in skills rather than relying on generic prompts, and from iterating on real failure logs to tighten the system continuously.
Implementation details
The fix-vulnerability skill contains a decision tree that mirrors how an engineer would approach the problem: identifying whether the vulnerability lives in a direct dependency, transitive dependency, base container image, or sidecar container, then applying the appropriate fix strategy for each case. The skill also specifies verification steps—confirming the patched version resolves correctly and that the build passes before opening a PR.
Atlassian emphasized several design principles: prompts are the system and should be invested in first; specialize for your specific frameworks and conventions rather than using generic instructions; iterate on real runs to improve reliability; verify before shipping by requiring passing tests; design for idempotent re-runs using existing system state as the source of truth; and use a dedicated service account so automated PRs are clearly attributed to a bot.
The company positions this as one instance of a broader pattern: any work done repeatedly on a schedule, following the same steps with a clear definition of done, is a candidate for this kind of automation. Details were published by Atlassian on their engineering blog.
This is an original analysis by the Omega editorial team. Source reporting: Automation Watch.
Want systems like this working for your business?
Book a Call