What does the inspection layer do when the copilot retrieves source code with embedded API keys?

The classifier detects the secret patterns in the retrieved code. The policy applies the redaction before the prompt reaches the model. The record captures the redaction with the specific secret types redacted. The detected secret also surfaces to the security team's secret-scanning pipeline so the underlying issue (a secret in the source code) gets addressed through the normal remediation workflow.

How does the inspection layer handle export-controlled code?

The policy maintains the repository-to-export-classification mapping the security team owns. The layer evaluates the source repository the IDE is working in against the mapping. A prompt from an export-controlled repository routes only to model endpoints whose inference happens inside the controlled jurisdiction. The record carries the export classification and the routing decision.

Does the inspection layer slow the engineer's IDE workflow?

The layer adds under 50 ms to each request. LLM inference for a coding-agent request takes 1 to 10 seconds. The inspection overhead is invisible against the model's response time.

What about copilots that propose installing a package from npm or pip?

The model's response surfaces as a tool call the copilot would issue. The inspection layer reads the proposed call, validates the package against the allow-list the platform team maintains, and approves or blocks the install. The audit record carries the proposed package, the policy rule that fired, and the decision.

How does the inspection layer integrate with the existing SDLC controls?

The audit records feed the SOC 2 evidence repository alongside the existing IT general controls evidence. The policy authoring lives in the same change-management process the platform team uses for the existing SDLC controls. The inspection layer's classifier signals integrate with the existing secret scanner, SAST, and SCA through a shared signal bus.

AI Security for Engineering Copilots: The Identity, Source-Code, and Audit Controls a Production Deployment Has To Run

Engineering copilots reach across the data surfaces a platform team has been protecting through code-review gates, secret scanning, and SCA tooling since the team standardized the SDLC. The copilot reads into the source repository, the build infrastructure logs, the package registry, and (in the worst-case patterns the security team has been trying to lock down) the production credential store. The data inside the prompt at any given moment crosses export-control boundaries on cryptographic implementations, customer source-code confidentiality terms the master agreement set, secret-handling rules HSM-backed key management was supposed to enforce, and the SOC 2 Type II change-management evidence the auditor reads each year. A model invocation that pulls a function with embedded API keys, routes through a vendor LLM whose training-data exclusion the security team has not verified, and writes a derived suggestion back into the codebase is a sequence the customer auditor will read against if a downstream incident surfaces.

I want to walk through the identity-aware policy decisions an engineering copilot deployment has to commit at the request boundary, the audit record format that survives SOC 2 Type II review and customer audit, and the architectural pattern that closes the post-authentication gap most engineering copilots leave open.

The data the engineering copilot reads at request time

