Monat: April 2026

Veröffentlicht am

The Vercel Breach Playbook: What Platform Teams Must Do When Their PaaS Provider Gets Compromised

Today — April 19, 2026 — Vercel disclosed a security incident involving unauthorized access to its internal systems. The breach has been linked to the ShinyHunters group, a threat actor known for targeting SaaS platforms via social engineering and vulnerability exploitation. Vercel says a „limited subset of customers“ was impacted and recommends reviewing environment variables — particularly urging use of their Sensitive Environment Variable feature.

If you’re a platform engineer running production workloads on Vercel, this is your signal to act. Not tomorrow. Now.

But this post isn’t just about Vercel. It’s about what every platform team should do when the infrastructure they trust gets compromised — because this has happened before, and it will happen again.

We’ve Been Here Before

The Vercel breach follows a pattern that platform teams should recognize by now:

  • CircleCI (January 2023) — An engineer’s laptop was compromised, giving attackers access to customer environment variables, tokens, and keys. CircleCI’s guidance was unambiguous: rotate every secret, immediately. Teams that delayed paid the price.
  • Codecov (April 2021) — Attackers modified Codecov’s Bash Uploader script, exfiltrating environment variables from CI pipelines for two months before detection. Thousands of repositories had their credentials silently harvested.
  • Travis CI (September 2021) — A vulnerability exposed secrets from public repositories, including signing keys and access tokens. The scope was enormous because the trust boundary had been quietly violated for years.

The common thread: environment variables are the crown jewels, and PaaS providers are the vault. When the vault gets cracked, every secret inside is potentially compromised.

The Shared Responsibility Blind Spot

Most teams understand the shared responsibility model for IaaS — you secure your workloads, AWS secures the hypervisor. But with PaaS providers like Vercel, Netlify, or Railway, the trust boundary is far murkier.

Consider what Vercel has access to in a typical deployment:

  • Your source code (pulled from Git during builds)
  • Every environment variable you’ve configured — database URLs, API keys, signing secrets
  • Build-time and runtime secrets
  • Deployment metadata and audit logs
  • DNS configuration and SSL certificates

When Vercel’s internal systems are breached, all of these become part of the blast radius. You didn’t misconfigure anything. You didn’t leak a credential. Your provider’s security posture became your security posture.

This is the platform trust boundary problem: the more convenience your PaaS offers, the more implicit trust you’ve delegated.

Immediate Response: The First 24 Hours

If you’re running on Vercel right now, here’s the checklist. Don’t wait for their investigation to conclude — assume the worst and work backward.

1. Audit Your Environment Variables

Vercel’s own advisory specifically calls out environment variables. Start here:

# List all Vercel projects and their env vars
vercel env ls --environment production
vercel env ls --environment preview
vercel env ls --environment development

Or use the consolidated environment variables page Vercel provides. Document every secret. You need to know what’s potentially exposed before you can rotate.

2. Rotate Every Secret — No Exceptions

This is the lesson from CircleCI: partial rotation is no rotation. If a secret was accessible to your PaaS provider, treat it as compromised.

  • Database credentials (connection strings, passwords)
  • API keys (Stripe, Twilio, SendGrid, any third-party service)
  • OAuth client secrets
  • JWT signing keys
  • Webhook secrets
  • Encryption keys

Prioritize by blast radius: payment processing keys and database credentials first, monitoring API keys last.

3. Review Deployment History

Check for unauthorized deployments or unexpected build activity:

# Review recent deployments via Vercel CLI
vercel ls --limit 50

# Check for deployments from unexpected branches or commits
vercel inspect <deployment-url>

Look for deployments that don’t correlate with your Git history. An attacker with access to Vercel’s internals could potentially trigger builds with modified environment variables or injected build steps.

4. Revoke and Regenerate Tokens

Beyond environment variables, rotate all integration tokens:

  • Vercel API tokens (personal and team)
  • Git integration tokens (GitHub/GitLab app installations)
  • Any webhook endpoints that use shared secrets for verification
  • CI/CD integration tokens that connect to Vercel

