Blog

Analysis on enterprise AI governance, inline policy enforcement, agentic AI security, and regulatory compliance.

OWASP LLM03 Training Data Poisoning: Why the Defense Lives Outside the Gateway

OWASP LLM03 covers training and fine-tuning data poisoning: an attacker contaminates the data the model learned from, and the contamination becomes a property of the model. The defense lives in the data and model supply chain, upstream of any runtime gateway. A policy gateway cannot un-poison a model, but it sits in the right place to detect the downstream behavior a poisoned model produces and to block the actions that behavior would trigger. This article walks through the LLM03 mechanism, where the gateway helps, and where it does not.

Problem-Awareai-securityowaspllm-securitydata-poisoningsupply-chainarchitecture
Read post →

OWASP LLM04 Model Denial of Service: Gateway Controls That Actually Hold Under Load

OWASP LLM04 covers model denial of service: resource-exhaustion attacks that exploit the cost asymmetry between issuing a prompt and serving it. A single user can drive an LLM workload to consume orders of magnitude more compute, tokens, or wall-clock time than a benign request. The defense is rate-limiting and shaping at the boundary where every request is visible. This article walks through the LLM04 attack patterns, the gateway controls that hold under load, and the metrics to instrument.

Problem-Awareai-securityowaspllm-securityrate-limitingai-gatewaycost-management
Read post →

OWASP LLM05 Supply Chain Vulnerabilities: Mapping the Surface a Gateway Can Cover

OWASP LLM05 covers supply chain vulnerabilities across the AI stack: model weights from public hubs, serving frameworks with their own CVE histories, third-party tools the agent calls, dependencies in inference dependencies. The defenses split across the supply chain itself, the runtime, and the network boundary. A policy gateway covers the network-boundary piece. This article maps the LLM05 surface, sorts the controls by which layer enforces each one, and shows what an identity-aware gateway adds.

Problem-Awareai-securityowaspllm-securitysupply-chainai-bomvulnerability-management
Read post →

OWASP LLM08 Excessive Agency: Bounding What an Agent Is Allowed to Actually Do

OWASP LLM08 covers excessive agency: the AI agent has the ability to take actions that exceed what the application or the user intended. The category is the agentic equivalent of the post-authentication gap: authentication and authorization happened, but the action the agent took was not the action the authorization actually permitted. The control point is the boundary between the agent loop and the tool surface. This article walks through the LLM08 mechanisms, the agency-bounding controls a gateway enforces, and where the architecture differs from classic API authorization.

Problem-Awareai-securityowaspllm-securityagentic-aiauthorizationtool-permissions
Read post →

MCP Tool Poisoning Prevention: Gateway Controls for the Model Context Protocol Surface

Model Context Protocol tool poisoning is the agentic analog to supply-chain compromise. An MCP server presents a set of tools to an agent host; an attacker who controls the MCP server (or the tool definitions an MCP server advertises) can change what the tools do, what they return, or what parameters they accept. The agent loop calls the tool in good faith and the actions executed against downstream systems are the attacker'"'"'s. The prevention surface splits across MCP server selection, tool-definition pinning, and per-decision authorization at the agent-tool boundary. This article walks through the MCP poisoning patterns and the gateway controls that contain them.

Problem-Awaremcpai-securityagentic-aitool-permissionssupply-chainai-gateway
Read post →

AI Gateway Canary Deployment: Patterns for Rolling Policy and Model Changes Safely

Canary deployment for an AI gateway covers two distinct change types: model routing changes (a new provider, a new model version, a new model entirely) and policy changes (a new redaction rule, a new tool allowlist, a new rate-limit threshold). Each change type has different risk characteristics and different rollback triggers. The canary pattern at the gateway differs from a classic application canary because the unit of traffic is identity-bound and the failure modes include silent drift in model behavior. This article walks through the canary architecture for an AI gateway, the metrics that drive the rollout, and the rollback conditions that have to be wired in before the canary starts.

Platform & Architectureai-gatewaycanary-deploymentdeployment-patternsrelease-managementai-policy-enforcementplatform-engineering
Read post →

