Blog

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

Mistral Prompt Injection: What the EU-Sovereign Models Inherit from the OWASP LLM01 Class

Mistral models run on EU-sovereign infrastructure for a reason: European enterprises that need to keep AI traffic inside the EU prefer the provider that started there. The architectural choice does not change the prompt-injection surface. Mistral models inherit OWASP LLM01 the same way OpenAI, Anthropic, and Google do, and the defense pattern that works is identical: identity-aware policy enforcement at the HTTP boundary, plus per-decision audit. This walkthrough covers the Mistral-specific attack patterns documented in production, the defense layers that hold, and the audit fields that survive the regulator.

Problem-Awaremistralprompt-injectionowasp-llm01ai-securityeu-sovereign
Read post →

EU AI Act Article 19: What the Six-Month Log Retention Rule Requires

Article 19 of the EU AI Act tells deployers of high-risk AI systems what to put in the automatically generated logs Article 12 requires, and how long to keep them. The retention floor is six months. The content has to support traceability for risk monitoring and post-market surveillance. The August 2, 2026 deadline applies. Most application logging stacks miss the identity, classification, and policy-state fields the Article 19 reading actually calls for.

Compliance & Regulationeu-ai-actarticle-19complianceaudithigh-risk-airetention
Read post →

AI Security Tools List: The 14 Categories That Actually Show Up in Enterprise Architecture

The AI security category is fragmented across 14 distinct tool types: AI gateway / policy enforcement, AI DLP, AI SPM, model security, guardrails, agent identity, red teaming, model risk management, AI observability, vendor risk for AI, AI incident response, AI training data security, federated learning security, and AI supply chain. Each category solves a different layer of the AI stack. Buyers who treat the category as one bucket overspend on overlap and underspend on the actual enforcement layer. This list walks through what each category does, where it sits in the architecture, and what to ask vendors before buying.

Comparisons & Alternativesai-securityvendor-evaluationbuying-guideai-toolscategory-mapai-gateway
Read post →

AI System Cards: What Goes Inside, Which Regulators Expect Them, and Where the Operational Evidence Comes From

An AI system card documents the AI system as deployed: the intended use, the operating environment, the human oversight mechanisms, the policies in effect, the audit-trail format, and the decommissioning plan. System cards extend the model-card concept from a model artifact (Mitchell et al., 2018) to a deployed-system artifact. Regulators expect system cards under EU AI Act Article 11 technical documentation, ISO 42001 Clause 7.5 documented information, NIST AI RMF MAP function, and Fannie Mae LL-2026-04 Pillar 1 inventory. This walkthrough covers the eight fields a system card needs, where the operational evidence comes from, and how the per-decision audit log feeds the card.

Compliance & Regulationai-system-cardeu-ai-actdocumentationai-governancecomplianceaudit-evidence
Read post →

The AI Governance Alliance: What the WEF Working Groups Have Shipped and Where Their Recommendations Land in Your Architecture

The AI Governance Alliance is the World Economic Forum initiative coordinated through three working groups: Safe Systems and Technologies, Responsible Applications and Transformation, and Resilient Governance and Regulation. Its outputs land in three places: model-level safety research, enterprise deployment patterns, and regulator-facing guidance for cross-border AI rules. The Alliance has shipped published frameworks since 2024 that map directly to NIST AI RMF MANAGE function, EU AI Act Article 13 transparency requirements, and the OECD AI principles. This walkthrough covers which Alliance outputs are operational, which are still aspirational, and where the recommendations need an enforcement layer.

Compliance & Regulationai-governancewefai-governance-alliancecomplianceframeworksglobal-governance
Read post →

AI Bias Detection: From Statistical Tests to Per-Decision Audit Records That Survive a Regulator Review

AI bias detection runs at two layers. The model-level layer evaluates the model against test sets across demographic groups and reports statistical disparities (demographic parity, equalized odds, calibration). The deployment-level layer evaluates actual decisions on actual people in production and reports outcomes against the populations affected. Regulators reading bias evidence under EU AI Act Articles 10 and 15, ISO 42001 Clause 9.1, and NIST AI RMF MEASURE.2.11 expect both layers. The deployment-level layer requires per-decision audit records that capture identity, classification, policy state, and outcome.

