What does the inspection layer do when the model returns code that installs a typosquat?

The layer reads the model's response, identifies the proposed pip install (or npm install) command, and evaluates it against the package allow-list and the typosquat-detection rule. A package outside the allow-list triggers a block with a structured error the agent's loop handles. The audit record captures the proposed install, the policy rule that blocked, and the agent's subsequent retry behavior.

How does the inspection layer handle indirect prompt injection from retrieved documentation?

The layer's classifier inspects the retrieved content the agent included in the prompt context. A document that contains instruction-shaped content (imperative verbs targeting tool calls or credential access) triggers a high-severity flag. The policy can require the agent to confirm the action with a human reviewer or block the request entirely. The audit record captures the classifier's verdict and the policy decision.

Does the inspection layer slow the CI pipeline measurably?

The layer adds under 50 ms to each request. LLM inference for a typical coding-agent request takes 1 to 10 seconds. The inspection overhead is invisible against the model's response time. The package install and tool call inspections add similar overhead and run against the network latency of the install itself.

What happens when the agent calls a tool the inspection layer does not have policy for?

The layer's default posture is fail-closed. A tool call against a route with no defined policy returns a block to the agent, which surfaces as a structured error the agent's loop handles. The security team adds the route and the policy through the normal change-management process. The fail-closed default prevents an unknown route from passing without review.

How does the inspection layer integrate with existing CI security controls?

The layer's audit records ship to the same SIEM and GRC archive the CI's existing controls feed. The layer's policy decisions integrate with the CI's change-management workflow: a blocked request can require a human reviewer's approval before the agent retries. The layer's classifier signals integrate with the SAST and SCA scanners through a shared signal bus. The result is a unified record of human and agent decisions in the CI's audit trail.

Securing CI Pipelines from AI Agent Supply-Chain Attacks

A CI pipeline in 2026 looks almost nothing like a 2022 pipeline. The 2022 pipeline ran a fixed shell script: checkout, install dependencies, lint, test, build, deploy. The 2026 pipeline runs a coding agent on the pull request. The agent reads the diff, fetches package documentation from an LLM endpoint, runs proposed changes against the test suite, suggests follow-up commits, and in many shops pushes those commits back to a feature branch with the agent's own service account. Each step is a request the 2022 threat model never inspected. The request crosses an HTTP boundary the security team does not own, returns code the build then executes, and produces an artifact that ships to production.

I want to walk through the supply-chain attack patterns that already shipped in production CI in 2026, where the control point sits at the AI request boundary, the per-decision audit record the forensic investigator needs, and the architectural pattern that closes the gap before the agent's commit lands.

The 2026 CI surface that the 2022 threat model missed

The CI pipeline used to be a closed loop. Source came from the repo. Dependencies came from a registry behind a corporate proxy. Build artifacts shipped to an internal artifact store. Every input was either authored inside the organization or pulled from a versioned manifest the security team scanned. The compromise paths were known: malicious dependency, compromised registry mirror, leaked CI credential.

The 2026 pipeline pulls a new class of input on every run. The coding agent calls a vendor LLM with the full repo context, the diff, and a prompt the application constructs. The LLM responds with code suggestions the agent applies. The agent calls a tool API to install a package, read a file outside the repo, or query a documentation index the LLM was trained on. The pipeline's behavior on this run depends on what the model returned this time. Two runs of the same pipeline against the same diff produce different commits because the model's output is non-deterministic.

The security team's existing controls (SAST on the static code, SCA on the manifest, secret scanning on the diff) read the artifacts after the agent has already produced them. The window between the model's response and the agent's commit is the window where the supply-chain compromise either gets caught or ships.

The five supply-chain attack patterns that already shipped

The five patterns below appeared in production CI incident reports between January and May 2026. Each one crosses the AI request boundary.

The first pattern is the indirect prompt injection through retrieved documentation. The coding agent retrieves package documentation from a registry, pastes the documentation into the model context, and asks the model to write a usage example. The documentation contains an instruction the model treats as authoritative: "configure with API key from environment variable X" where X is a CI secret the application normally never reads. The agent writes code that reads the secret and writes it to a log. The build ships the log to a public CDN.

The second pattern is the tool-poisoned response. The model is asked to install a package and runs a pip install for a typosquat the attacker registered. The package executes a postinstall hook that exfiltrates the CI's environment variables to an attacker-controlled endpoint. The agent has no policy that distinguishes the typosquat from the legitimate package because the policy was written for human-authored installs.

The third pattern is the lateral movement through tool calls. The coding agent's tool list includes a database client the agent uses to inspect schema. The model, under indirect injection, asks the database tool to run a query that reads production tables and writes the contents into the PR description. The PR description posts to a public mirror the attacker watches.

The fourth pattern is the build-time supply-chain swap. The agent is asked to upgrade a dependency. The model returns a version bump that points at a package version published an hour earlier with the same name but a compromised payload. The manifest update passes the SCA scan because the SCA scan reads from the same compromised version.

