Kategorie: DevSecOps

Veröffentlicht am

AI Code Review Needs a Platform Contract: Governing Instructions, Network Access, and Runners

AI-assisted code review is moving beyond a simple product toggle. Once a reviewer can read repository instructions, execute setup steps, access networks, and run on different compute environments, it becomes part of the software delivery platform. That changes the governance question from “Should we enable AI review?” to “Under which versioned and auditable contract may it operate?”

GitHub’s latest Copilot code review improvements make that shift visible. Copilot code review can now read instructions from the pull request’s head branch, consume additional instruction formats such as REVIEW.md, GEMINI.md, and CLAUDE.md, execute custom setup steps, run behind a configurable firewall, and use runner settings that are independent from the Copilot cloud agent.

These capabilities can improve relevance and reduce false positives. They also expand the execution surface around every review. Enterprises should therefore treat the configuration as platform policy rather than scattered repository preferences.

The reviewer now has an execution environment

Traditional static analysis usually operates under a relatively fixed contract: a known rule set evaluates a defined artifact and emits deterministic results. An AI reviewer behaves differently. Its output depends on context, instructions, available tools, network access, and the environment in which it runs.

AI review can work in an enterprise, but model selection is only one part of the operating model.

Four control planes now shape the result:

  • Instruction policy: which repository files influence the review and who may change them.
  • Setup policy: which commands and dependencies prepare the review environment.
  • Network policy: which external destinations the reviewer may reach.
  • Runner policy: where the review executes and which identities, secrets, and internal resources are available there.

If these controls evolve independently, two repositories using the same AI reviewer can have very different security and quality properties. A platform contract makes those differences explicit.

Instructions are executable review policy

Reading custom instructions from the head branch is useful because teams can test review guidance before merging it. It also creates a trust-boundary question: a pull request can propose code changes and changes to the instructions used to review that code.

This is not inherently unsafe. Pull requests already modify workflows, build scripts, and policy files. The important point is that instruction files deserve comparable governance.

A practical enterprise baseline should:

  • define which instruction formats are supported and where they may live;
  • assign CODEOWNERS to organization-critical instruction and agent-skill paths;
  • require human review when a pull request changes both application code and reviewer policy;
  • separate mandatory organization guidance from repository-specific context;
  • test instruction changes against representative pull requests before broad rollout;
  • retain the exact instruction revision with review evidence where audit requirements justify it.

Product teams still need room for domain-specific guidance. The platform team should own the contract, validation, and protected baseline, while repository owners maintain local context within those boundaries.

Setup steps belong to the software supply chain

Custom setup steps can make reviews substantially better. A reviewer may need generated code, dependency metadata, project-specific linters, or a compiled schema before it can understand a change.

However, setup steps are code execution. They can download dependencies, run scripts from the branch, and interact with credentials exposed to the runner. Treating them as harmless customization would recreate risks that enterprises already learned to manage in CI/CD.

The platform contract should require:

  • minimal and explicit setup steps;
  • pinned versions or immutable references for downloaded tools and reusable actions;
  • dependency caching that does not weaken provenance checks;
  • timeouts and resource limits;
  • no production credentials in the review environment;
  • clear separation between untrusted pull-request code and trusted setup logic;
  • logs that show what ran without exposing secrets.

Where setup behavior is common across many repositories, publish a maintained golden path instead of copying shell fragments. Teams can then inherit a reviewed baseline and add only the repository-specific preparation they need.

Network access needs an exception model

GitHub states that Copilot code review now runs behind a firewall by default and that its network rules can be configured independently from the Copilot cloud agent. This is an important default because review tasks often need less network access than general-purpose coding agents.

The right enterprise pattern is deny by default with narrow, observable exceptions. Typical allowed destinations may include an internal package repository, a schema registry, or an approved documentation endpoint. General internet access should require a documented reason.

Every exception should answer four questions:

  1. Which destination is required?
  2. Which review capability depends on it?
  3. What data may leave the runner?
  4. Who owns and periodically revalidates the exception?

The current GitHub notice also matters operationally: self-hosted runners do not support the code-review firewall. Organizations using self-hosted runners therefore need compensating controls at the network, workload, or runner-pool level. “Self-hosted” should not be interpreted as “automatically safer.”