5. Check Downstream Systems

If your database credentials were in Vercel env vars, check your database audit logs for unusual access patterns. If your AWS keys were stored there, review CloudTrail. Every secret that was in Vercel is a thread to pull.

Stop Storing Secrets in Environment Variables

The deeper lesson here is architectural. Environment variables are the de facto standard for passing configuration to applications — but they were never designed as a secrets management system. They’re plaintext, they get logged, they get copied into build caches, and they’re only as secure as the system storing them.

External Secrets Operator

If you’re running Kubernetes workloads (even alongside a PaaS), the External Secrets Operator lets you reference secrets from external stores without ever putting them in your deployment platform:

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: database-credentials
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: vault-backend
    kind: ClusterSecretStore
  target:
    name: db-creds
  data:
    - secretKey: password
      remoteRef:
        key: secret/data/production/database
        property: password

The secret lives in Vault or AWS Secrets Manager. Your PaaS never sees it. If the PaaS is breached, the secret isn’t in the blast radius.

HashiCorp Vault with Dynamic Secrets

Even better: don’t store long-lived credentials at all. Vault’s dynamic secrets generate short-lived database credentials on demand:

# Application requests temporary database credentials at startup
vault read database/creds/my-role
# Returns credentials valid for 1 hour
# Automatically revoked after TTL expires

When your PaaS is breached, there’s nothing useful to steal — the credentials expired hours ago.

CI/CD Credential Hygiene: Kill the Static Tokens

Static API keys and long-lived tokens are the gift that keeps giving — to attackers. Every major PaaS breach has involved harvesting static credentials. The fix is structural.

OIDC Federation: Identity Without Secrets

Instead of storing cloud provider credentials in your CI/CD platform, use OIDC federation. Your pipeline proves its identity to the cloud provider directly, receiving short-lived tokens that can’t be stolen from the PaaS:

# GitHub Actions example — no AWS keys stored anywhere
- uses: aws-actions/configure-aws-credentials@v4
  with:
    role-to-assume: arn:aws:iam::123456789:role/deploy-role
    aws-region: eu-central-1
    # No access-key-id or secret-access-key needed
    # GitHub's OIDC token proves the workflow's identity

All major cloud providers support OIDC federation from GitHub Actions, GitLab CI, and most CI/CD platforms. There is no good reason to store static cloud credentials in your PaaS in 2026.

Workload Identity and SPIFFE7.

For more complex deployments, SPIFFE (Secure Production Identity Framework for Everyone) and its reference implementation SPIRE provide cryptographic identity attestation for workloads. Every workload gets a verifiable identity (SVID) without static credentials, and identity is attested based on the workload’s environment — not a secret that can be exfiltrated.

This is zero-trust for deployment pipelines: trust is established through verifiable identity, not shared secrets.

SBOM and Provenance: Know What You Shipped

When your build platform is compromised, one critical question emerges: can you prove that what’s running in production is what you intended to ship?

Build provenance — cryptographic attestations that link a deployed artifact to its source code, build parameters, and builder identity — becomes essential during incident response:

# Verify build provenance with cosign
cosign verify-attestation \
  --type slsaprovenance \
  --certificate-identity builder@your-org.iam.gserviceaccount.com \
  --certificate-oidc-issuer https://accounts.google.com \
  ghcr.io/your-org/your-app:latest

If you maintain SBOMs (Software Bills of Materials) and SLSA provenance attestations, you can forensically verify whether a compromised build platform injected anything into your artifacts. Without them, you’re flying blind.

Long-Term: Multi-Provider Resilience

The uncomfortable truth is that every PaaS provider will eventually have a security incident. The question isn’t if — it’s whether your architecture limits the blast radius when it happens.

