Blog

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

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 →

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 →

EU AI Act FRIA Templates for Deployers: What the Article 27 Assessment Actually Has to Contain

Article 27 of the EU AI Act requires a Fundamental Rights Impact Assessment from certain deployers of high-risk AI systems before first use. The FRIA must cover the deployment process, the time period and frequency of use, the categories of natural persons affected, the specific risks of harm, the human oversight measures, and the measures to take if those risks materialize. The August 2, 2026 enforcement date means deployers of in-scope systems need a completed FRIA in hand at that point. This article walks through what Article 27 actually requires, which deployers are in scope, and the section-by-section structure a defensible FRIA needs.

Compliance & Regulationeu-ai-actcomplianceai-governanceregulationfundamental-rightsfria
Read post →

EU AI Act Importers and Distributors: The Lesser-Known Article 23 and Article 24 Obligations

Article 23 covers importer obligations and Article 24 covers distributor obligations for high-risk AI systems in the EU. The roles get conflated with provider and deployer roles in practice. An importer is the operator that places a high-risk AI system from outside the EU onto the EU market. A distributor is the operator that makes a high-risk AI system available in the EU market without being the importer or the provider. Both have specific verification obligations before the system reaches the deployer. With the August 2, 2026 enforcement date approaching, EU resellers and EU branches of non-EU vendors need to understand which obligations belong to them.

Compliance & Regulationeu-ai-actcomplianceai-governanceregulationhigh-risk-aiimporter-distributor
Read post →

EU AI Act Providers vs Deployers: Splitting the Obligations Before August 2, 2026

The EU AI Act assigns different obligations to providers and deployers of high-risk AI systems. Article 16 covers provider obligations; Article 26 covers deployer obligations. The split matters because most enterprises operating AI in the EU are deployers, not providers, and the deployer obligations are routinely underestimated. With the August 2, 2026 high-risk enforcement date 35 days away, deployers running on someone else''s foundation model need a clear read on which obligations belong to them. This article walks the provider-deployer split, the cases that change the assignment, and the architectural artifacts each side needs.

Compliance & Regulationeu-ai-actcomplianceai-governanceregulationhigh-risk-aideployer-obligations
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 →

OWASP LLM06 Sensitive Information Disclosure: The Output-Side Controls a Gateway Enforces

OWASP LLM06 covers sensitive information disclosure: the model emits data the application or the user is not authorized to receive. The disclosure paths split into three: training-data leakage, in-context leakage from RAG and tool outputs, and cross-tenant leakage from shared deployments. The output-side controls live at the gateway, where every response is observable before it reaches the user. This article walks through the LLM06 disclosure paths, the output-side controls that work, and the redaction and policy patterns to enforce.

Problem-Awareai-securityowaspllm-securitydata-leakageoutput-filteringredaction
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 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 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 →

MCP Server Authentication for Enterprise Deployments: Identity, Authorization, and the Boundary Question

Model Context Protocol (MCP) servers have moved from developer-tool integrations to production agent backends inside enterprises. The authentication and authorization model for MCP traffic differs from REST-API authentication in two specific ways that matter at enterprise scale: the principal acting on the MCP server can be an agent on behalf of a human, and the tool invocations have to carry the propagation chain. This article walks through the MCP authentication model, the transport-boundary distinction, and the gateway-layer controls that produce a usable audit trail.

Platform & Architectureai-securitymcpauthenticationagent-securityarchitecturepolicy-enforcement
Read post →

AI Security for KYC Onboarding: BSA, FINRA, and the Per-Decision Record Regulators Inspect

KYC onboarding is one of the highest-volume AI use cases inside banks, broker-dealers, payments firms, and crypto exchanges. The regulatory stack covers the Bank Secrecy Act customer-identification rules, FINRA know-your-customer obligations, FinCEN beneficial-ownership reporting, and (in EU operations) the EBA AML package. This article walks through the AI integration points inside a KYC pipeline, the per-decision audit fields the relevant regulators inspect, and the gateway-layer controls that produce records sufficient for an enforcement inquiry.

Industry Verticalsai-securityfinancial-serviceskycamlcomplianceaudit
Read post →