AI Gateway Rate Limiting by Identity: Why Per-Key Limits Fail in Production

AI gateway rate limiting that uses the API key as the limit boundary fails in three production patterns: shared service accounts, agent fan-out, and cost runaway from a single high-volume identity. The fix is to limit per verified identity, where identity is the authenticated principal extracted from the request context, not the API key in the header. This article walks the failure modes, the architecture that fixes them, the data model the gateway needs, and the operational tradeoffs of identity-bound limits versus simpler per-key approaches.

Platform & Architectureai-gatewayrate-limitingidentityengineeringpolicy-enforcementagentic-ai
Read post →

AI Gateway Fail-Open vs Fail-Closed: The Decision That Shapes Your Audit Trail

An AI gateway that sits inline between authenticated callers and the LLMs they use has to answer a structural question. When the gateway cannot reach the policy decision (the policy engine is down, the identity service is unreachable, a configuration cannot be loaded), does the request go through (fail-open) or get refused (fail-closed)? The answer shapes the audit trail, the regulatory posture, and the production behavior under degraded conditions. This article walks the tradeoffs, the cases where each mode is appropriate, the data-driven defaults, and the operational patterns that hold up under audit.

Platform & Architectureai-gatewayfail-closedreliabilityengineeringpolicy-enforcementaudit-logging
Read post →

MCP Confused Deputy: Why the Server Acting on the User Is the Wrong Principal

The confused deputy attack describes the case where a privileged intermediary acts on behalf of a less-privileged caller and ends up doing things the caller could not have done directly. In the Model Context Protocol (MCP) world, the confused deputy lives in the MCP server. The MCP server holds credentials for upstream tools and acts on behalf of an LLM client. When the client identity is not propagated to the upstream calls, the upstream services see the MCP server, not the user, and authorization decisions get made against the wrong principal. This article walks the attack pattern, the architectural cause, the controls a policy gateway enforces at the MCP boundary, and the operational checklist.

Problem-Awaremcpconfused-deputyauthorizationagentic-aipolicy-enforcementsecurity
Read post →

RAG Poisoning Prevention: Defending the Retrieval Layer Against Adversarial Content

Retrieval-augmented generation grounds an LLM response in a corpus of documents the application retrieves at query time. The retrieval surface is also an attack surface. An attacker who can write to the corpus or to a source the corpus ingests from can inject content that steers the model toward attacker-chosen outputs. RAG poisoning has three production patterns: corpus injection, indirect prompt injection through retrieved content, and adversarial document crafting that pollutes the embedding space. This article walks the failure modes, the defense layers, the controls a policy gateway enforces against the model-call boundary, and the operational checklist.

Problem-Awareragprompt-injectionllm-securityagentic-aipolicy-enforcementdata-poisoning
Read post →

AI Gateway Rollback Strategy: How to Revert a Policy or Model Change Without Breaking the Audit Trail

A bad policy change or a broken model upgrade at the AI gateway has to be reverted fast. The rollback is the high-availability move that prevents a small problem from becoming a service-wide outage. The rollback also has to preserve the audit trail, because the regulatory record of "what policy was in effect when" survives the rollback. This article walks the rollback patterns that work at the gateway layer, the failure modes that catch teams off guard, the integrity controls that keep the audit record consistent across the revert, and the operational drill that proves the rollback works before it has to.

Platform & Architectureai-gatewayrollbackdeploymentpolicy-versioningaudit-logginghigh-availability
Read post →

AI Gateway Blue-Green Deployment: How to Ship a Gateway Version Without Cutting Traffic

A blue-green deployment runs two full gateway environments in parallel, with traffic flipped at a load balancer from the current (blue) environment to the new (green) environment after the green environment has been verified. The pattern works for AI gateways with two differences from a standard API gateway: the policy and routing state has to be consistent across the cutover, and the audit log chain has to remain unbroken. This article walks the blue-green pattern at the AI gateway layer, the state-consistency requirements, the verification gates, and the fallback path.

Platform & Architectureai-gatewayblue-green-deploymenthigh-availabilitydeploymentaudit-loggingdevops
Read post →