Reduce Single Points of Trust

  • Secrets in an external vault, not in the PaaS — Vault, AWS Secrets Manager, Azure Key Vault
  • Build artifacts signed independently — don’t rely on the build platform’s integrity alone
  • DNS and TLS managed separately — if your PaaS controls your DNS, a breach can redirect traffic
  • Audit logs forwarded in real-time — ship PaaS audit logs to your own SIEM before the provider can tamper with them

Portable Deployments

If your deployment is tightly coupled to a single PaaS, you can’t move quickly during an incident. Containerized workloads with Infrastructure-as-Code configuration give you the option to shift to another platform within hours, not weeks. You don’t need to be multi-cloud on day one — but you need the capability to move when the trust relationship breaks.

The Incident Response Checklist

Pin this somewhere visible. When your next PaaS breach notification lands in your inbox:

Timeframe Action
0-1 hours Inventory all secrets stored in the provider. Begin rotating critical credentials (database, payment, auth).
1-4 hours Revoke all API tokens and integration credentials. Review deployment history for anomalies.
4-12 hours Complete rotation of all remaining secrets. Check downstream system audit logs. Verify build artifact integrity.
12-24 hours Confirm no unauthorized deployments occurred. Brief stakeholders. Document timeline.
1-7 days Conduct full post-incident review. Implement architectural improvements (external secrets, OIDC federation). Update runbooks.

Trust, but Architect for Betrayal

The Vercel breach is a reminder that platform trust is borrowed, not owned. Every convenience a PaaS provides — environment variable storage, built-in secrets, managed DNS — is a trust delegation that becomes a liability during a breach.

The platforms you depend on will get compromised. The question is whether you’ve architected your systems so that a provider breach is a inconvenience you handle in hours — or a catastrophe that takes weeks to untangle.

Start rotating your secrets now. Then start building the architecture that means you won’t have to do it so urgently next time.

Veröffentlicht am

Dapr Agents v1.0: Resilient Multi-Agent Orchestration on Kubernetes

The Distributed Systems Foundation for AI Agents

When LangGraph introduced stateful agents and CrewAI popularized role-based collaboration, they solved the what of multi-agent AI systems. But as organizations move from demos to production, a critical question emerges: how do you run these systems reliably at scale?

Enter Dapr Agents, which reached v1.0 GA in March 2026. Built on the battle-tested Dapr runtime—a CNCF graduated project—this Python framework takes a fundamentally different approach: instead of bolting reliability onto AI frameworks, it brings AI agents to proven distributed systems primitives.

The result? AI agents that inherit decades of distributed systems wisdom: durable execution, exactly-once semantics, automatic retries, and the ability to survive node failures without losing state.

Why Traditional Agent Frameworks Struggle in Production

Most AI agent frameworks were designed for prototyping. They work brilliantly in Jupyter notebooks but encounter friction when deployed to Kubernetes:

  • State Loss on Restart: LangGraph checkpoints require manual persistence configuration. A pod restart can lose agent memory mid-conversation.
  • No Native Retry Semantics: When an LLM API returns a 429, most frameworks fail or require custom retry logic.
  • Coordination Complexity: Multi-agent communication typically requires custom message queues or REST endpoints.
  • Observability Gaps: Tracing an agent’s reasoning across multiple tool calls often means stitching together fragmented logs.

Dapr Agents addresses each of these by standing on the shoulders of infrastructure patterns that have been production-hardened since the early days of microservices.

Architecture: Agents as Distributed Actors

At its core, Dapr Agents builds on three Dapr building blocks:

1. Workflows for Durable Execution

Every agent interaction—LLM calls, tool invocations, state updates—is persisted as a workflow step. If the agent crashes mid-reasoning, it resumes exactly where it left off:

from dapr_agents import DurableAgent, tool

class ResearchAgent(DurableAgent):
    @tool
    def search_arxiv(self, query: str) -> list:
        return arxiv_client.search(query)
    
    async def research(self, topic: str):
        papers = await self.search_arxiv(topic)
        summary = await self.llm.summarize(papers)
        return summary

