Kategorie: AI Security

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

The Agent Egress Boundary: Making Every AI Tool Call Enforceable and Observable

AI agents do not create risk only when they generate the wrong answer. They create operational risk when they turn that answer into an outbound action: calling an API, querying a search service, downloading content, opening a ticket, sending a message, or changing a production system.

Most enterprise controls still focus on the agent’s intent. Prompts, guardrails, and model policies describe what the agent should do. They do not guarantee which destinations the workload can reach, which request was sent, or whether an unapproved path was used.

That gap calls for an agent egress boundary: a platform-enforced control through which every external tool call must pass, combined with traceable evidence that links the call to the originating agent interaction.

Guardrails are necessary, but they are not enforcement

Prompt-level guardrails are useful for shaping behavior. They can tell an agent not to disclose sensitive information, not to call unknown services, or to request human approval before a consequential action. But those controls operate inside the reasoning path they are intended to constrain.

Production systems need an independent layer. If an agent is compromised through prompt injection, a poisoned tool response, a vulnerable dependency, or a simple implementation mistake, the network should still prevent access to destinations outside the approved contract.

The distinction is familiar from other areas of security:

  • application authorization expresses intended access;
  • network enforcement limits reachable destinations;
  • observability records what actually happened;
  • human approval controls high-impact exceptions.

No single layer is sufficient. Together, they create defense in depth.

The platform contract

An agent egress boundary should answer four questions for every outbound request:

  1. Who initiated it? Identify the workload, agent, tenant, and user or workflow context.
  2. Where is it going? Resolve the approved destination, protocol, port, and application-level route.
  3. Was it allowed? Evaluate the call against a versioned policy rather than an application convention.
  4. What evidence remains? Record a traceable decision without leaking secrets or sensitive payloads.

This turns outbound connectivity into a platform contract. An agent receives only the network access required by its tools, while the platform provides a consistent control and evidence plane.

A practical cloud-native pattern

A recent CNCF implementation demonstrates the core idea using NGINX, Kubernetes, and OpenTelemetry. NGINX acts as both the inbound reverse proxy and the outbound forward proxy for an agent workload. Network rules drop direct egress so the proxy becomes the only approved path. The NGINX OpenTelemetry module emits a span for each request, and an OpenTelemetry Collector forwards the evidence to observability or security systems.

The important principle is architectural: the boundary is not a library the agent may choose to call. It is the only network path available.

A production-oriented request flow can look like this:

  1. A user or system invokes the agent through an authenticated gateway.
  2. The gateway propagates a trace context and workload identity.
  3. The agent selects a tool and issues an outbound request.
  4. Kubernetes egress controls permit traffic only to the designated proxy.
  5. The proxy evaluates destination, protocol, identity, and policy.
  6. Allowed traffic is forwarded; denied traffic returns a controlled error.
  7. OpenTelemetry records the decision and correlates it with the originating interaction.

The result is a chain of evidence from user request to external side effect.

Why Kubernetes NetworkPolicy alone is not enough

Kubernetes NetworkPolicy is a strong foundation. It can isolate workloads and restrict egress by IP block, port, and selected peers, provided the cluster’s network plugin enforces the policy. A default-deny egress policy should be the starting point for sensitive agent workloads.

However, many agent tools call dynamic external services over HTTPS. IP addresses change, destinations share infrastructure, and business rules are usually expressed in terms of domains, API routes, methods, or tool identities rather than static addresses.

That is why a layered design is useful:

  • NetworkPolicy or equivalent CNI controls ensure the workload can only reach the approved proxy and essential platform services.
  • The egress proxy enforces destination and application-aware rules.
  • Workload identity distinguishes agents and tenants without relying only on source IP.
  • OpenTelemetry provides correlated evidence for operations, security, and audit.

The network layer prevents bypass. The proxy layer understands enough context to make a useful decision.

Policy should follow the tool contract

Allowing an agent to reach an entire domain is often broader than the tool definition requires. A better policy starts with the declared tool contract.

For example, an incident-analysis agent may need to:

  • read selected observability APIs;
  • create, but not delete, incident tickets;
  • query a controlled knowledge source;
  • send notifications only to an approved channel;
  • never call arbitrary internet destinations.