Runner selection is a data-boundary decision

Separating runner configuration for Copilot code review from the Copilot cloud agent allows enterprises to match infrastructure to the task. It also prevents an overly broad agent configuration from becoming the default for review workloads.

Runner policy should be based on data classification and required connectivity:

  • use isolated hosted runners when repositories need no private network access;
  • use hardened self-hosted pools only when internal dependencies make them necessary;
  • keep runner images minimal and reproducible;
  • use short-lived credentials with repository-scoped permissions;
  • prevent persistence between review jobs;
  • separate runner pools for different trust zones.

Runner selection affects far more than performance. It determines what source code, internal services, credentials, and telemetry the review process can reach.

A platform contract for AI code review

A useful contract should be small enough for teams to understand and strict enough for governance teams to trust. It can be implemented as policy-as-code, reusable repository configuration, protected settings, and automated conformance checks.

The contract should define at least:

  1. Purpose: AI review supplements human review and deterministic controls; it does not become an unmeasured release gate.
  2. Instruction ownership: approved formats, protected paths, and required reviewers.
  3. Execution policy: allowed setup operations, dependency provenance, resource limits, and secret handling.
  4. Egress policy: default network posture, approved destinations, and exception ownership.
  5. Runner policy: permitted runner classes by repository classification and connectivity need.
  6. Evidence: the configuration version, runner class, policy result, and operational outcome retained for each review where needed.
  7. Escalation: how developers report incorrect findings, missing context, or policy constraints that reduce review quality.

This contract should be versioned. A change to review instructions, setup behavior, firewall rules, or runner selection can alter both quality and risk. It deserves the same change-management discipline as a CI template or deployment policy.

Measure the operating model, not just adoption

Counting how many repositories enabled AI review says little about whether it works safely. Platform and engineering leaders need evidence across quality, reliability, and governance.

Useful measures include:

  • acceptance and dismissal rates for review findings;
  • time from finding to resolution;
  • setup-step failure and timeout rates;
  • repositories compliant with the approved runner and firewall baseline;
  • number and age of network exceptions;
  • frequency of instruction changes and their effect on finding quality;
  • cases where deterministic checks or human reviewers contradicted the AI reviewer.

These measures create a feedback loop. Teams can improve instructions and setup context while the platform team identifies systemic policy or reliability problems.

A pragmatic rollout sequence

Enterprises do not need to design the final governance model before gaining value. A controlled rollout can proceed in four steps:

  1. Inventory: identify existing instruction files, setup workflows, runner types, and network dependencies.
  2. Baseline: define one default contract with protected instructions, minimal setup, restricted egress, and an approved runner class.
  3. Pilot: onboard a representative set of repositories and measure finding quality, setup reliability, and exceptions.
  4. Scale: publish golden-path configuration, automate conformance checks, and review exceptions periodically.

This approach lets the organization learn without turning every repository into a separate governance experiment.

From feature configuration to delivery policy

GitHub’s new controls are useful because they expose the real shape of AI-assisted review: it is a configurable workload operating inside the delivery system. Instructions influence judgment. Setup steps execute code. Network rules define egress. Runners define the data boundary.

Enterprises now have to make this customization reviewable, reusable, and measurable.

Platform teams should provide the paved road: a versioned contract, secure defaults, approved extension points, and evidence that the reviewer operated within policy. Product teams should own the domain context that makes reviews useful. Security and engineering leadership should define the exceptions and success measures.

That division of responsibility allows AI code review to improve delivery quality without creating an invisible parallel control plane.

GitHub’s implementation details are described in the Copilot code review customization announcement, the code review environment documentation, the repository custom instructions guidance, and the firewall configuration guidance.

Veröffentlicht am

AI Security Findings in Pull Requests: Treat the Model as a Reviewer, Not a Release Gate

GitHub now surfaces AI-powered security detections directly in pull requests. The feature extends coverage to languages and frameworks that CodeQL does not currently support, including examples such as PHP, Shell, Terraform configuration, Dockerfiles, JSP, and Blazor.

That is useful coverage. It is not the same thing as a release control.

GitHub explicitly describes these findings as advisory. They are labeled as AI-generated, may contain false positives, appear only on pull requests, and cannot currently be used in rulesets to enforce merge requirements. The feature is also in public preview and its supported languages and detection categories may change.