Under the hood, Dapr Workflows use the Virtual Actor model—the same pattern that powers Orleans and Akka. Each agent is a stateful actor that can be deactivated when idle and reactivated on demand, enabling thousands of agents to run on a single node.

2. Pub/Sub for Event-Driven Coordination

Multi-agent systems need reliable communication. Dapr’s Pub/Sub abstraction lets agents publish events and subscribe to topics without knowing about the underlying message broker:

from dapr_agents import AgentRunner

await agent_a.publish("research-complete", {
    "topic": "quantum computing",
    "findings": summary
})

@runner.subscribe("research-complete")
async def handle_research(event):
    await writer_agent.draft_article(event["findings"])

Swap Redis for Kafka or RabbitMQ without changing agent code.

3. State Management for Agent Memory

Conversation history, tool results, reasoning traces—all flow through Dapr’s State API with pluggable backends:

from dapr_agents import memory

agent = ResearchAgent(memory=memory.InMemory())

agent = ResearchAgent(
    memory=memory.PostgreSQL(
        connection_string=os.environ["PG_CONN"],
        enable_vector_search=True
    )
)

Agentic Patterns Out of the Box

Dapr Agents ships with implementations of common multi-agent patterns:

Pattern Description Use Case
Prompt Chaining Sequential LLM calls where each output feeds the next Document processing
Evaluator-Optimizer One LLM generates, another critiques in a loop Code review
Parallelization Fan-out work to multiple agents, aggregate results Research synthesis
Routing Classify input and delegate to specialist agents Customer support
Orchestrator-Workers Central coordinator delegates subtasks dynamically Complex workflows

MCP and Cross-Framework Interoperability

A standout feature is native support for the Model Context Protocol (MCP):

from dapr_agents import MCPToolProvider

tools = MCPToolProvider("http://mcp-server:8080")
agent = DurableAgent(tools=[tools])

Dapr Agents can also invoke agents from other frameworks as tools:

from dapr_agents.interop import CrewAITool

research_crew = CrewAITool(crew=research_crew, name="research_team")
coordinator = DurableAgent(tools=[research_crew])

Kubernetes-Native Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: research-agent
  annotations:
    dapr.io/enabled: "true"
    dapr.io/app-id: "research-agent"
spec:
  replicas: 3
  template:
    spec:
      containers:
      - name: agent
        image: myregistry/research-agent:v1

Comparison: Dapr Agents vs. LangGraph vs. CrewAI

Capability Dapr Agents LangGraph CrewAI
Durable Execution Built-in Requires config Limited
Auto Retry Built-in Manual Manual
State Persistence 50+ backends SQLite, PG In-memory
Kubernetes Native Sidecar Manual Manual
Observability OpenTelemetry LangSmith Limited

When to Choose Dapr Agents

Dapr Agents makes sense when:

  • You’re already running Dapr for microservices
  • Your agents must survive node failures without state loss
  • You need to scale to thousands of concurrent agents
  • Enterprise observability requirements demand OpenTelemetry

Getting Started

pip install dapr-agents
dapr init

from dapr_agents import DurableAgent, AgentRunner

class GreeterAgent(DurableAgent):
    system_prompt = "You are a helpful assistant."

runner = AgentRunner(agent=GreeterAgent())
runner.start()

The Bigger Picture

Dapr Agents represents a broader trend: AI frameworks are maturing from „make it work“ to „make it work reliably.“ The CNCF ecosystem is converging on this need—KubeCon 2026 showcased kagent, AgentGateway, and the AI Gateway Working Group.

For platform teams, Dapr Agents offers a familiar operational model: sidecars, state stores, message brokers, and observability pipelines. The agents are new; the infrastructure patterns are proven.

Dapr Agents v1.0 is available now at github.com/dapr/dapr-agents.

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.

Veröffentlicht am

AI Gateways: The Security Control Plane for Enterprise LLM Operations

## The LiteLLM Wake-Up Call

