Blog

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

EU AI Act Article 5 Prohibited Practices: The Eight AI Use Cases That Cannot Be Deployed in the EU

EU AI Act Article 5 prohibits eight categories of AI use that the regulation treats as incompatible with Union values. The prohibition has been in force since February 2, 2025. Penalties under Article 99 reach EUR 35 million or 7 percent of global annual turnover, the highest tier in the regulation. Enterprises preparing for the August 2, 2026 high-risk deadline often skip Article 5 because the prohibitions sound like edge cases. The operational reality is that several prohibitions catch mainstream enterprise use cases when the system is examined against the actual statutory text.

Compliance & Regulationeu-ai-actarticle-5prohibited-aicomplianceregulationai-governance
Read post →

EU AI Act August 2, 2026 Readiness Checklist: The 32-Day Operational Sweep

On August 2, 2026, the EU AI Act high-risk system obligations take effect. Providers and deployers operating in the EU have 32 days from today to close the gap between the regulation as written and the operational evidence the supervisory authorities will ask for. This checklist walks the eight artifacts a high-risk deployer needs in production before August 2: the inventory, the classification, the Article 11 documentation, the Article 12 logging architecture, the Article 14 human oversight record, the Article 19 retention plan, the Article 26 deployer obligations, and the Article 73 incident reporting workflow.

Compliance & Regulationeu-ai-actcompliancehigh-risk-airegulationauditai-governance
Read post →

AI Audit Log Chain of Custody: What Forensic Integrity Requires at the Request Boundary

An AI audit log that has to survive a regulatory inquiry or a legal proceeding needs more than the data it captures. The log needs a chain of custody: the proof that the record at the moment of inquiry is the record that was written at the moment of the decision, that nobody has modified it in between, and that the writer and the reader are the entities they claim to be. The chain of custody applies to the AI request-and-response log as much as to physical evidence in any other regulated context. This article walks the requirements, the failure modes, the cryptographic and operational controls that produce a defensible chain, and the architectural pattern that holds up under examination.

Problem-Awareaudit-loggingforensicscomplianceevidencetamper-evidenthigh-risk-ai
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 →

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 →

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 →

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 →

EU AI Act EU Database Registration: Article 49 Obligations for High-Risk Systems

EU AI Act Article 49 requires providers of most high-risk AI systems to register the system in the EU database for high-risk AI systems before placing it on the EU market or putting it into service. Article 49(2) creates a parallel obligation for public-authority deployers and certain EU institution deployers to register the systems they use. The database is maintained by the Commission and is publicly accessible for the information that is not commercially sensitive. With the August 2, 2026 high-risk enforcement date 34 days away, providers and the in-scope deployers need a clear read on what gets registered, who registers it, and what the registration record contains.

Compliance & Regulationeu-ai-actcompliancedatabase-registrationhigh-risk-airegulationarticle-49
Read post →

EU AI Act Post-Market Monitoring: Article 72 Obligations and the Plan That Survives an Audit

EU AI Act Article 72 requires providers of high-risk AI systems to establish and document a post-market monitoring system that actively and systematically collects, documents, and analyzes data on the performance of the system throughout its lifetime. The monitoring system must be proportionate to the nature of the AI technologies and the risks, and it must allow the provider to evaluate continuous compliance with the requirements of Chapter III, Section 2 of the regulation. With the August 2, 2026 high-risk enforcement date 34 days away, providers and deployers need a clear read on what the monitoring plan must contain, what data feeds it, and what artifacts an auditor expects to see.

Compliance & Regulationeu-ai-actcompliancepost-market-monitoringhigh-risk-airegulationarticle-72
Read post →

EU AI Act Incident Reporting: Article 73 Obligations Before the August 2 Date

EU AI Act Article 73 requires providers of high-risk AI systems to report serious incidents to the market surveillance authority of the member state where the incident occurred. The reporting window is 15 days from the moment the provider establishes the causal link between the incident and the AI system, with a 72-hour window for widespread infringements and a 2-day window for incidents resulting in death. With the August 2, 2026 high-risk enforcement date 34 days away, providers and deployers need a clear read on what counts as a serious incident, who reports, and what the reporting record needs to contain.

Compliance & Regulationeu-ai-actcomplianceincident-responsehigh-risk-airegulationarticle-73
Read post →

OWASP LLM10 Unbounded Consumption: The Cost, Latency, and DoS Failure Mode

OWASP LLM10 Unbounded Consumption, in the 2025 OWASP Top 10 for LLM Applications, replaced the older "Model Theft" category and captures a broader failure mode: a workflow consumes model resources without effective bounds, leading to runaway cost, degraded latency, denial-of-service for legitimate callers, or wallet drain attacks against pay-per-token APIs. The mitigation surface has three layers. The application can implement budgets and quotas inside its own code. The model provider exposes rate limits and quota policies at the API. A policy gateway sits between the two and enforces identity-bound limits that the application cannot bypass.

Problem-Awareowaspllm-securityrate-limitingai-governancepolicy-enforcementcost-control
Read post →

OWASP LLM09 Misinformation: Where a Policy Gateway Reduces the Production Blast Radius

OWASP LLM09 Misinformation, in the 2025 OWASP Top 10 for LLM Applications, names the risk that an LLM produces plausible but inaccurate output that downstream systems treat as authoritative. The control surface a model-side fix can address is partial. Output validation, retrieval grounding, and confidence signals each sit upstream of the request boundary. A policy gateway between authenticated users or agents and the LLM sits at a different point in the path and can enforce identity-bound rules on which calls are permitted, which prompts trigger heightened validation, and which responses get persisted with provenance metadata.

Problem-Awareowaspllm-securitymisinformationai-governancepolicy-enforcementagentic-ai
Read post →