Enterprise engineering organizations should preserve that distinction. Use the model as an additional security reviewer that broadens visibility. Keep release gates grounded in deterministic controls, validated policies, and accountable human decisions.

The value is coverage, not certainty

CodeQL provides high-precision static analysis for supported languages and queries. AI-powered security detections address a different problem: codebases contain languages, frameworks, infrastructure definitions, and integration patterns that deterministic analyzers may not cover.

GitHub’s AI engine analyzes changes when a pull request is opened or updated. It can use code search to gather repository context and reports findings as they become available. The results appear alongside CodeQL alerts but carry an AI label so reviewers can distinguish the evidence source.

This creates practical value in three areas:

  • Coverage expansion: teams receive security signals in previously unscanned parts of the repository.
  • Workflow placement: findings appear where developers already discuss and approve changes.
  • Contextual explanation: a finding includes a risk explanation and often a suggested remediation.

None of those benefits requires treating the model’s conclusion as an objective fact. The useful product is a prioritized question for the reviewer: Is this change unsafe, and what evidence confirms or rejects that assessment?

Why an AI finding should not become an automatic release gate

A release gate is an enforcement mechanism. When it fails, delivery stops. That makes consistency, explainability, availability, and predictable remediation essential operational properties.

AI-generated findings have different characteristics.

Model output is probabilistic

The same flexibility that lets a model reason across unfamiliar frameworks also introduces uncertainty. GitHub’s documentation acknowledges that findings may include false positives. A noisy blocking control creates alert fatigue, encourages bypasses, and can reduce trust in the entire security program.

The detection surface can evolve

The feature is in public preview. Detection categories and language coverage may change as the product evolves. A release policy tied directly to an evolving model can change effective enforcement without a corresponding policy review inside the enterprise.

Results are asynchronous

AI and CodeQL analysis run independently, and findings are posted as each engine returns them. A fast-moving pull request may therefore see one source before the other. A release process must define whether it waits, who evaluates late findings, and what happens when a result arrives after approval.

The product itself treats them as advisory

GitHub states that AI-powered findings do not block merges and cannot currently be used in rulesets for merge enforcement. Recreating an improvised hard gate around an advisory preview feature transfers the operational risk to the platform team without improving the underlying evidence quality.

The right conclusion is not to ignore AI findings. It is to design a decision process appropriate to their evidence class.

Build an explicit security evidence hierarchy

A mature pull-request policy should distinguish how a finding was produced and how much confidence the organization has earned in it.

Class 1: deterministic blocking controls

These controls have clear pass or fail semantics and an agreed relationship to release risk. Examples include required tests, policy-as-code checks, secret push protection, approved dependency rules, and configured code-scanning merge protection for validated analyzers and severities.

Failures block the merge because the organization has intentionally accepted the trade-off between delivery speed and risk reduction.

Class 2: deterministic advisory findings

Some scanner results are reliable but not severe enough to stop every change. They remain visible, receive an owner and service-level expectation, and may be promoted to blocking after the policy is validated.

Class 3: AI advisory findings

These are hypotheses that require triage. They should be labeled, routed, measured, and resolved with a documented outcome. They extend the reviewer’s attention but do not replace the reviewer’s judgment.

Class 4: confirmed risk decisions

Once a qualified reviewer confirms a material vulnerability, the decision is no longer merely a model output. The team can require remediation, accept the risk through an accountable exception, or stop the release under the existing security policy.

This hierarchy prevents a common category error: confusing the mechanism that discovered a concern with the governance decision that determines whether software may ship.

A practical pull-request operating model

The operating model should connect detection, triage, decision, and learning without creating a parallel workflow outside the pull request.

1. Preserve the source label

Do not normalize every result into a generic „security failed“ status. Keep the AI indicator and record the detection source, category, repository, language, commit, and time. Reviewers need to know whether they are evaluating a deterministic query, a model-generated hypothesis, or a human-confirmed issue.

2. Route by risk context

Not every repository needs the same handling. Use repository criticality, data classification, deployment target, and change ownership to determine the triage path.

  • A low-risk internal tool may let the author resolve the finding with peer review.
  • A customer-facing service may require a security champion for high-impact categories.
  • An identity, payment, or production-control component may require application-security review before approval.

