Should organisations use agentic AI in CI/CD before strengthening governance?

Why Governance Should Come Before Agentic CI/CD

agentic ai can accelerate build, test, and release workflows, but CI/CD is a high-consequence environment where small mistakes propagate quickly. If an autonomous system can approve changes, trigger deployments, or interact with tooling before the organisation defines boundaries, accountability, and review points, it creates speed without reliable control. OWASP’s OWASP Top 10 for Agentic Applications 2026 is useful here because it focuses attention on the access, orchestration, and failure modes that matter when software can act, not just predict.

The core issue is not whether agentic AI is useful. It is whether the organisation can explain who authorised the action, what the agent was allowed to touch, and how errors will be detected before production is affected. In release pipelines, weak governance often looks benign at first because the agent appears to be “helping”, but the actual risk is that authority becomes implicit, not explicit. In practice, many teams discover that they treated an agent like a support tool until it was already influencing deploy decisions, secrets access, or rollback behaviour.

What Changes Once an AI Agent Can Act in the Pipeline

Traditional automation follows predefined rules. An agentic system adds interpretation, planning, and tool use, which means its effect depends not just on code but on the permissions and objectives it is given. That changes the control problem. Teams need to understand which actions are read-only, which are suggestive, and which are executable. Without that distinction, the release process can become harder to audit even when it becomes faster to operate.

Good governance in this context usually means three things. First, the agent’s permissions are narrower than the human operators it assists. Second, every material action is logged in a way that supports review after the fact. Third, a named owner is responsible for the outcome, including cases where the agent made a technically plausible but operationally wrong decision. This is where the NIST AI Risk Management Framework helps, because it frames AI use as a governance and accountability problem, not only a model-quality problem. The same logic also aligns with NIST AI Risk Management Framework guidance on mapping, measuring, and managing AI risk.

• Agents should be constrained to the smallest practical action set for the pipeline stage they support.
• Human review should remain mandatory for release promotion, secrets exposure, and rollback exceptions.
• Logs should show both the agent’s suggestion and the effective action taken.
• Ownership should be explicit enough that failure cannot be described as “the agent did it”.

Where this guidance breaks down is when the organisation cannot distinguish advisory automation from autonomous execution, because then the control boundary is already too vague to govern reliably.

Where the Trade-Off Becomes Acceptable and Where It Does Not

Tighter control often slows deployment decisions and adds process overhead, so organisations have to balance delivery speed against accountability. That trade-off can be acceptable when the agent is limited to low-risk tasks such as triage, summarisation, or draft recommendations, but it becomes much harder to justify once the system can approve changes, modify pipeline state, or influence privileged actions.

There is no serious consensus that governance can be added later without cost. Once an agent has been allowed to operate in a production-adjacent pipeline, teams often inherit messy telemetry, unclear responsibility, and exceptions that are difficult to unwind. The safer pattern is to treat governance as a prerequisite for autonomy, not a retroactive cleanup task. That is especially true when the agent can interact with other systems through API keys, tokens, or service accounts, because the blast radius expands from the model to the connected environment. The OWASP agentic guidance and the MITRE ATLAS adversarial AI threat matrix both reinforce that tool access and chained actions are where agentic risk becomes operational, not theoretical.

For teams that want a practical decision rule: if you cannot explain, test, and audit the agent’s authority on paper, you should not allow it to make release-impacting decisions in practice. Security teams usually learn that lesson only after an apparently helpful automation path starts making changes nobody can confidently attribute or reverse.

Risk and Threat Considerations

Agentic AI in CI/CD introduces governance risk, privilege exposure, and attack-path risk at the point where software can alter delivery outcomes. The main concern is not merely misconfiguration. It is that an agent with tool access can amplify weak boundaries into release-impacting failures, especially where secrets, deployment controls, or approval workflows are exposed through automation.

Failure mechanism: The risk materialises when the agent is granted broader permissions than its task requires, or when its actions are trusted as if they were human-reviewed. That creates a path for accidental misdeployment, hidden policy bypass, or malicious prompt and tool abuse to trigger downstream changes in build, test, or release systems. The same mechanism can also obscure accountability because logs may record what happened without clearly showing why the action was allowed.

Impact: Organisations can lose release integrity, accelerate the spread of bad builds, expose credentials, or make rollback and incident investigation harder. In the worst case, the pipeline stops being a controlled delivery system and becomes a high-speed privilege conduit.

Practitioner Guidance

What to prioritise: Define the agent’s authority before expanding its scope. The first control question is not whether the agent is accurate enough, but whether every action it can take is intentionally permitted, observable, and reversible.

What to verify: Confirm that pipeline owners can distinguish recommendation from execution, and that failure ownership is assigned to a human role with operational authority. If no one can explain who approves exceptions, the governance model is still incomplete.

Common mistake: Treating a release assistant as harmless because it starts in a narrow use case. In CI/CD, narrow use cases often expand through convenience until the agent is adjacent to privilege, which is when the control gap becomes expensive to fix.

Practitioner takeaway: Agentic AI belongs in CI/CD only when governance is strong enough to contain its authority, not when the team hopes governance will catch up after deployment.

Related resources from NHI Mgmt Group

• Should organisations prioritise identity governance before expanding agentic AI?
• Should organisations prioritize securing machine identities before expanding agentic AI use?
• Should organisations use AI for identity governance before they clean up data and policies?
• Should organisations buy AI governance tooling before scaling agentic workflows?