The copilot reads four categories of data that each carry distinct security obligations. The first is the source code itself (the application code the team is authoring). The second is the secrets that may appear in the source code (API keys, database passwords, signing keys, customer credentials the application reads from configuration). The third is the build and deployment context (CI configuration, the artifact identifiers, the deployment manifest). The fourth is the customer-derived material the source code may reference (the customer schema, the customer's data structure, the customer-supplied configuration).

Each category carries an explicit handling posture. The source code is restricted under the firm's IP policy and the customer master agreement's confidentiality terms. The secrets are restricted under the secret-management framework the security team operates. The build context is restricted under the SDLC controls SOC 2 evidence rests on. The customer-derived material is restricted under the data processing agreement with the customer.

A copilot that reads any of these categories into the prompt at request time is making a routing decision the security team has to be able to reconstruct after the fact. The reconstruction has to include the user identity, the data class, the model endpoint, and the policy state.

The identity-aware policy decisions

The decisions the deployment commits at the request boundary cover three orthogonal axes. The first is user-against-data. A backend engineer can read the backend source code. A frontend engineer can read the frontend source code. A security engineer can read both with elevated scope. A contractor can read only the code the contract scope permits. The policy reads the directory roles and the repository access the source control system maintains.

The second is data-against-model. A prompt that contains source code subject to export controls (cryptographic implementations under EAR Category 5 Part 2) cannot route to a model whose inference happens outside the controlled jurisdiction. A prompt that contains customer-derived material cannot route to a model whose data processing terms do not cover the customer's DPA requirements. A prompt that contains a detected secret receives a redaction or a block before the request reaches the model.

The third is suggestion-against-action. A copilot that proposes installing a package crosses the SCA and the typosquat-prevention controls. The action requires a policy step that validates the package against the allow-list. A copilot that proposes writing to production configuration crosses the change-management control. The action requires a routing step that confirms the change goes through the normal review.

The three axes compose. A user (backend engineer, on the team for the service) asks (a question about a code change) against (source code without secrets, routing to a model with appropriate processing terms). The combination produces a pass. A change on any axis (a detected secret appears in the prompt, the source code falls inside the export-control category, the model selection moves to a non-covered endpoint) produces a block or a modify.

The audit record format for SOC 2 Type II and customer audit

The record at decision time carries the seven fields a SOC 2 Type II change-management evidence test and a customer audit on the AI usage would each read. The identity carries the natural-person identifier (the engineer) and the agent identifier when the copilot acts on behalf of the engineer. The route carries the route identifier (which copilot function, which repository) and the policy bundle binding active at decision time. The data classification carries the inspection layer's classifier output on the prompt and the retrieved context (source code, secret, export-controlled, customer-derived). The policy version carries the version of the policy bundle the policy decision point read at decision time. The decision outcome carries pass, block, or modify with the rule identifier that produced the outcome. The model and version carries the upstream LLM the request forwarded to. The integrity metadata carries the cryptographic signature and the hash chain link.

The record satisfies SOC 2 Type II processing-integrity and change-management criteria because the deployer can produce evidence that the AI-assisted code changes operated inside the documented policy across the audit period. The record satisfies the customer audit on AI usage because the deployer can produce per-customer evidence of which customer-derived material crossed which model boundary. The record satisfies the export-control compliance evidence because the records establish which export-controlled material did not reach a non-controlled jurisdiction.

The post-authentication gap engineering copilots leave open

Most engineering copilots integrate with the firm's SSO, propagate the engineer's identity into the IDE session, and then call the model API through the IDE's plugin with a service account or a token the engineer holds. The model provider's logs carry the API key or the OAuth identifier rather than the natural-person identity. The IDE plugin's logs carry the engineer identity but lack the model selection on a per-call basis (when the IDE uses a single proxy), the classifier output on the prompt, and the policy state.

The auditor who asks "what customer-derived material entered the prompt context when engineer X worked on the customer Y integration" reads two log streams that were never designed to be joined. The customer audit that surfaces months later has no defensible record to rest on.

The architectural pattern that closes the gap

The pattern is an inspection layer at the HTTP boundary between the IDE plugin (or the agent's HTTP client) and each upstream the copilot calls. The layer reads the prompt, the retrieved context, the identity the IDE plugin propagates, and the policy state. The layer evaluates the user-against-data, data-against-model, and suggestion-against-action policies. The layer applies pass, block, or modify and commits the per-decision audit record before the response forwards.

The layer requires the IDE plugin to propagate the engineer's identity in the request. The standard pattern attaches the engineer identifier as a header or includes the identity in a signed JWT the layer verifies against the corporate IdP. The IDE plugin's identity propagation is the upstream obligation. The policy evaluation and the audit record commit are the inspection layer's obligation.

DeepInspect

This is the gap DeepInspect closes for engineering copilots. DeepInspect sits inline between the IDE plugin (or the agent's HTTP client) and any HTTP upstream the copilot calls. The inspection layer reads the prompt, the retrieved context, and the engineer's identity the plugin propagates. The layer evaluates identity-bound policy against the data classification (source code, secret, export-controlled, customer-derived) and the policy state. The layer applies pass, block, or modify and commits the per-decision audit record to durable, append-only storage with a cryptographic integrity signature before the response forwards.

The record series carries the natural-person identifier the engineer authenticated with, the repository identifier, the copilot session identifier, the route, the data classification, the policy version, the decision outcome, the upstream model and version, and integrity metadata. The series satisfies SOC 2 Type II change-management evidence, customer audit on AI usage, export-control compliance evidence, and EU AI Act Article 12 for high-risk deployments from a single pipeline. Book a technical deep dive at deepinspect.ai.