The model can suggest severity, but enterprise routing should also use deterministic context the organization owns.

3. Require a recorded disposition

Each material finding should end with one of a small number of outcomes:

  • confirmed and fixed;
  • confirmed and accepted through the risk process;
  • false positive with a short technical rationale;
  • duplicate of an existing issue;
  • deferred to a tracked remediation item.

A thumbs-up or thumbs-down signal can help improve detection quality, but the enterprise also needs its own auditable disposition when the finding influenced a release decision.

4. Keep enforcement in the existing control plane

Use branch rulesets, required status checks, approval requirements, and policy-as-code for actual merge protection. If a confirmed AI finding should stop a release, translate that human decision into an existing accountable control rather than letting an unreviewed model response become the gate.

5. Handle late findings deliberately

Because results can arrive asynchronously, define a policy for high-risk repositories. Options include a minimum review stage, a named security owner, or post-merge follow-up when an advisory result arrives after approval. The policy should reflect system criticality instead of imposing the same delay on every repository.

Measure detection quality before changing policy

AI security coverage should be managed as an evidence-producing service. Usage counts alone do not show whether it reduces risk.

Track at least:

  • findings by repository, language, framework, and category;
  • confirmed findings and false-positive dispositions;
  • time from finding to first triage and final resolution;
  • findings fixed before merge versus deferred or accepted;
  • late findings that arrived after approval or merge;
  • repeat findings for the same weakness or component;
  • review effort per confirmed vulnerability;
  • AI credit consumption per run and per confirmed finding;
  • developer feedback and bypass behavior.

Precision is especially important for workflow trust: of the findings reviewed, how many were confirmed? Recall is harder because the organization does not automatically know what the model missed. Periodic expert review, penetration tests, incident data, and comparison with other scanners can provide partial evidence.

Do not create an arbitrary global threshold and call the model „validated.“ Quality can differ by language, repository pattern, and vulnerability category. Evaluate the segments that matter to your environment.

Promote patterns, not raw model confidence

If repeated AI findings reveal a reliable class of defects, the long-term goal should be to convert that learning into a deterministic control where possible.

For example:

  • Add a CodeQL query or another static-analysis rule for a recurring unsafe pattern.
  • Create a policy-as-code rule for an insecure infrastructure configuration.
  • Improve a secure library or platform template so teams avoid the defect by default.
  • Add a focused test to the affected component.
  • Update a golden path, coding standard, or reviewer checklist.

This is how AI improves the release system without becoming its single point of judgment. The model discovers weak signals; the platform team turns proven patterns into repeatable controls.

Govern the feature as an enterprise capability

GitHub requires enterprise policy permission, organization-level opt-in, CodeQL default setup, GitHub Advanced Security, and during public preview a GitHub Copilot license. Runs also consume AI credits.

That makes enablement a portfolio decision, not merely a repository toggle.

Enterprise owners should define:

  • which organizations and repository classes may use the feature;
  • who owns configuration, cost, triage policy, and support;
  • which repositories provide the initial evaluation cohort;
  • how findings and dispositions are retained for audit purposes;
  • how credit consumption is budgeted and attributed;
  • how product-preview changes are reviewed before broader rollout;
  • how teams report harmful noise, gaps, or inconsistent behavior.

Platform engineering, application security, developer experience, and service owners all have a role. Security defines risk policy. Platform engineering integrates the workflow and evidence. Developer experience monitors friction. Service owners remain accountable for the code they merge.

A staged rollout plan

Phase 1: baseline

Document existing CodeQL coverage, merge protection, security-review responsibilities, and unsupported languages. Keep current release gates unchanged.

Phase 2: advisory pilot

Enable AI detections for a representative set of repositories with meaningful coverage gaps. Train reviewers to distinguish AI findings from CodeQL alerts and require a simple disposition for reviewed findings.

Phase 3: measure and tune

Review confirmed findings, false positives, triage time, late results, developer effort, and AI credit consumption. Segment the results by language and finding category.

Phase 4: institutionalize learning

Turn recurring confirmed patterns into deterministic queries, tests, policies, secure defaults, or platform templates. Define escalation paths for categories that consistently indicate material risk.

