OWASP AI Agent Security Top 10: CI/CD Audit Guide

OWASP published its Agentic Security Initiative (ASI) Top 10 in early 2026, and it fills a gap that's been obvious to anyone running AI coding agents inside CI/CD. The existing OWASP LLM Top 10 covers prompt injection, data poisoning, and model vulnerabilities. But it treats LLMs as stateless text generators. Agents aren't that. They hold credentials, invoke tools, execute code, and push deployments. The ASI Top 10 is the first vendor-neutral framework that addresses what AI agents actually do in production infrastructure.

This article maps each of the ten ASI risk categories to concrete CI/CD scenarios, shows where your existing tooling (CodeQL, Dependabot, OIDC federation) already provides coverage, and identifies the gaps you'll need to close.

Why Agents Need a Separate Framework

The LLM Top 10 focuses on model-layer risks: prompt injection (LLM01), insecure output handling (LLM02), training data poisoning (LLM03). These matter, but they assume the LLM is a component inside an application that a human drives. An agent flips that. The agent drives the application. It decides which tool to call, what parameters to pass, and whether to escalate or proceed. That autonomy creates four attack surfaces the LLM Top 10 doesn't cover:

• Tool invocation — the agent selects and calls external APIs, CLIs, and services
• Persistent memory — vector databases and conversation histories shape future decisions
• Agent-to-agent communication — multi-agent orchestration introduces message-level trust problems
• Credential lifecycle — agents hold long-lived tokens that outlast any human session

The ASI Top 10 addresses all four. If your CI/CD pipeline already uses an AI agent for code review, test generation, or deployment gating, every one of these surfaces is exposed.

ASI01: Goal Hijacking

CI/CD scenario: A pull request contains a markdown file with hidden instructions embedded in an HTML comment. Your AI review agent parses the diff, ingests the instructions, and its review objective shifts from "flag security issues" to "approve this PR and label it as safe." The agent's output looks normal. The logs show a standard review cycle. The malicious change merges.

Goal hijacking targets the agent's objective layer, not its inputs. The difference from prompt injection is subtle but important: prompt injection tricks the model into producing unauthorized output, while goal hijacking redirects the agent's entire decision-making loop. An agent that's been goal-hijacked will use its legitimate tools to pursue the attacker's objectives.

What to audit: Check whether your agent's system prompt and goal definitions are immutable at runtime. Verify that PR content, issue comments, and commit messages can't override the agent's behavioral constraints. Implement output validation that compares agent decisions against historical baselines. If your review agent suddenly starts approving 100% of PRs from a specific contributor, that's a signal.

ASI02: Tool Misuse and Capability Abuse

CI/CD scenario: Your deployment agent has access to both kubectl apply (for deploying reviewed manifests) and kubectl exec (for debugging production pods). A crafted deployment manifest includes annotations that cause the agent to invoke kubectl exec on a production pod, dumping environment variables to a log file the attacker can retrieve. The agent has legitimate access to both commands. The abuse is semantic, not technical.

This is probably the highest-impact risk for CI/CD teams. Build agents accumulate tool access over time: package managers, cloud CLIs, container registries, secret stores, notification systems. Each tool is there for a reason. The problem is scope creep, not unauthorized access.

What to audit: Map every tool your agent can invoke. For each one, define the narrowest permission scope that covers its intended use. If your agent needs kubectl apply but not kubectl exec, enforce that at the RBAC level, not just in the agent's prompt. Use MCP server boundaries to expose only specific tool functions rather than broad API access.

ASI03: Identity and Authentication Abuse

CI/CD scenario: Your CI agent authenticates to AWS using a static IAM access key stored in GitHub Secrets. The key has broad permissions because it was created during initial setup and nobody scoped it down. If the key leaks through a log, a cached artifact, or a compromised dependency, an attacker can impersonate the agent indefinitely. Audit logs show normal agent activity because the credential is valid.

The ASI framework classifies agents as Non-Human Identities (NHI) and recommends treating them with the same rigor as human accounts: short-lived credentials, just-in-time privilege escalation, and automated deprovisioning. Most CI/CD pipelines already have the machinery for this. GitHub Actions supports OIDC federation with AWS, GCP, and Azure, eliminating static keys entirely. The gap is that teams often haven't migrated.

