AI agents in the software development lifecycle: where they help and where control is needed
Most engineering teams started with AI in one place: a coding assistant in the editor. That is changing. Assistants such as Claude Code or Cursor can now reach beyond the editor and act in the tools around the code, for example by creating Jira tickets, commenting on pull requests, updating Confluence pages or posting a summary in Slack. The technical enabler for this is the Model Context Protocol (MCP), an open standard that lets an AI client call tools in other systems.
This changes the question a team has to answer. It is no longer only "which assistant do we use?", but "what may this assistant do in each of our systems, and how do we know what it did?". This article walks through the stages of the software development lifecycle (SDLC), describes where agents are useful in each stage, and names the control that matters most there. Each stage links to a more detailed article in this series.
Why the lifecycle view matters
An agent that writes code in a local branch has a limited blast radius. An agent that can also close tickets, merge pull requests, edit documentation and send email has a much larger one. The risk does not come from a single tool; it comes from the sum of access across tools, usually granted through personal API tokens that carry the full rights of the person who created them.
In practice, this leads to two typical outcomes. Either the organisation blocks agents outside the editor, and the productivity gain is lost, or individual developers connect agents on their own, and nobody can say which agent can reach which system. Neither is a good baseline. A more useful approach is to decide per stage which operations an agent needs, grant exactly those, and record every call.
Planning: backlog, sprints and work items
Planning work is repetitive and text heavy, which makes it a good fit for agents. Typical tasks are drafting tickets from a meeting note, grooming the backlog, moving issues into the next sprint or summarising what changed during the last one. The relevant systems are Jira, Azure DevOps Boards and Trello.
The main control here is scope. An agent that plans sprints for one team should see that team's Jira project and nothing else, and it should be able to move issues between backlog and sprint without being able to delete projects. In Vordix, Jira access is scoped by project key, with finer allowlists for issue types, boards and sprints. Before every sprint or board operation, Vordix checks that the board or sprint really belongs to an approved project, and search accepts only structured filters instead of raw JQL, so an agent cannot widen its own query. The details are in letting an AI agent plan Jira sprints.
Documentation: Confluence and wikis
Documentation tends to fall behind the code. Agents can help by drafting release notes, updating a runbook after an incident or keeping an architecture page in line with the repository. The relevant systems are Confluence, the Azure DevOps wiki and, for some teams, Notion.
The control that matters is which spaces an agent may write to, and whether it can delete. Reading a whole Confluence instance is often acceptable; rewriting pages in the HR space is not. Vordix scopes Confluence by space and page, and the Azure DevOps wiki rejects an update that is based on an outdated page version, so an agent cannot silently overwrite a colleague's edit. See AI documentation in Confluence and the Azure DevOps wiki.
Code and review: GitHub and Azure DevOps Repos
This is where most teams already use AI, and where the stakes are highest. Reviewing a pull request needs read access to files and diffs and the right to comment. Merging, pushing to a protected branch or triggering a deployment workflow are different operations with a different risk profile.
The control here is least privilege per operation. In Vordix every operation is a separate permission: an agent can be allowed to read pull requests and post review comments, while merging stays switched off. Access is scoped per repository, with allowlists for branches. For operations that should only run with a human decision, an admin can attach an approval policy, for example to merging a pull request; the call is then held until a reviewer approves it. This is configured per operation and is not on by default. More in permissions for AI code review on GitHub and Azure DevOps.
Data: Databricks and the warehouse
Agents become more useful when they can answer questions with real numbers, for example the error rate of a service after a release. That requires access to the data platform, which often contains personal data.
The controls are table and column scope, and what happens to sensitive values in the result. The Databricks integration in Vordix is read only and accepts structured queries instead of raw SQL, with columns allowlisted per table. Data policies can mask, pseudonymise or remove values such as email addresses or IBANs before the result reaches the model. See giving AI agents access to Databricks.
Communication: Slack, Teams and email
The last step of many workflows is telling people about it: a release summary in a Slack channel, a status message in Microsoft Teams, an email to a customer. Communication tools are sensitive because a message leaves the team, and in the case of email, often the company.
The controls are channel scope for chat and recipient rules for mail. Vordix scopes Slack by channel and Teams by team and channel. For Gmail and Outlook, admins can restrict recipients to an allowlist or to internal domains, limit the number of recipients and disallow BCC. The same rules also filter what the agent can read, so mail outside the policy never reaches the model.
Across all stages: one audit trail
Each stage has its own risk, but one requirement is shared: when something goes wrong, the team has to reconstruct what happened. If every tool logs agent activity in its own way, or not at all, this becomes a manual search across systems.
A central gateway can record every call in one place, including the calls it denied and why. In Vordix the audit log is append only and hash chained, so later edits are detectable, and it can be exported or streamed to a SIEM (security information and event management) system. A log kept outside the AI vendor also has a different evidential weight than the vendor's own records. This is discussed in what an audit trail for AI agents should contain.
One control point instead of many
The stages above describe one pattern: agents need access to many systems, and each system needs a different kind of limit. Configuring these limits separately in every tool is possible, but the result is hard to review, because the answer to "what can this agent do?" is spread across a dozen admin consoles.
An MCP gateway puts one control point between the AI clients and the tools. The agent connects to the gateway instead of holding tokens for each system, and the gateway decides per call. How this works, and when a team actually needs one, is explained in what is an MCP gateway.
Trade-offs and limitations
A gateway is an additional component, and it has costs. It has to be operated, updated and monitored; in the case of Vordix it runs self hosted on the customer's infrastructure, which keeps data in house but means the team runs it. Permissions also need an owner: a gateway makes access reviewable, but it does not decide what the right access is. Finally, a gateway only covers the operations it supports. Coverage differs by tool; the Notion integration, for example, is limited to pages in databases today, so teams should check the operations they need against the documentation before a rollout.
Conclusion
AI agents are moving from the editor into planning, documentation, review, data and communication. The benefit is real, but so is the combined access. A useful way to adopt agents across the lifecycle is to decide per stage which operations are needed, grant only those, and keep one record of every call. The following articles in this series look at each stage in detail.
If you want to see how this looks for your own toolchain, you can request a demo or read the Vordix documentation.