Phase 5: expand with evidence

Extend the feature to additional repository classes only when the organization can support the triage load and demonstrate useful detection quality. Reassess the operating model as the public-preview capability changes.

The model reviews; the organization decides

AI-powered security detections can close meaningful coverage gaps and bring more security context into the pull request. Their value is strongest when they broaden human attention and feed continuous improvement.

A release gate carries a different responsibility. It must represent an explicit, accountable policy backed by evidence the organization understands and can operate reliably.

Treat the model as a security reviewer. Measure its findings. Confirm the risk. Convert repeatable lessons into deterministic controls. Then let people and policy decide whether the software is ready to ship.

Sources

Veröffentlicht am

MCP Security: Securing the Model Context Protocol for Enterprise AI Agents

The Model Context Protocol (MCP) has rapidly become the de facto standard for connecting AI agents to enterprise systems. Originally developed by Anthropic and released in November 2024, MCP provides a standardized interface for AI models to interact with databases, APIs, file systems, and external services. It’s the protocol that powers Claude’s ability to read your files, query your databases, and execute tools on your behalf.

But with adoption accelerating—Gartner predicts 40% of enterprise applications will integrate MCP servers by end of 2026—security researchers are discovering critical vulnerabilities that could turn your helpful AI assistant into a gateway for attackers.

The Protocol That Connects Everything

MCP works by establishing a client-server architecture where AI models (the clients) connect to MCP servers that expose „tools“ and „resources.“ When you ask Claude to read a file or query a database, it’s making MCP calls to servers that have been granted access to those systems.

The protocol is elegant in its simplicity: JSON-RPC messages over standard transports (stdio, HTTP, WebSocket). But this simplicity also means that a single compromised MCP server can potentially access everything it’s been granted permission to touch.

Consider a typical enterprise setup: an MCP server connected to your GitHub repositories, another to your production database, a third to your internal documentation. Each server aggregates credentials and access tokens. An attacker who compromises one server doesn’t just get access to that service—they get access to the aggregated credentials that service holds.

Recent CVEs: A Wake-Up Call

The first quarter of 2026 has already seen two critical CVEs in official MCP SDK implementations:

CVE-2026-34742 (CVSS 8.1) affects the official Go SDK. A DNS rebinding vulnerability allows attackers to bypass localhost restrictions by resolving to 127.0.0.1 after initial CORS checks pass. This means a malicious website could potentially interact with MCP servers running on a developer’s machine, even when those servers are configured to only accept local connections.

CVE-2026-34237 (CVSS 7.5) in the Java SDK involves improper CORS wildcard handling. The SDK accepted overly permissive origin configurations that could be exploited to bypass same-origin protections, potentially allowing cross-site request forgery against MCP endpoints.

These aren’t theoretical vulnerabilities—they’re implementation bugs in the official SDKs that thousands of developers use to build MCP integrations. The patches are available, but how many custom MCP servers in production environments are still running vulnerable versions?

Attack Vectors Unique to MCP

Beyond SDK vulnerabilities, MCP introduces new attack surfaces that security teams need to understand:

Tool Poisoning and Rug Pulls

MCP’s tool discovery mechanism allows servers to dynamically advertise available tools. A compromised server can change its tool definitions at runtime—a „rug pull“ attack. Your AI agent thinks it’s calling read_file, but the server has silently replaced it with a tool that exfiltrates data before returning results.

More subtle: tool descriptions influence how AI models use them. A malicious server could manipulate descriptions to guide the AI toward dangerous actions. „Use this tool for all sensitive operations“ could be embedded in a description, influencing the model’s behavior without changing the tool’s apparent functionality.

The Confused Deputy Problem

AI agents operate with the combined permissions of their MCP connections. When an agent uses multiple tools in sequence, it can inadvertently transfer data between contexts in ways that violate security boundaries.

Example: A user asks an AI to „summarize the Q1 financials and post a summary to Slack.“ The agent reads confidential data from a financial database (MCP server A) and posts it to a public channel (MCP server B). Neither MCP server violated its permissions—but the agent performed an unauthorized data transfer.

Shadow AI via Uncontrolled MCP Servers