The platform can translate that contract into an egress policy covering destination, method, route, identity, rate, and approval requirements. High-risk actions can be routed through a separate approval service rather than granted as normal network access.

This also creates a cleaner ownership model. Domain teams define which tools are necessary. Security teams define control requirements. Platform teams provide the reusable enforcement mechanism.

Observability must produce evidence, not surveillance

OpenTelemetry is well suited to correlating inbound interactions with outbound HTTP client activity. Standard HTTP span conventions provide consistent attributes for requests and responses, while trace context links multiple services into one transaction.

But recording everything is not automatically safe. Agent traffic can include credentials, personal data, customer information, prompts, and tool payloads. The audit plane therefore needs its own policy.

Useful evidence

  • trace and request identifiers;
  • agent, workload, tenant, and tool identity;
  • policy version and allow or deny decision;
  • destination service and approved route classification;
  • HTTP method and status class;
  • latency, retries, and byte counts;
  • model or agent configuration version;
  • human approval reference where required.

Data to avoid by default

  • authorization headers and API keys;
  • full request or response bodies;
  • raw prompts containing confidential data;
  • URL query parameters unless explicitly sanitized;
  • unbounded high-cardinality attributes.

The purpose is to prove and investigate behavior, not to create a second uncontrolled copy of sensitive data.

Controls that make the boundary credible

A proxy is only a boundary when bypass is demonstrably difficult. Platform teams should validate at least the following controls:

  • Default-deny egress: direct external connectivity fails.
  • DNS control: workloads cannot switch to an unmonitored resolver or exploit unexpected resolution paths.
  • IPv4 and IPv6 parity: policy applies consistently to both address families.
  • Protocol coverage: non-HTTP tools, WebSockets, streaming APIs, and message protocols have explicit handling.
  • TLS design: the organization decides where TLS terminates and what metadata can be inspected without undermining privacy.
  • Identity: decisions rely on authenticated workload identity, not only mutable labels or network location.
  • Fail-closed behavior: proxy, collector, or policy failures do not silently open direct access.
  • High availability: the control plane does not become an avoidable single point of failure.

These details determine whether the pattern is an architectural control or merely a useful demonstration.

Operational signals for platform teams

Once all tool traffic crosses the boundary, the same telemetry can improve reliability and cost control.

Useful service-level indicators include:

  • allowed and denied tool calls by agent and policy version;
  • unexpected destinations or repeated policy violations;
  • external dependency latency and error rates;
  • retry storms and rate-limit responses;
  • egress volume and estimated third-party API cost;
  • calls that required human approval;
  • trace gaps where an outbound action lacks an originating interaction.

This gives security and operations teams a shared view. The same denied request may indicate an attack, an outdated policy, or a legitimate new tool requirement.

A phased adoption plan

  1. Inventory agent egress. Identify destinations, protocols, credentials, and business owners for each production tool.
  2. Introduce observation first. Capture sanitized outbound traces to understand real behavior before enforcing a narrow policy.
  3. Define tool-level contracts. Document approved destinations and actions rather than granting general internet access.
  4. Apply default deny. Force a low-risk agent through the proxy and prove that direct egress fails.
  5. Add policy-as-code. Version destination rules, ownership, exceptions, and approval conditions in Git.
  6. Connect the audit plane. Send sanitized OpenTelemetry data to the organization’s observability and SIEM platforms.
  7. Test failure modes. Validate DNS bypass, IPv6, proxy outage, collector outage, policy rollback, and certificate rotation.
  8. Scale by platform product. Offer the boundary as a reusable golden-path capability rather than a custom design for every agent.

Conclusion

Enterprises should not have to trust that an AI agent will respect its network boundaries. Those boundaries should be enforced by the platform and evidenced through telemetry.

NGINX, Kubernetes, and OpenTelemetry show that the core pattern can be built from mature cloud-native components: default-deny connectivity, an application-aware egress proxy, and correlated traces. The exact implementation will vary, but the platform contract should remain consistent.

Every agent tool call should be attributable, policy-checked, observable, and reversible where the downstream system allows it. That is the difference between experimenting with autonomous software and operating it responsibly.

Sources and further reading

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.