Atlassian Streamlines Security Workflows Through Agentic Automation in Bitbucket Pipelines

The landscape of modern software engineering is frequently marred by the "interruption tax"—a steady stream of routine, high-consequence but repetitive tasks that fragment developer focus and stall the progress of planned feature work. Among the most persistent of these interruptions is the remediation of security vulnerabilities. While individual vulnerability fixes are rarely complex in isolation, the cumulative overhead of the manual workflow—identifying the ticket, tracing dependencies, updating images, regenerating files, running test suites, and managing the pull request lifecycle—creates a significant bottleneck. To address this, Atlassian has pioneered the use of agentic pipelines within Bitbucket, transforming the traditional ticket-heavy process into an automated, review-ready system designed to reduce the manual burden on engineering teams.

The core objective of this shift toward agentic automation is to move from a reactive model, where engineers begin their day by picking up a security ticket, to a proactive model, where they start by reviewing a tested and verified pull request. This transition is powered by a sophisticated workflow that integrates Jira Automation, custom dispatchers, Bitbucket Agentic Pipelines, Atlassian Rovo Dev, and Model Context Protocol (MCP) tools. By delegating the mechanical aspects of vulnerability patching to AI-driven agents, Atlassian has demonstrated a significant reduction in the time and cognitive load required to maintain a secure codebase.

The results of a three-month pilot program at Atlassian underscore the efficiency of this approach. During this period, a single engineering team reported more than 120 resolved vulnerabilities and the successful merging of over 55 agent-created pull requests. Remarkably, 95 percent of these automated pull requests were merged on the first run without requiring rework or failing initial tests. This high success rate highlights a critical shift in perspective: the primary value of the agent was not merely its ability to edit code, but its ability to provide a reviewable path and a clear stopping point, making the work significantly easier for human engineers to trust and finalize.

Routine vulnerability patching was selected as the ideal starting point for agentic automation because it meets four essential criteria: a clear entry condition, repeatable decisions, deterministic checks, and an obvious definition of "done." In this context, the entry condition is the creation of a vulnerability ticket by a scanner. The decisions—such as whether to bump a version or update a base image—follow established patterns. The checks, involving builds and test suites, provide binary pass/fail results. Finally, the definition of done is satisfied when the fix is deployed and the scanner no longer detects the vulnerability. Critically, the agent is not tasked with the final decision of whether a change should ship; instead, it prepares the change and assembles the necessary evidence for a human engineer to make an informed judgment.

The architecture of the agentic workflow is divided into three distinct components: a dispatcher, a coding agent, and a closer. This separation of concerns ensures that each job has a narrow purpose and specific permissions, maintaining the integrity and security of the development lifecycle. The process begins with Jira Automation, which triggers the workflow on a scheduled basis. The existing delivery system and human engineers remains responsible for the final governance, merge, and deployment phases.

The custom dispatcher, running as an Agentic Pipeline, serves as the initial filter. Scheduled to run before the start of the working day, it searches for vulnerability tickets within a configured patch window. The dispatcher makes four critical decisions for each ticket: determining if the vulnerability is eligible for automation based on known patterns, identifying the correct repository, grouping related vulnerabilities to minimize PR noise, and selecting the appropriate "skill" or instruction set for the agent. Every ticket processed by the dispatcher receives an explicit outcome, ensuring that no work disappears without a record.

Once eligible batches are identified, the dispatcher initiates the coding agent. This agent receives the context of the ticket, checks out the repository, and follows codebase-specific instructions stored directly within the repository. These instructions act as a digital "runbook," describing the decision tree an engineer would typically follow. For example, the agent may determine that a direct dependency requires a version bump, whereas a transitive dependency might necessitate an upgrade to its parent package. The agent applies the change, regenerates any necessary files, and executes the full build and test suite. If the checks pass, the agent creates a branch and opens a pull request. If the checks fail or the situation falls outside of its encoded logic, the agent stops and reports the failure, ensuring a safe handoff to a human developer.

The technical implementation of these agents is integrated into the repository’s own delivery system. Using a YAML configuration, the agent is defined as a provider (such as Rovo Dev) with a specific prompt located within the repository. This setup ensures that the agent operates within the same environment as the build tools, possessing only the Bitbucket permissions required for its specific task. This "versioning" of the agent’s prompts and skills alongside the code ensures that the automation evolves in lockstep with the software it maintains.

The final stage of the workflow is managed by the "closer." The remediation process is not considered complete simply because a pull request has been opened. The closer verifies that the fix is live by checking that the relevant pull request was merged and that the deployed build contains the expected commit. Only after this verification does the closer transition the Jira ticket for final scanner verification. This mechanism is designed to be idempotent, meaning it can run repeatedly without duplicating actions or prematurely closing tickets.

The adoption of agentic pipelines has fundamentally altered the developer loop. Engineers have moved from a labor-intensive process of scanning tickets, finding capacity, and manually tracking dependencies to a streamlined workflow where their primary role is one of oversight and approval. By handling the investigation, implementation, testing, and ticket updates, the agents allow engineers to focus their judgment on the most critical aspects of the code change.

Atlassian’s implementation offers several key learnings for organizations looking to apply similar patterns. First, instructions must be specific to the codebase. Generic instructions often result in generic, ineffective fixes; reliability stems from encoding specific dependency patterns, file locations, and known exceptions. Second, verification must remain deterministic and human-controlled. While an agent can prepare a change, the existing CI/CD infrastructure—including branch protections and required reviews—must serve as the final release gate. Third, the system must fail safely. When an agent encounters an unfamiliar pattern or a failing build, it must provide a clear handoff rather than attempting to force a solution. Finally, access must be kept narrow and attributable, with specific write scopes granted only where necessary to maintain an auditable trail of automated work.

While vulnerability patching has served as a successful proof of concept, the pattern is applicable to a wide range of repeatable engineering tasks. This includes dependency maintenance, the removal of stale feature flags, documentation updates, and the resolution of flaky tests.

Currently, Agentic Pipelines is in open beta for Bitbucket Cloud. Users can leverage Atlassian-managed providers like Rovo Dev or integrate third-party models such as Claude Code or Codex through their own provider accounts. Utilizing Rovo Dev requires a paid Bitbucket Cloud account with Pipelines enabled and a Rovo Dev Standard subscription. As organizations begin to experiment with these tools, the emphasis remains on starting with bounded, repeatable tasks that possess reliable checks and clear points for human review. By automating the "interruption tax," engineering teams can reclaim significant portions of their sprint capacity for higher-value innovation.