On March 24, 2026, LiteLLM—a Python library with 3 million daily downloads powering AI integrations across tools like CrewAI, DSPy, Browser-Use, and Cursor—was compromised in a supply chain attack. Malicious versions 1.82.7 and 1.82.8 silently exfiltrated API keys, SSH credentials, AWS secrets, and crypto wallets from anyone with LiteLLM as a direct or transitive dependency.

The attack was detected within three hours, reportedly after a developer’s laptop crash exposed the breach. But for those three hours, millions of developers were vulnerable—not because they did anything wrong, but because they trusted their dependencies.

This incident crystallizes a fundamental truth about enterprise AI operations: the infrastructure layer between your applications and LLM providers is now a critical attack surface. And that’s exactly where AI Gateways come in.

## What Is an AI Gateway?

An AI Gateway is a reverse proxy that sits between your applications (or AI agents) and LLM providers. Think of it as an API Gateway specifically designed for AI workloads—but with capabilities that go far beyond simple routing.

┌─────────────────────────────────────────────────────────────────┐
│                        AI Gateway                                │
├─────────────────────────────────────────────────────────────────┤
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────────────────┐ │
│  │   Request   │  │   Policy    │  │      Observability      │ │
│  │  Inspection │  │ Enforcement │  │   & Cost Management     │ │
│  └─────────────┘  └─────────────┘  └─────────────────────────┘ │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────────────────┐ │
│  │ PII/Secret  │  │   Model     │  │   Rate Limiting &       │ │
│  │  Redaction  │  │   Routing   │  │   Quota Management      │ │
│  └─────────────┘  └─────────────┘  └─────────────────────────┘ │
│  ┌─────────────┐  ┌─────────────────────────────────────────┐  │
│  │  Prompt     │  │        Failover & Load Balancing        │  │
│  │  Injection  │  └─────────────────────────────────────────┘  │
│  │  Defense    │                                               │
│  └─────────────┘                                               │
└─────────────────────────────────────────────────────────────────┘
         │                    │                    │
         ▼                    ▼                    ▼
   ┌──────────┐        ┌──────────┐        ┌──────────┐
   │ OpenAI   │        │ Anthropic│        │  Azure   │
   │   API    │        │   API    │        │  OpenAI  │
   └──────────┘        └──────────┘        └──────────┘

The key insight is that AI workloads have unique security requirements that traditional API Gateways weren’t designed to handle:

  • Prompt inspection: Detecting injection attacks, jailbreak attempts, and policy violations
  • PII detection and redaction: Preventing sensitive data from reaching external providers
  • Model-aware routing: Directing requests to appropriate models based on content classification
  • Semantic rate limiting: Throttling based on token usage, not just request count
  • Response validation: Scanning outputs for hallucinations, toxicity, or data leakage

## The MCP Gateway: Controlling Agentic Tool Calls

As organizations deploy AI agents that can invoke tools and APIs, a new control plane emerges: the MCP Gateway. The Model Context Protocol (MCP), introduced by Anthropic and now stewarded by the Agentic AI Foundation, standardizes how AI models connect to external tools—but it also introduces significant security risks.

### The N×M Problem

Without a gateway, each agent needs custom authentication and routing logic for every MCP server (Jira, GitHub, Slack, databases). This creates an explosion of point-to-point connections that are impossible to audit, monitor, or secure consistently.

### What MCP Gateways Provide

Capability Description
Centralized Routing Single entry point for all tool calls with protocol translation
Identity Propagation JWT-based auth with per-tool scopes and least-privilege access
Tool Allow-Lists Runtime blocking of unauthorized server connections
Audit Logging Complete record of tool calls, inputs, and outputs for compliance
Response Validation Screening for injection patterns before responses reach the model
Context Management Filtering oversized payloads to prevent context overflow attacks

## The Current Landscape: Gateway Solutions Compared

### TrueFoundry AI Gateway

TrueFoundry has emerged as a performance leader, delivering approximately 3-4ms latency while handling 350+ requests per second on a single vCPU. Key enterprise features include:

  • Model access enforcement with spend caps
  • Prompt and output inspection pipelines
  • Automatic failover across providers
  • Full MCP gateway integration with identity propagation

