Teams often assume an agent is just another automation step, when in practice it can interpret untrusted text and take actions with real permissions. That means prompt injection, workflow poisoning, and tool misuse become identity and authorisation problems. The control point is not only model safety, but what the agent is allowed to do once it has context.
Why This Matters for Security Teams
AI agents in CI/CD pipelines are not just faster scripts. They can read issue text, pull request comments, build logs, and repository content, then decide which tools to call and which actions to request. That creates a new control problem: untrusted text can become operational input, and operational input can become code change, deployment, or secret exposure. Guidance from the NIST AI Risk Management Framework is useful here because it pushes teams to manage model behaviour, data integrity, and downstream harm together rather than as separate concerns.
What teams often miss is that the agent inherits the trust boundaries of the pipeline it sits in. If the agent can approve a merge, trigger a deployment, or retrieve secrets, then prompt injection becomes an authorisation issue and workflow poisoning becomes a supply chain issue. Security review must therefore cover the agent’s context sources, tool permissions, and approval path, not only the model provider or the prompt template. In practice, many security teams encounter agent abuse only after an unexpected deployment, secret access, or poisoned build artifact has already occurred, rather than through intentional testing.
How It Works in Practice
A secure CI/CD design treats the agent as a privileged workflow participant with tightly bounded authority. The pipeline should define which inputs the agent may trust, which tools it may invoke, and which outputs require human review before execution. That means separating read-only context collection from write-capable actions, and using short-lived credentials rather than persistent tokens wherever possible. The OWASP Agentic AI Top 10 is a practical reference for the most common failure modes, including prompt injection, excessive agency, and insecure tool invocation.
In operational terms, security teams should map the agent’s behaviour to the same controls used for other privileged automation:
- Limit tool scope so the agent can only call approved actions.
- Segregate duties so the agent cannot both propose and finalise high-risk changes.
- Validate every external input, including tickets, chat messages, and commit text, before it reaches the model.
- Log tool calls, context sources, and outputs for incident review and replay.
- Use policy checks outside the model so approvals do not depend on model judgment alone.
Threat modelling should also include model and workflow abuse paths, not just infrastructure compromise. The MITRE ATLAS adversarial AI threat matrix helps teams reason about prompt manipulation, evasion, and indirect control of agent decisions. For agentic systems that can modify code or trigger releases, the same pipeline should be reviewed as part of broader software supply chain governance. These controls tend to break down when agents are given broad repository access, because untrusted text can steer actions across multiple stages faster than manual review can intervene.
Common Variations and Edge Cases
Tighter agent control often increases release friction, requiring organisations to balance delivery speed against assurance. That tradeoff is real, and best practice is evolving. Some teams permit agents to prepare changes but not merge or deploy them; others allow low-risk automation with step-up approval for production actions. There is no universal standard for this yet, but the direction of travel is clear: the higher the blast radius, the less autonomy the agent should have.
Edge cases appear when the pipeline spans multiple repositories, shared runners, or external ticketing systems. In those environments, a single poisoned instruction can travel further than expected, especially if the agent can reuse context across tasks. Human approval alone is not enough if approvers cannot see the exact context the agent consumed. That is why provenance, traceability, and context minimisation matter as much as policy wording. For broader governance and risk mapping, the NIST AI Risk Management Framework and CSA MAESTRO agentic AI threat modeling framework are useful starting points, while the Anthropic AI-orchestrated cyber espionage report shows how agentic misuse can become operationally real. This guidance breaks down most often in legacy CI/CD environments where shared credentials, weak secrets hygiene, and ad hoc approvals make every stage equally trusted.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and MITRE ATLAS address the attack and risk surface, while NIST AI RMF, NIST CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | Agentic app abuse patterns map directly to prompt injection and excessive agency in CI/CD. | |
| NIST AI RMF | AI RMF covers governance, risk, and impact from autonomous AI decisions in pipelines. | |
| MITRE ATLAS | ATLAS helps model prompt abuse, evasion, and adversarial manipulation of agent decisions. | |
| NIST CSF 2.0 | PR.AA | Identity and access controls govern what the agent can do once it receives context. |
| NIST SP 800-63 | Strong identity assurance supports trusted approvals and traceable operator actions. |
Use verified human identities for approvals and keep agent actions attributable to a controlled account.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 2, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