Developers love convenience. When official MCP integrations are locked down by IT, they’ll spin up their own servers on localhost. These shadow MCP servers often have overly permissive configurations, skip authentication entirely, and connect to production systems using personal credentials.

The result: an invisible attack surface that security teams can’t monitor because they don’t know it exists.

Defense in Depth: Securing MCP Deployments

Authentication: OAuth 2.1 with PKCE

MCP’s transport layer supports OAuth 2.1, but many deployments still rely on API keys or skip authentication for „internal“ servers. This is insufficient.

Implement OAuth 2.1 with PKCE (Proof Key for Code Exchange) for all MCP connections, even internal ones. PKCE prevents authorization code interception attacks that could allow attackers to hijack MCP sessions.

# Example MCP server configuration
auth:
  type: oauth2
  issuer: https://auth.company.com
  client_id: mcp-database-server
  pkce: required
  scopes:
    - mcp:tools:read
    - mcp:tools:execute

Every MCP server should validate tokens on every request—don’t cache authentication decisions.

Centralized MCP Gateways

Rather than allowing AI agents to connect directly to MCP servers, route all traffic through a centralized gateway. This provides several security benefits:

Traffic visibility: Log every tool call, including parameters and results. This audit trail is essential for detecting anomalies and investigating incidents.

Policy enforcement: Implement fine-grained access controls that go beyond what individual MCP servers support. Block specific tool calls based on user identity, time of day, or risk scoring.

Rate limiting: Prevent credential stuffing and abuse by throttling requests at the gateway level.

This pattern mirrors what we discussed in our AI Gateways post—the same architectural principles apply. Products like Aurascape, TrueFoundry, and Bifrost are beginning to offer MCP-specific gateway capabilities.

Behavioral Analysis for Anomaly Detection

MCP call patterns are highly predictable for legitimate use cases. A developer’s AI assistant will typically make similar calls day after day: reading code files, querying documentation, creating pull requests.

Sudden changes in behavior—a new tool being called for the first time, unusual data volumes, calls at unexpected hours—should trigger alerts. This is where AI can help secure AI: use machine learning models to baseline normal MCP activity and flag deviations.

Key signals to monitor:

  • First-time tool usage by an established user
  • Data volume anomalies (reading entire databases vs. specific records)
  • Tool call sequences that don’t match known workflows
  • Geographic or temporal anomalies in API calls

Supply Chain Validation

Many organizations install MCP servers from package managers (npm, pip) without verifying integrity. The LiteLLM supply chain attack in March 2026 demonstrated how a compromised package could inject malicious code into AI infrastructure.

For MCP servers:

  1. Pin specific versions in your dependency files
  2. Verify package signatures where available
  3. Scan MCP server code for malicious patterns before deployment
  4. Maintain an inventory of all MCP servers and their versions
  5. Subscribe to security advisories for SDKs you use

Principle of Least Privilege

Each MCP server should have the minimum permissions necessary for its function. This seems obvious, but the convenience of MCP makes it tempting to create „god servers“ that can access everything.

Instead:

  • Create separate MCP servers for different data classifications
  • Use short-lived credentials that are rotated frequently
  • Implement time-based access windows where possible
  • Regularly audit and revoke unused permissions

The Path Forward

MCP is too useful to avoid. The productivity gains from giving AI agents structured access to enterprise systems are substantial. But we’re in the early days of understanding MCP’s security implications.

The organizations that will thrive are those that treat MCP security as a first-class concern from day one. Don’t wait for a breach to implement proper authentication, monitoring, and access controls.

Start here:

  1. Inventory: Know every MCP server in your environment, official and shadow
  2. Authenticate: Deploy OAuth 2.1 with PKCE for all MCP connections
  3. Monitor: Route MCP traffic through a centralized gateway with logging
  4. Validate: Implement supply chain security for MCP server dependencies
  5. Limit: Apply least-privilege principles to every MCP server’s permissions

The Model Context Protocol represents a fundamental shift in how AI agents interact with enterprise infrastructure. Getting security right now—while the ecosystem is still maturing—is far easier than retrofitting it later.

This post builds on our earlier exploration of AI Gateways. For more on protecting AI infrastructure, see our series on Guardrails for Agentic Systems and Non-Human Identity.