TL;DR: Generative AI is moving into CI/CD pipelines, cloud APIs, and production workflows, and Xygeni argues that the OWASP GenAI Security Project now provides a practical threat model for agentic systems, tool misuse, and permission abuse. The core issue is that AI-driven automation expands the blast radius of trusted actions faster than traditional pipeline controls can govern it.
At a glance
What this is: OWASP’s GenAI Security Project is being positioned as a DevOps security framework for AI-enabled pipelines, with the key finding that agentic and tool-connected AI create new abuse paths across CI/CD and cloud automation.
Why it matters: It matters because DevSecOps teams now need to govern AI agents, prompts, tools, and permissions as part of the control plane, not as a separate model-security problem.
Context
Generative AI security is no longer limited to model quality or prompt safety. Once LLM-powered features and agents are wired into CI/CD, cloud APIs, and deployment tooling, the relevant risk becomes pipeline governance, permission scope, and execution control.
This article is primarily about the security boundary shift inside DevOps. The identity angle is real because the systems being governed are not just applications, but agents and tool-connected services acting with credentials, making NHI-style controls part of the control surface.
Key questions
Q: How should security teams govern AI agent spend in CI/CD pipelines?
A: They should treat spend governance as a request-level control problem, not a billing review problem. The gateway should tag every call with owner metadata, track cumulative cost by repo and team, and enforce thresholds with clear alert and fail-closed behaviour. That makes cost overruns actionable and ties accountability to the workload that caused them.
Q: Why do over-privileged AI agents create higher business risk than ordinary users?
A: Over-privileged agents can execute many more actions than the task actually requires, so one bad decision can cascade into wrong approvals, refunds, data movement, or API calls. The risk is not just misuse. It is that the agent can act quickly, repeatedly, and without the human timing constraints that limit user mistakes.
Q: What breaks when prompt injection can reach deployment automation?
A: The break point is trust in the instruction path. If untrusted input can influence a deploy, config update, or infrastructure task, the pipeline is no longer only executing approved code. It is executing attacker-influenced intent through a legitimate mechanism, which makes traditional code-only controls insufficient.
Q: Should teams prioritise provenance or observability for GenAI security in pipelines?
A: Provenance should usually come first because teams need to know which models, prompts, tools, and descriptors are allowed to influence execution. Observability then proves what actually happened at runtime. Together they create a governable chain from approved inputs to recorded actions, which is essential once AI participates in delivery.
Technical breakdown
Why agentic AI changes DevOps trust boundaries
A conventional pipeline assumes automation is deterministic: a job runs because a defined trigger fires, and the job does only what the job definition allows. Agentic AI breaks that assumption by introducing runtime decision-making, tool selection, and context-dependent action. Once an agent can plan, call tools, and persist state, the security question shifts from whether code is correct to whether the system is allowed to decide. That creates a governance gap around intent, authority, and scope that classic CI/CD controls were not designed to manage.
Practical implication: Treat agent behaviour as an authorization problem, not just a model-quality problem.
How prompt injection and tool misuse bypass pipeline controls
Prompt injection is risky in DevOps because it can steer a legitimate workflow into an unsafe action without exploiting a traditional software vulnerability. Tool misuse is the adjacent failure mode: the agent is granted access to repositories, runners, or cloud APIs and then uses those permissions in ways the operator did not intend. In both cases, the action can appear authorized because the system is using valid credentials and approved integrations. That is why the attack surface sits at the intersection of input trust, tool trust, and permission trust.
Practical implication: Block unsafe tool paths with allowlists, scoped tokens, and execution policy around sensitive actions.
Why provenance and observability matter for AI supply chain security
The article’s supply-chain point is that AI-enabled delivery inherits risk from prompts, tools, model dependencies, and descriptors, not just from application code. If those components are changed, poisoned, or swapped without strong provenance, the pipeline can faithfully execute untrusted instructions at machine speed. Observability matters because teams need to reconstruct why an agent acted, what inputs it consumed, and which tool chain it followed. Without that evidence, post-incident analysis is weak and guardrail tuning becomes guesswork.
Practical implication: Pin, verify, and log every AI-related artifact before it reaches execution paths.
Threat narrative
Attacker objective: The objective is to induce trusted AI automation to carry out unsafe build, deployment, or infrastructure actions without triggering traditional controls.
- Entry occurs when untrusted prompts, poisoned tool definitions, or manipulated context reach an AI-enabled DevOps workflow through normal pipeline inputs.
- Escalation follows when the agent uses valid credentials or tool access to perform actions beyond the operator’s intent, such as changing infrastructure or modifying deployments.
- Impact is the silent execution of unsafe pipeline steps, where authorised-looking automation produces unauthorized operational change at scale.
Breaches seen in the wild
- PyPI secrets exposure 2023: Researchers found 3,938 unique secrets in published PyPI packages, 768 still valid; a new release or yank does not remove them.
- Miasma and Hades Supply Chain Worms: Self-propagating supply chain worms Miasma and Hades compromise npm, PyPI, and Azure credential stores.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
OWASP GenAI Security Project gives DevSecOps teams a control vocabulary for a new class of machine-initiated risk. The important shift is not that AI introduces another workload, but that it can now choose actions inside the delivery path. That makes agent authorization, not just model hardening, the central governance problem. Practitioners should treat AI-driven execution as a distinct policy domain with its own approval boundaries.
AI agents in pipelines behave like non-human identities with delegated authority. That is the identity-security bridge this article makes explicit. Once an agent can access repos, CI runners, cloud APIs, and deployment tools, the failure mode becomes overprivileged NHI behaviour, not merely application misuse. The right lens is lifecycle control over permissions, tokens, and tool scope. Practitioners should manage AI agents as governed identities, not informal automations.
Prompt injection matters here because it becomes an execution-control bypass, not just an input problem. The article correctly shows that a malicious instruction can trigger a legitimate step when the workflow lacks separation between planning and execution. That is a control-plane weakness, not a content-filtering weakness. Practitioners should assume trusted tooling can be steered unless execution policy is explicitly enforced.
Supply-chain integrity now extends to prompts, descriptors, and agent tooling, not only source code. This is the article’s most durable message for the broader field. If model inputs and external tools are unverified, the pipeline can execute compromised intent with full operational legitimacy. Practitioners should fold AI artifacts into provenance, attestation, and change-control processes.
Observability is the difference between governable automation and opaque delegation. Without an audit trail for what the agent saw, why it acted, and which tool it called, security teams cannot prove policy conformance or investigate abuse. That creates governance debt quickly in fast-moving DevOps environments. Practitioners should require traceability before expanding AI authority.
From our research library:
- Generative AI use specifically increased from 33% in 2023 to 79% in 2025, according to McKinsey’s Global Surveys on the State of AI.
- Read next: AI Supply Chain Security and AI-BOM Guide
What this signals
AI governance debt is now a DevSecOps issue. The longer teams treat agents as scripts instead of delegated actors, the harder it becomes to explain, restrict, or audit their behaviour. In practice, that means AI security controls need to be built into pipeline design rather than bolted on after rollout.
Agentic AI security and NHI governance are converging. Once an agent holds credentials, uses tools, and influences production change, the relevant control problem looks much closer to machine identity governance than to model-only security. Teams should expect future programme boundaries to blur between IAM, DevSecOps, and AI risk management.
For practitioners
- Model AI-enabled pipelines as governed identities Inventory every agent, model connector, tool integration, and pipeline account that can take action. Assign explicit owners, scope each credential, and define where human approval is still required.
- Separate planning from execution Keep recommendation and action in different trust domains so an AI prompt cannot directly trigger a deploy, config change, or infrastructure update without policy enforcement.
- Apply least privilege to agent credentials Limit API access, CI permissions, repository scope, and deployment rights to the smallest set of actions the workflow actually needs. Use short-lived credentials where possible.
- Pin and verify AI supply chain inputs Control versions for models, prompts, tools, and descriptors, then verify provenance before those artifacts influence build or deployment paths.
- Log agent decisions and tool use Capture the prompt context, selected tools, executed steps, and resulting changes so you can trace why an automated action occurred and whether it matched policy.
Key takeaways
- Generative AI in CI/CD changes the risk model because agents can now influence execution, not just output.
- The article’s core governance problem is delegated machine authority, especially when AI systems inherit credentials and tool access.
- Security teams need provenance, execution boundaries, and observability before they expand AI authority in delivery pipelines.
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, OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The article centers on agents using delegated access inside pipelines. |
| ASI04 — Agentic Supply Chain Vulnerabilities | The article highlights risk from tools, prompts, and AI dependencies in delivery chains. | |
| Recommendation — Scope agent privileges tightly and block actions that exceed delegated authority. Verify AI-related artifacts and pin trusted inputs before execution paths use them. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | The article treats AI agents as systems that often inherit excessive permissions. |
| NHI-10 — Human Use of NHI | The article's DevOps framing shows humans delegating operational actions to AI systems. | |
| Recommendation — Reduce agent permissions to the minimum set needed for each workflow step. Define human approval points wherever an agent can trigger production change. | ||
| NIST AI RMF | GOVERN — AI Governance and Accountability | The article is fundamentally about governance of AI-enabled automation in operations. |
| Recommendation — Establish accountable ownership for each AI workflow and its permitted actions. | ||
| MITRE ATT&CK | TA0006;TA0040 — Credential Access; Impact | The article describes abuse paths that rely on trusted credentials and harmful pipeline actions. |
| Recommendation — Map agent misuse scenarios to credential access and impact techniques in detection content. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The piece repeatedly emphasizes permissions, scoped access, and tool authorization. |
| Recommendation — Review entitlements for AI agents and remove any standing access beyond operational need. | ||
Key terms
- Agentic AI: Autonomous AI systems capable of planning, deciding, and taking actions, including calling APIs, writing code, and orchestrating other agents, with minimal human oversight. Agentic AI introduces new NHI risks as agents must authenticate to external services.
- Prompt Injection (Agentic): An attack where malicious instructions are embedded in content that an AI agent reads, causing the agent to execute unintended actions using its own legitimate credentials. A primary vector for agent goal hijacking and identity abuse.
- AI Supply Chain Security: AI supply chain security is the practice of protecting the people, data, models, code, tools, and services used to build and run AI systems. It covers risks from training data, model artifacts, dependencies, prompts, connectors, and deployment pipelines, with controls for integrity, provenance, access, and change monitoring across the full lifecycle.
- Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
Deepen your knowledge
NHI Mgmt Group's NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security, IAM, and DevSecOps practitioners apply identity controls where automation and AI now make decisions.
Published by the NHIMG editorial team on August 21, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org