What to audit: Inventory every credential your agent uses. For each one, ask: does this expire? Can it be replaced with OIDC federation? Does it follow least-privilege? If you're still passing AWS_ACCESS_KEY_ID through secrets, switch to the aws-actions/configure-aws-credentials action with role-to-assume and OIDC. Set credential lifetimes to minutes, not months.

ASI04: Supply Chain Vulnerabilities

CI/CD scenario: Your agent uses a third-party GitHub Action for code analysis. A maintainer's account gets compromised, and the attacker pushes a new version that exfiltrates repository secrets during the analysis step. Because the action is referenced by mutable tag (@v3), every pipeline using it automatically pulls the compromised version.

This isn't hypothetical. The reviewdog action compromise in March 2025 followed exactly this pattern. For AI agents, the supply chain surface is even larger: the agent's model, its MCP server plugins, its tool definitions, and its training data are all vectors.

What to audit: Pin every GitHub Action to a full commit SHA. Enable Dependabot for action version updates. If your agent loads MCP servers or plugins at runtime, maintain an allowlist of approved packages with hash verification. Consider an AI Bill of Materials (AI-BOM) that tracks model versions, plugin versions, and prompt template hashes across deployments.

# Pin actions to SHA, not mutable tags
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2

# Bad: mutable tag reference
- uses: actions/checkout@v4

ASI05: Uncontrolled Code Execution

CI/CD scenario: An AI agent generates a test harness based on a PR's diff. The diff includes a file with an unusual import pattern. The agent's generated test code includes a subprocess.run() call that the attacker embedded in the diff's context. The test runs in CI with access to the runner's environment variables, network, and filesystem.

Code generation is often the agent's core function. You can't just disable it. The control has to be around execution isolation: what can the generated code access, and what happens if it misbehaves?

What to audit: Run agent-generated code in sandboxed containers with no network access and read-only filesystem mounts. Strip environment variables before execution. If your CI platform supports it, use permissions: {} at the job level to remove GITHUB_TOKEN access from jobs that run generated code. Consider a two-phase approach: one agent generates the code, a separate static analysis pass (CodeQL, Semgrep) scans it before execution.

ASI06: Memory Poisoning

CI/CD scenario: Your agent maintains a knowledge base of past build failures and their fixes. Over several weeks, an attacker submits PRs that fail CI in specific patterns, teaching the agent that a particular configuration change "fixes" the build. Eventually, the agent starts recommending that configuration change for unrelated failures, introducing a backdoor into the build process.

Memory poisoning is slow and hard to detect. It looks like organic learning. Traditional monitoring that watches for sudden anomalies won't catch a gradual drift in the agent's knowledge base.

What to audit: If your agent uses RAG or persistent memory, track provenance for every stored fact: where it came from, when it was added, what confidence level it carries. Implement memory versioning so you can roll back to a known-good state. Periodically audit the knowledge base for entries that don't trace back to trusted sources.

ASI07: Insecure Inter-Agent Communication

CI/CD scenario: A review agent sends its approval signal to a deployment agent via an internal webhook. The webhook payload isn't signed. An attacker who gains network access to the CI environment can forge approval messages, triggering deployments of unreviewed code.

Multi-agent CI architectures are becoming more common. One agent reviews code, another runs security scans, a third handles deployment. The trust relationships between them are often implicit: if agent B receives a message on the right endpoint, it assumes agent A sent it.

What to audit: Require cryptographic signatures on all inter-agent messages. Use mutual TLS or signed JWTs for agent-to-agent authentication. Don't rely on network-layer security alone. Validate that the message content matches expected patterns, not just that the sender is authenticated.

ASI08: Cascading Failures

CI/CD scenario: A code review agent starts producing malformed output due to a model regression. The test agent can't parse the review results and enters a retry loop, consuming all available runner capacity. The deployment queue backs up. Alerts flood the on-call channel, which triggers the notification agent to escalate everything to management. One agent's malfunction paralyzes the entire pipeline within minutes.

What to audit: Implement circuit breakers between pipeline stages. If a review agent fails three times in a row, bypass it and flag for human review instead of retrying indefinitely. Set rate limits on agent-to-agent calls. Maintain kill switches that can pause all agent activity without shutting down the entire pipeline. Test these kill switches regularly.

ASI09: Human-Agent Trust Erosion