Problem-Awareai-biasbias-detectionai-fairnesseu-ai-actcomplianceaudit-evidence
Read post →

AI Transparency Disclosure: What EU AI Act Article 13 Requires from Providers and What Deployers Owe Their Users

AI transparency disclosure obligations come from three layers. EU AI Act Article 13 requires high-risk AI system providers to deliver instructions of use, system characteristics, capabilities, limitations, and the means for human oversight to deployers. Article 26 extends the obligation: deployers have to inform natural persons that they are subject to an AI system. The horizontal transparency obligations under Articles 50 through 53 cover labelling synthetic content, disclosing AI interactions, and watermarking generated media. Each layer has a different recipient, a different artifact, and a different timing. This walkthrough covers the three layers and the audit-record fields that prove the disclosures actually fired.

Compliance & Regulationai-transparencyeu-ai-actarticle-13disclosurecomplianceai-governance
Read post →

DORA Third-Party AI Risk: How EU Banks Have to Treat LLM Vendors Under the ICT Critical-Provider Regime

Under the Digital Operational Resilience Act, EU financial entities have to maintain a register of all ICT third-party service providers including LLM vendors, classify which ones support critical or important functions, run pre-contract diligence on those, and meet specific contract content rules under Article 30. The European Supervisory Authorities can designate certain LLM vendors as Critical ICT Third-Party Providers under the CTPP regime, with direct supervisory powers. The Jan 17, 2025 enforcement date is in the rear-view; the question now is whether your AI usage shows up correctly in the register and whether your audit evidence survives an ESA review.

Compliance & Regulationdorathird-party-riskfinancial-servicescomplianceeu-regulationai-governance
Read post →

LiteLLM's June CVE wave: what an authentication bypass in an AI gateway teaches about control-plane design

LiteLLM disclosed seven CVEs in June 2026, including CVE-2026-12773, a CVSS 7.3 authentication bypass in the UserAPIKeyAuth path, and CVE-2026-42271, a remote code execution flaw that CISA added to the Known Exploited Vulnerabilities catalog on June 8, 2026. The cluster of disclosures exposes a structural lesson about AI gateway design: the gateway authentication layer and the provider-key storage layer are themselves high-value attack surfaces. The lesson points at architectural choices that minimize blast radius.

Problem-Awarelitellm-cveai-gateway-securityauthentication-bypasscve-2026-12773cisa-kevcontrol-plane
Read post →

Fail-closed AI gateway design: why the default failure mode is the security mode

A fail-closed AI gateway returns HTTP 503 when the policy decision point cannot reach a verdict, blocking the request rather than forwarding it. A fail-open gateway returns HTTP 200 with the upstream model response, treating the policy outage as a pass. The choice between the two postures determines whether a policy outage produces a security incident or a contemporaneous deny record. EU AI Act Article 12 and Article 26 expect the deny record. The four failure categories that test the design are policy timeout, identity provider outage, redaction engine outage, and audit write outage.

Platform & Architecturefail-closedai-gatewaypolicy-enforcementeu-ai-actaudit-logsavailability
Read post →

AI gateway observability: the metrics, traces, and logs a policy decision point should emit

An AI gateway emits four signal categories that serve four different audiences. Per-decision audit logs serve the regulator under EU AI Act Article 12. Per-request traces serve the engineering team debugging a request. Per-policy metrics serve the operations team measuring policy effects. Per-model latency histograms serve the capacity-planning team sizing the LLM provider relationship. OpenTelemetry alignment lets the four signal categories share a transport without conflating their consumers.

Platform & Architectureai-gateway-observabilityopentelemetryaudit-logseu-ai-act-article-12policy-metricslatency-histograms
Read post →

AI policy version control: how to treat gateway policy like code

AI gateway policy that governs which users can call which models with which data lives in YAML, evolves with the organization, and carries the same regression risk as application code. Treating the policy as code means git-backed storage, semantic versioning of policy bundles, audit-log tagging of decisions with the policy version hash, blue/green policy rollout, and shadow-mode evaluation before promotion. The NIST AI RMF MAP and MANAGE functions ask the questions the version-control discipline answers.

Platform & Architectureai-policy-version-controlpolicy-as-codenist-ai-rmfblue-green-deploymentshadow-modegitops
Read post →