### Lasso Security

Focused specifically on security, Lasso provides real-time content inspection with PII redaction, prompt injection blocking, and browser-level monitoring for shadow AI discovery.

### Netskope One AI Gateway

Pairs with existing identity infrastructure for enterprise-grade DLP, combining traditional network security capabilities with AI-specific controls like prompt injection defense.

### Kong AI Gateway

Brings the proven Kong API Gateway architecture to AI workloads, with plugins for rate limiting, authentication, and multi-provider routing.

### Bifrost

Optimized for microsecond-latency routing, Bifrost targets high-scale production deployments where every millisecond matters.

## Addressing the OWASP LLM Top 10

AI Gateways provide the control plane needed to address the 2026 OWASP LLM Top 10 risks:

Risk Gateway Control
LLM01: Prompt Injection Input validation, pattern matching, semantic anomaly detection
LLM02: Insecure Output Handling Response sanitization, content filtering
LLM03: Training Data Poisoning Not directly addressed (training-time risk)
LLM04: Model Denial of Service Semantic rate limiting, request throttling
LLM05: Supply Chain Vulnerabilities Centralized dependency management, provenance verification
LLM06: Sensitive Information Disclosure PII detection/redaction, DLP integration
LLM07: Insecure Plugin Design Tool allow-lists, MCP gateway controls
LLM08: Excessive Agency Least-privilege tool access, action approval workflows
LLM09: Overreliance Confidence scoring, uncertainty flagging
LLM10: Model Theft Access controls, usage monitoring

## Shadow AI: The Visibility Challenge

According to recent surveys, 68% of organizations have employees using unapproved AI tools. AI Gateways provide the visibility needed to discover and govern shadow AI usage:

  • Traffic Analysis: Identify which LLM providers are being accessed across the organization
  • Usage Patterns: Understand who is using AI tools and for what purposes
  • Policy Enforcement: Redirect unauthorized traffic through approved channels
  • Gradual Migration: Provide managed alternatives to shadow tools

## Implementation Patterns

### Pattern 1: Centralized Gateway

All LLM traffic routes through a single gateway deployment. Simple to implement but creates a potential bottleneck and single point of failure.

### Pattern 2: Sidecar Gateway

Deploy gateway logic as a sidecar container alongside each application. Eliminates the single point of failure but increases resource overhead.

### Pattern 3: Service Mesh Integration

Integrate gateway capabilities into your existing service mesh (Istio, Linkerd). Leverages existing infrastructure but may have limited AI-specific features.

### Pattern 4: Edge + Central Hybrid

Lightweight edge proxies handle routing and caching, while a central gateway provides security inspection and policy enforcement.

## Getting Started: A Phased Approach

### Phase 1: Observability (Week 1-2)

Deploy a gateway in passthrough mode to gain visibility into current LLM usage patterns without disrupting existing workflows.

### Phase 2: Basic Controls (Week 3-4)

Enable rate limiting, basic authentication, and usage tracking. Start capturing audit logs for compliance.

### Phase 3: Security Policies (Month 2)

Implement PII detection, prompt injection defense, and content filtering. Define model access policies.

### Phase 4: MCP Integration (Month 3)

If using agentic AI, deploy MCP gateway controls for tool call governance and audit logging.

### Phase 5: Continuous Improvement

Establish feedback loops from security findings to policy refinement. Regular reviews of blocked requests and anomalies.

## The Organizational Imperative

The LiteLLM incident demonstrates that AI security isn’t just a technical problem—it’s an organizational one. Platform teams need to establish AI Gateways as the standard path for all LLM interactions, not as an optional security layer.

Key questions for your organization:

  1. Do you know which LLM providers your developers are using today?
  2. Can you detect if sensitive data is being sent to external AI services?
  3. Do you have audit logs for AI tool invocations by your agents?
  4. How quickly could you rotate credentials if a supply chain attack occurred?

