Introduction

AI coding agents give security teams a reason to be optimistic about vulnerability prevention. Before an agent writes a line of code for a new feature, it can be given a risk assessment of that feature: what the change touches, what could go wrong, and what a secure implementation has to account for. This creates an opportunity to address identified software change risks while the feature is still a plan.

That matters because agents change the pace of delivery. More changes reach review each week, and remediation has to keep up with every one of them. When a security risk turns up after the fact, a developer has to go back to work they finished days ago, after the context has faded and priorities have moved on. Repeat that across every change an agent writes and the rework becomes the bottleneck.

Reviewing risk at the ticket, before anyone starts building, can help teams remove some of that rework. It also gives security teams a direct way to put guidance into the build workflow while implementation decisions are still being made.

Give prevention a place in the build

Every vulnerability prevented is one nobody has to investigate, prioritise and fix later. The hard part is turning that aim into something a security team can do consistently.

Providing development teams with training can help, but it can’t deliver a lasting reduction on its own. A developer can understand access control and still miss how a new feature changes an existing permission rule. Applying general knowledge to a specific change takes context about the system and the feature being built.

AI agents also face that difficulty when writing code. They could misinterpret a requirement or overlook a security concern. But what their workflow adds is a repeatable point where the security review for a proposed change can be handed over as implementation begins. Cybersecurity teams can then check whether the guidance reached the agent and how it shaped the resulting code

That makes the handover from security review to implementation a practical place to step in. The team can specify what the agent should know before the build starts, then reviews whether it changed the result.

Explain the risk behind the requirement

A general instruction to ‘write secure code’ leaves the agent to work out which security concerns matter. A review of the specific software change can point to the business rules and permissions this piece of work has to respect.

Consider an illustrative ticket for a bulk-refund approval feature. The organisation requires that the person who requests a refund is never the person who approves it. That rule has to hold when staff approve several refunds in one action.

A pre-build review could flag the risk that the new bulk route bypasses independent approval. It could explain that each refund in the batch needs checking against the identity of its requester, even when the approver has the permission to use the bulk function.

Where the review identifies that concern, the agent has something specific to account for as it chooses an implementation. Checking only whether a user can access the bulk approval function would leave the real question unanswered: did this user request any of the refunds they’re approving? A flaw like that leaves the system looking healthy, which is what makes business logic vulnerabilities easy to miss.

The new code does not need to exist for that risk to be considered. The intended workflow and the business rule provide a basis for the risk assessment. Once the feature is built, the same concern gives the team a concrete test: does the bulk route stop someone approving their own refund?

Bring the review into the agent’s workflow

Cytix provides a skill that can be deployed to coding agents which we refer to as an agentic development guardrail. Before the agent starts building code for a ticket, the skill instructs it to find and retrieve the matching Cytix security review.

Two things need to be in place first. The ticket must be connected to Cytix, and its review must already have run in the platform. Where a matching review is available, the skill can bring it into the agent’s working context alongside the implementation requirements.

That gives the review a defined route into the build. It also makes the prerequisites easy to see: a connected ticket and a completed review are necessary for the agent to receive Cytix guidance through this workflow.

The review needs clearly specified tickets with relevant context. ‘Add bulk refunds’ leaves important questions unanswered. The intended behaviour, permissions and business constraints give the review something meaningful to assess. If the independent-approval requirement is missing from the refund ticket, clarifying that requirement before implementation helps both engineering and security.

For developers delegating implementation to an agent, writing that ticket is part of directing the work, along with describing the system, choosing the architecture, setting constraints and assessing the result. Security can contribute to those decisions before the agent starts building. Existing requirements and design work give that contribution a starting point, but gaps in the business rules still need a person to fill them.

Check what the agent built

Retrieving a review is a useful step, but it doesn’t show that the agent applied the guidance correctly. The review may miss risks, and the agent may misinterpret the guidance it receives. The implementation and its tests still need to be checked.

For the refund example, that means inspecting how the code enforces independent approval, then testing the change itself by trying to bypass it through the bulk route. Change-driven testing scopes that test to what the feature touched, rather than waiting for the next scheduled pentest.

Keep a record of the review, the implementation decisions and the test evidence in one record attached to the ticket. That helps the team see which identified concerns have been checked in the implementation and which still need follow-up. Human reviewers stay responsible for unresolved questions and for deciding whether the evidence is enough to release.

Start with one well-described change. Make its security review available before the agent builds it, then look at three things: what the agent received, how the implementation handled the identified risks, and what the tests show.

A reason for security teams to be optimistic

AI coding agents give security teams a point in the workflow where guidance can still influence the design. That is the practical case for optimism. Prevention gets a defined step in the build that security teams can evaluate and improve, one change at a time. Where that guidance helps prevent a vulnerability, there is one less issue to investigate, prioritise and fix later.

Frequently Asked Questions