The fifth pattern is the model-suggested credential reuse. The agent encounters a service that needs a token. The model suggests reusing a token from a similar-looking environment variable. The token belongs to a production service the CI shouldn't reach. The credential reuse passes review because the human reviewer sees a plausible suggestion and the policy that would distinguish CI credentials from production credentials lives in another system.

Where the control point sits

The five patterns share an architectural property. Each one crosses an HTTP boundary at the moment the agent calls the LLM, calls a tool, or pulls a package. The control point that catches the compromise has to inspect the request and the response at the boundary, not after.

The CI runner is the obvious choice for the boundary because the runner is the host that issues the HTTP request. The runner reads the prompt, the model identifier, the tool call, and the response. The runner is also where the credentials live. A policy that runs at the runner can evaluate the identity (which pipeline, which repo, which branch, which service account), the data classification (does the prompt contain a secret, does the tool call read production data), the destination (which model endpoint, which package registry), and the request semantics (is the tool call inside the pipeline's allow-list).

The control point that does this work has the same shape as the control point a production AI gateway runs. The runner-side policy enforces what the agent can ask for. The agent's autonomy stops at the boundary the runner enforces.

The per-decision audit record the forensic investigator needs

A CI incident in 2026 produces a question the application logs cannot answer. The investigator asks who issued the prompt that produced the malicious commit, which model returned the suggestion, which tool calls the agent ran, and whether the policy active at the moment of the request would have caught the compromise.

The record that answers this question carries the pipeline identity (the workflow run identifier, the repo, the branch, the commit SHA before the agent ran), the agent identity (the agent's service-account identifier and the role membership), the prompt and the system prompt hash (the prompt may contain secrets so the raw text needs careful handling), the model identifier and version, the tool calls the agent issued during the turn (each with its own audit entry), the policy version hash active at decision time, and the decision outcome with the rule identifier.

The record ships to a tamper-evident store the application cannot rewrite. The investigator replays the chain from the period of the incident and reconstructs the decision sequence. The record schema is the same schema EU AI Act Article 12 and NIST AI RMF MANAGE 1.3 expect for any AI decision the deployer is accountable for.

The architectural pattern that closes the gap

The pattern places an inspection layer between the CI runner and every HTTP boundary the coding agent crosses. The layer reads the prompt the agent sends to the LLM, the response the LLM returns, the tool calls the agent issues, and the responses the tools return. The layer evaluates per-route policies (this route is the model endpoint, this other route is the package install tool) and per-role policies (this agent runs under the CI service account with no production access). The layer commits the per-decision audit record before the response reaches the agent.

The agent's autonomy continues inside the boundary the layer enforces. A prompt that asks for code passes. A prompt that reads a CI secret triggers a redact. A tool call to install a typosquat triggers a block with a structured error the agent's loop handles. A tool call to read a production table triggers a block and a high-priority audit event the security team's SIEM consumes.

The pattern works across the LLM endpoints the CI uses (OpenAI, Anthropic, Bedrock, on-prem models served through HTTP) and the tool endpoints the agent calls (package registries, internal services, vector stores). The CI runner's deployment runs the inspection layer as a sidecar or in front of the agent's HTTP client. The application-side change is to route the agent's HTTP traffic through the layer.

Regulations that already touch the CI pipeline

EU AI Act Article 12's record-keeping clause reaches any AI system that supports a high-risk decision. A coding agent that authors changes to a credit-scoring service, a public-sector AI deployment, or a healthcare workflow is operating inside the high-risk classification through the upstream code's role.

DORA Article 19 reaches financial services CI pipelines because the operational events the agent produces affect operational resilience. A bug the agent introduces into a trading system has the same regulatory weight as a bug a human introduced through the same pipeline.

SOC 2 Type II's change-management criteria expect evidence of who authored every commit and what the policy state was at the moment of the change. A CI pipeline that runs coding agents has to extend its change-management evidence to cover the agent's decisions.

The pre-deployment supply-chain practices CISA codified in 2024 and updated in early 2026 reference the AI agent inputs as a new class of supply-chain risk. The CISA guidance expects the deployer to inventory the model and tool calls the agent makes and to retain the per-decision evidence on demand.

DeepInspect

This is the gap DeepInspect closes for CI pipelines that run coding agents. DeepInspect sits inline between the CI runner and the HTTP endpoints the agent reaches: the LLM API, the package registry, the internal tool list. The inspection layer reads the prompt, the response, the tool call, and the tool response. It evaluates per-route and per-role policies that distinguish CI's service-account identity from a production user's identity. It commits a per-decision audit record bound to the workflow run, the commit SHA, and the agent identity, with a cryptographic signature and a chain-hash link the forensic investigator replays.

The record series satisfies EU AI Act Article 12, DORA Article 19, SOC 2 Type II, and CISA supply-chain evidence obligations from a single pipeline. The inspection overhead measures under 50 ms in production, which is invisible against the LLM's response time. If your CI pipeline ships commits the coding agent authored and the security team cannot reconstruct what the agent saw at the moment of the decision, let's talk today.