Agentic DevSecOps: When AI Agents Can Write, Test and Deploy Code

Over 2025, coding agents moved from developers' laptops into the delivery pipeline. Today, in many engineering organisations, agents write a share of feature code, respond to failing builds, open pull requests for dependency upgrades, fix scanner findings and draft release notes. A few organisations let agents trigger deployments to lower environments.

For DevSecOps, this creates two questions at once:

1. How do we secure a delivery pipeline in which agents are active participants?
2. How do we use agents to make the delivery pipeline more secure?

#Half 1: securing a pipeline full of agents

#Principle: agents propose, gates decide

The central rule is simple. Agents may propose any change: code, configuration, dependencies, even pipeline definitions. What reaches production is decided by deterministic gates and human approvals that agents cannot bypass.

flowchart LR
  A[Agents propose changes] --> PR[Pull requests]
  H[Humans propose changes] --> PR
  PR --> G[Deterministic gates<br/>tests, SAST, SCA, IaC,<br/>policy, provenance]
  G --> R{Risk-based<br/>human approval}
  R --> D[Deployment pipeline<br/>not an agent]
  D --> P[Production]

#Controls

• Identity per agent. Every agent integration has its own identity, so its actions are attributable and its permissions reviewable.
• Least privilege. Agents can open pull requests and push to their own branches. They cannot merge, approve, edit protected workflow files or reach deployment credentials.
• Sandboxed execution. Agent jobs run on isolated, ephemeral runners with restricted egress and no production secrets.
• Untrusted input awareness. Issues, PR descriptions, code comments and dependency code can carry instructions aimed at agents. Agent-triggered workflows should only run for trusted actors, and never with elevated tokens on untrusted content.
• Change control for agent configuration. Prompts, instruction files, tool permissions and model versions are reviewed and versioned like code.
• Provenance. Agent-authored commits are marked and, where possible, signed, so reviewers and auditors know what they are looking at.

#Half 2: agents doing security work

Security teams have always had more findings than capacity. Agents can change the economics, if their output is verified.

Finding triage. Agents examine scanner findings in context: whether input is attacker-controlled, whether code is reachable, whether a mitigating control exists. They propose a verdict with reasoning. Humans confirm suppressions.

Automated fixes. For well-understood issues (vulnerable dependency versions, injection sinks, missing security headers, IaC misconfigurations) agents open fix pull requests that are verified by tests and re-scans.

Security test generation. Agents write authorisation and input-validation tests from requirements, turning one-off pentest findings into permanent regression tests.

Pipeline hygiene. Agents can propose pinning unpinned actions, tightening token permissions and removing unused secrets across hundreds of repositories: tedious work that rarely gets done by hand.

Incident support. During security incidents, agents with read-only access can summarise logs, map affected services and draft timelines.

#Verification is non-negotiable

A security fix that is wrong is worse than no fix, because it creates false confidence. Every agent-produced security change should:

1. re-run the scanner that found the issue and confirm it is resolved,
2. pass the full test suite,
3. include or update a test that would fail if the vulnerability returned, and
4. be reviewed by someone who understands the vulnerability class.

# Illustrative "security fix" pipeline for agent-authored PRs labelled security-fix
security-fix-verification:
  rules:
    - if: '$CI_MERGE_REQUEST_LABELS =~ /security-fix/'
  script:
    - make test
    - semgrep ci --config p/default            # original finding must be gone
    - ./scripts/check-regression-test.sh        # PR must add or update a test for the CWE
  allow_failure: false

#Operating model

• Security owns the guardrails: gates, policies, agent permissions and verification pipelines.
• Platform owns the paved road: shared CI templates, sandboxed runners and agent integrations.
• Development teams own their code, including agent-authored changes they merge.
• Everyone owns metrics: time to remediate, percentage of findings auto-fixed and verified, change failure rate for agent-authored changes, and escaped vulnerabilities.

#The bottom line

Agentic DevSecOps is not a new discipline so much as DevSecOps with a new kind of participant. Secure the pipeline so that agents can propose anything but ship nothing without passing the same gates as everyone else, and use agents where they help most: triage, verified fixes, tests and hygiene at a scale humans never had time for.

Our application security testing and DevSecOps teams design agent-aware DevSecOps pipelines, from sandboxed runners to verified auto-fix workflows.