AI Gateways don’t solve all AI security challenges, but they provide the foundational control plane that makes everything else possible. In a world where AI agents are becoming autonomous actors in your infrastructure, that control plane isn’t optional—it’s essential.

## Looking Forward

As AI systems evolve from simple chat interfaces to autonomous agents with real-world capabilities, the security surface area expands dramatically. The organizations that establish strong AI Gateway practices now will be positioned to adopt agentic AI safely. Those that don’t will face the same painful lesson that LiteLLM’s users learned: in AI operations, trust without verification is a vulnerability waiting to be exploited.

Veröffentlicht am

Code Knowledge Graphs: Semantic Search for AI Coding Agents

AI coding tools have revolutionized software development, but there’s a fundamental limitation hiding in plain sight: most AI agents don’t actually understand your codebase—they just search it. When you ask Claude Code, Cursor, or GitHub Copilot to refactor a function, they retrieve relevant file chunks using embedding similarity. But code isn’t a collection of independent text fragments. It’s a graph of interconnected symbols, call hierarchies, and dependencies.

A new generation of tools is changing this paradigm. By parsing repositories into knowledge graphs and exposing them via MCP (Model Context Protocol), projects like Codebase-Memory, CodeGraph, and Lattice give AI agents structural awareness—enabling call-graph traversal, impact analysis, and semantic queries with sub-millisecond latency.

The RAG Problem: Why File-Based Retrieval Falls Short

Traditional RAG (Retrieval-Augmented Generation) pipelines treat codebases as document collections. They chunk files, generate embeddings, and retrieve the most similar fragments when an agent needs context. This approach has critical limitations for code:

  • Scattered evidence: Function definitions get split across chunks, separating signatures from implementations and losing import context.
  • Semantic blindness: Vector similarity doesn’t understand call relationships. A function and its callers may embed to distant vectors despite being tightly coupled.
  • Context window pressure: Complex queries requiring multi-file context quickly exhaust token budgets, forcing truncation of relevant code.
  • No impact awareness: When modifying a function, RAG can’t tell you which downstream components will break.

The result? AI agents that confidently generate code changes without understanding the ripple effects through your architecture.

Enter Code Knowledge Graphs

Knowledge graphs offer a fundamentally different approach: instead of treating code as text to embed, they parse it into structured relationships. Every function, class, import, and call site becomes a node in a traversable graph. This enables queries that RAG simply cannot answer:

  • „What functions call processPayment()?“ — Direct graph traversal, not similarity search.
  • „Show me the impact radius if I change the User interface.“ — Transitive dependency analysis.
  • „Find all implementations of the Repository pattern.“ — Semantic pattern matching across the codebase.

The key enabler is Tree-Sitter, a parsing library that generates abstract syntax trees (ASTs) for 66+ programming languages. By walking these ASTs, tools can extract symbols, relationships, and structural information without language-specific parsers.

Codebase-Memory: The MCP-Native Approach

Codebase-Memory has emerged as a leading implementation, garnering 900+ GitHub stars since its February 2026 release. It parses repositories with Tree-Sitter and stores the resulting knowledge graph in SQLite, then exposes 14 MCP query tools for AI agents:

ToolPurpose
get_symbolRetrieve a symbol’s definition, docstring, and location
get_callersFind all functions that call a given symbol
get_calleesList all functions called by a symbol
get_impact_radiusTransitive analysis of what breaks if a symbol changes
semantic_searchNatural language queries over the graph
get_module_structureHierarchical view of a module’s exports

The performance gains are substantial. Codebase-Memory reports 10x lower token costs compared to file-based retrieval—agents get precisely the context they need without padding prompts with irrelevant code. Query latency runs in sub-milliseconds, even on large repositories.

CodeGraph and token-codegraph: Multi-Language Support