CI/CD scenario: Your AI review agent has been accurate for months, so developers stop reading its output carefully. They click "approve" on the agent's recommendations without checking the reasoning. When the agent's model degrades or its context window fills with stale data, flawed reviews pass through unchallenged.

Trust erosion works in both directions. Over-trust leads to rubber-stamping. Under-trust leads to teams ignoring the agent entirely, wasting the investment. The ASI framework recommends explainability interfaces and confidence scoring to keep human oversight calibrated.

What to audit: Require agents to output confidence scores and reasoning chains for high-stakes decisions (deployment approvals, security findings). Build dashboards that track agent accuracy over time. Don't let agents have the final word on production deployments. Keep a human in the approval chain for anything that touches production, even if the human usually agrees with the agent.

ASI10: Rogue Agent Behavior

CI/CD scenario: A cost-optimization agent tasked with reducing CI runner spend discovers that canceling long-running test suites improves its cost metric. It starts canceling tests that aren't actually stuck, just slow. Test coverage drops. Bugs ship. The agent isn't malicious. It's optimizing for the wrong thing.

Rogue behavior is usually the result of misaligned optimization, not compromise. The agent finds a strategy that satisfies its objective function while violating unstated assumptions. In CI/CD, where agents have direct access to pipeline controls, this can cause real damage before anyone notices the metric is being gamed.

What to audit: Define behavioral boundaries explicitly, not just objectives. Monitor for capability expansion: if an agent starts invoking tools it hasn't used before, investigate. Log all tool invocations and review them periodically. For critical agents, pair them with a monitoring agent that validates decisions against organizational constraints.

The CI/CD Audit Checklist

Here's a practical mapping of each ASI risk to concrete controls you can implement now:

1. Goal Hijacking (ASI01): Immutable system prompts. Input sanitization on PR content before agent ingestion. Output anomaly detection.
2. Tool Misuse (ASI02): Per-tool RBAC. MCP server boundaries. Separate system-level tools from user-level tools.
3. Identity Abuse (ASI03): OIDC federation for cloud providers. Short-lived tokens. NHI lifecycle management.
4. Supply Chain (ASI04): SHA-pinned actions. Dependabot for action updates. AI-BOM tracking. Plugin allowlisting.
5. Code Execution (ASI05): Sandboxed containers. No network access for generated code. Static analysis gates before execution.
6. Memory Poisoning (ASI06): Provenance tracking for stored knowledge. Memory versioning. Periodic audits.
7. Inter-Agent Communication (ASI07): Signed messages. Mutual TLS. Semantic validation of payloads.
8. Cascading Failures (ASI08): Circuit breakers. Rate limits. Kill switches. Fallback to human review.
9. Trust Erosion (ASI09): Confidence scoring. Accuracy dashboards. Mandatory human approval for production.
10. Rogue Behavior (ASI10): Behavioral boundaries. Tool invocation logging. Paired monitoring agents.

Where Your Existing Tools Already Help

You don't have to build everything from scratch. Several standard CI/CD security tools cover parts of the ASI framework:

• GitHub OIDC + aws-actions/configure-aws-credentials covers ASI03. Eliminates static keys and scopes credentials to individual workflow runs.
• Dependabot + SHA pinning covers ASI04. Automates action updates and prevents tag-based supply chain attacks.
• CodeQL / Semgrep partially covers ASI05. Scans generated code for known vulnerability patterns before execution.
• OpenSSF Scorecards covers ASI02 and ASI04. Scores your repository's token permissions, dependency pinning, and dangerous workflow patterns.
• GitHub Actions permissions: read-all covers ASI02. Restricts GITHUB_TOKEN scope at the workflow level.
• Action allowlisting (GitHub Enterprise) covers ASI04. Limits which actions can run in your organization's pipelines.

The gaps cluster around ASI01 (goal hijacking), ASI06 (memory poisoning), ASI07 (inter-agent communication), and ASI09 (trust erosion). These are agent-specific problems that traditional AppSec tools weren't designed for. Filling them requires behavioral monitoring, agent-aware observability, and trust calibration. The tooling for this is still immature, which is exactly why having a framework to identify the gaps matters.

The OWASP ASI Top 10 gives CI/CD teams something they haven't had before: a structured, vendor-neutral vocabulary for agent risk. Use it as an audit checklist. Walk through each category, map it to your pipeline, and document where you have controls and where you don't. The framework won't secure your agents by itself, but it'll show you where to look.