What is the actual risk of an AI code review bot?

The risk is source-code egress. To review a change, the bot sends the diff and surrounding files to an LLM over HTTP, which moves proprietary code, and occasionally a committed secret, out of your environment on every run. If that traffic is unattributed, unclassified, and unrecorded, the organization cannot say what code left, from which repository, or to which model. The review output is useful and the exposure on the request path is the part that needs controls.

Does the bot's own configuration control what it sends?

Only loosely. The bot assembles its prompt at runtime from the diff and a context window it selects, so the exact content leaving is not the template a developer reviewed. A secret or a sensitive file can land in that window without anyone approving it. Controlling what actually leaves requires classifying the outbound prompt at the model boundary, which is a request-layer control the bot's configuration does not provide.

How do you keep a review bot from leaking secrets to the model?

Classify the outbound prompt against secret patterns at the gateway and block or redact the call before it reaches the model, rather than relying on the model to ignore a secret it received. Pair that with egress control so the bot cannot reach a provider directly, and per-repository identity so policy can be stricter on sensitive repositories. Secret scanning on the repository itself remains the upstream control that keeps secrets out of commits in the first place.

Is prompt injection through a pull request a real concern?

Yes. A PR can contain text crafted to steer the review bot, since the bot reads the diff as input. An injected instruction that changes what the bot decides runs inside the CI environment, outside a network gateway. What the gateway sees is the outbound consequence: if the injection drives the bot to send extra source to the model or to reach an outside endpoint, identity-bound policy and egress control block and record that call. The gateway stops the manipulated bot from moving code it is not authorized to move.

AI Security for Code Review Bots: Governing the Source Code That Leaves for the Model

An AI code review bot works by shipping your source code to a model. It watches for a pull request, collects the diff and usually a window of surrounding files for context, and sends that content to an LLM over HTTP with an instruction to flag bugs and suggest changes. The review comment that lands on the PR is the visible output. The request behind it is proprietary source code, and sometimes a secret that a developer committed by accident, leaving the environment as an HTTPS POST to a model endpoint.

That request path is the whole security question for a code review bot. The bot's scheduling, its integration with the git host, and any local tooling it runs are application concerns. The content that crosses the network to the model is where source code and secrets are exposed, and where policy and audit have to attach.

Draw the boundary around the model call

A gateway governs the HTTP traffic between the review bot and the model. It does not govern the CI runner or the repository.

Inside the boundary:

The bot's HTTP call to the LLM, carrying the diff and any surrounding source.
The model's response returning to the bot.

Outside it:

The CI runner that executes the bot, the git host, and any local process the bot spawns. Those are application-security and pipeline concerns.
The developer's decision to commit a secret in the first place, which secret scanning on the repository has to catch.

The gateway is the control on what source leaves for the model and which bot sent it. Securing the pipeline that runs the bot is a separate job.

Bind each review to a bot and repository identity

The default setup gives the review bot one provider key across every repository it watches. A prompt from a public sample repo and a prompt from the core revenue service reach the model as the same credential, so nothing at the model boundary distinguishes them. Route calls through the gateway and bind each to a per-bot, per-repository identity. Policy can then treat a review on a low-sensitivity repo differently from one on a repository holding regulated or proprietary logic, and every model call names the repository whose code it carried.

Classify source and secrets in the outbound prompt

A review prompt is assembled at runtime from the diff plus whatever context window the bot pulls in, so the developer never hand-approves the exact bytes that leave. That window can include a credentials file, a private key, or a block of proprietary logic the diff happened to sit next to. The gateway classifies the outbound prompt against secret patterns and source-sensitivity classes, and applies policy on the class, so a call carrying a live secret is blocked or redacted before it reaches the model rather than flagged hours later. This is the request-layer control that a bot's own configuration cannot provide, because the bot assembled the context itself. The reasoning matches LLM application security: inspect the request, not the intent.

Keep the model call on one path with egress control

A per-bot identity is only enforceable if the bot cannot reach the provider directly. Restrict egress from the CI environment so the only route to any model endpoint runs through the gateway:

With egress constrained, a bot configured with a stray provider key, or an injected instruction hidden in a PR that tries to exfiltrate code to an outside endpoint, fails at the network. The egress control keeps the gateway as the single path every review call travels.

Record what the bot sent to the model

Every review call produces a decision record: the bot and repository identity, the data class in the prompt, the pass, block, or redact outcome, the policy version, and a timestamp. When a question comes up about whether proprietary source or a secret reached an external model, that record answers it per pull request. It commits before the review returns, on a write path the bot does not control, which is what makes it evidence rather than a log the same automation could drop.

DeepInspect

This is exactly what DeepInspect does. A code review bot sends source to an LLM over HTTP, and DeepInspect sits inline at that boundary between the bot and the model endpoint it calls.

For every request, DeepInspect binds the call to the bot and repository identity the application supplies, classifies the prompt against secret patterns and source-sensitivity classes, applies per-repository policy, and makes a deterministic, fail-closed decision before the diff reaches the model. Every decision commits a signed, identity-bound audit record before the response returns, on a write path the bot never controls. DeepInspect governs the model traffic and any HTTP tool traffic routed through it, and it does not secure the CI runner or the git host, which remain pipeline concerns. If you are running an AI reviewer across your repositories and cannot say which code reached which model, book a demo today.