CodeGraph, originally a TypeScript project by Colby McHenry, pioneered the concept of exposing code structure via MCP. Its Rust port, token-codegraph, extends support to Rust, Go, Java, and Scala. Key features include:

  • libsql storage with FTS5 full-text search for hybrid queries
  • Incremental syncing for fast re-indexing on file changes
  • JSON-RPC over stdio for seamless MCP integration
  • Zero external dependencies—runs entirely locally

The local-first architecture matters for enterprise adoption. Unlike cloud-based code intelligence (Sourcegraph, GitHub Code Search), these tools keep your proprietary code on-premises while still enabling AI-powered navigation.

Lattice: Beyond Syntax to Intent

Lattice takes a different approach by connecting code to its reasoning. Its knowledge graph spans four dimensions:

  1. Research: Background investigation, technical spikes, competitor analysis
  2. Strategy: Architecture decisions, trade-off evaluations, design rationale
  3. Requirements: User stories, acceptance criteria, constraints
  4. Implementation: The actual code and its structural relationships

This enables queries that pure code graphs can’t answer: „Why did we choose PostgreSQL over MongoDB for this service?“ or „What requirements drove the decision to make this component async?“

For AI agents, this context is invaluable. When tasked with extending a feature, they can trace back to the original requirements and strategic decisions rather than guessing from code patterns alone.

Integration Patterns for DevOps Teams

Adopting code knowledge graphs requires integrating them into your existing AI coding workflows:

1. CI/CD Graph Updates

Run graph indexing as part of your pipeline. On each merge to main:

- name: Update Code Knowledge Graph
  run: |
    codebase-memory index --repo . --output graph.db
    codebase-memory serve --port 3001 &

This ensures AI agents always query against the latest codebase structure.

2. MCP Server Configuration

Configure your AI coding tool to connect to the graph server. For Claude Code:

{
  "mcpServers": {
    "codebase": {
      "command": "codebase-memory",
      "args": ["serve", "--db", "./graph.db"]
    }
  }
}

3. Impact Analysis in PR Reviews

Use graph queries to automatically flag high-impact changes:

changed_functions=$(git diff --name-only | xargs codebase-memory changed-symbols)
for fn in $changed_functions; do
  impact=$(codebase-memory get-impact-radius "$fn" --depth 3)
  echo "## Impact Analysis: $fn" >> pr-comment.md
  echo "$impact" >> pr-comment.md
done

Benchmarks: Knowledge Graphs vs. RAG

Recent research validates the knowledge graph approach. On SWE-bench Verified—a benchmark where AI agents resolve real GitHub issues—systems using repository-level graphs significantly outperform pure RAG approaches:

ApproachSWE-bench ScoreToken Efficiency
RAG-only retrieval~45%Baseline
RepoGraph + RAG hybrid~62%3x improvement
Full knowledge graph~68%10x improvement

The token efficiency gains compound over time. Agents make fewer exploratory queries when they can directly traverse the call graph, reducing both latency and API costs.

The Future: Hybrid Structural-Semantic Retrieval

The next evolution combines structural graph queries with semantic embeddings. Rather than choosing between „find callers of X“ (structural) and „find code similar to X“ (semantic), hybrid systems enable queries like:

„Find functions that call the payment API and handle similar error patterns to our retry logic.“

This bridges the gap between precise structural navigation and fuzzy semantic understanding—giving AI agents both the map and the intuition to navigate complex codebases.

Conclusion

Code knowledge graphs represent a fundamental shift in how AI agents understand software. By treating repositories as queryable graphs rather than searchable text, tools like Codebase-Memory, CodeGraph, and Lattice unlock capabilities that RAG-based retrieval simply cannot match: call-graph traversal, impact analysis, and sub-millisecond structural queries.

For platform engineering teams, the adoption path is clear: index your repositories, expose the graph via MCP, and integrate impact analysis into your PR workflows. The payoff—10x token efficiency and dramatically more accurate AI assistance—makes this infrastructure investment worthwhile for any team serious about AI-augmented development.

The tools are open source and ready to deploy. The question isn’t whether to adopt code knowledge graphs, but how quickly you can integrate them into your AI coding pipeline.