Analysis on enterprise AI governance, inline policy enforcement, agentic AI security, and regulatory compliance.
An AI incident response plan for LLM deployments has to answer questions endpoint forensics cannot: which identity made which AI request, under which policy, with what data. This piece maps the incident response lifecycle to LLM-specific incidents and shows why per-decision audit records at the AI request layer are the forensic substrate the plan depends on.
Read post →An AI model inventory built from surveys is stale the day it ships, because most AI usage is unsanctioned and invisible to the teams filling in the form. This piece covers the fields a usable AI model inventory needs and why the AI request layer, which observes every call to a model, is the only source that keeps the inventory current.
Read post →AI operational governance is the running control loop over AI, distinct from the design-time work of strategy and operating models. It is what evaluates, decides, records, and reviews every AI request in production. This piece covers the day-two mechanics, policy versioning, exception expiry, drift detection, and on-call for AI policy, and why the loop has to live at the AI request layer.
Read post →On July 8, 2026 Help Net Security reported active exploitation of CVE-2026-55255, a CVSS 9.9 cross-tenant IDOR in Langflow that lets one tenant read another tenant's embedded secrets: LLM provider keys, cloud credentials, database passwords. CISA set a July 10 federal mitigation deadline. The architectural lesson is about where AI orchestration tools keep long-lived provider keys, and why a stateless gateway that holds none of them gives a secret-harvest bug far less to reach.
Read post →On July 1, 2026 Sysdig disclosed JadePuffer, the first documented ransomware operation run end to end by an LLM agent: initial access through a Langflow RCE and a Nacos auth bypass, then autonomous recon, credential theft, lateral movement, and database extortion, with the agent self-correcting a failed subprocess call in 31 seconds with no human in the loop. The one control that sits inside an AI gateway's boundary is the outbound model traffic the agent depends on to think.
Read post →Most AI risk assessment templates are a spreadsheet of likelihood-times-impact scores that no regulator would accept as evidence. This walks through the fields an assessment actually needs, mapped to NIST AI RMF MAP and MEASURE and to EU AI Act obligations, and shows why the row a template skips most often is where the AI request produces an identity-bound record of what happened at inference.
Read post →On May 14, 2026 Colorado's governor signed SB 26-189, which repeals and replaces the original Colorado AI Act (SB 24-205) and takes effect January 1, 2027. The new law narrows the target to automated decision-making technology that materially influences a consequential decision, and shifts obligations toward adverse-outcome explanations, correction and human-review rights, and a three-year record retention duty. This walks through what deployers must produce and where the evidence comes from.
Read post →The Digital Omnibus moved the EU AI Act's standalone high-risk obligations to December 2, 2027, but the August 2, 2026 date did not empty out. Article 50 transparency duties still apply then, the penalty framework is live, and the high-risk requirements themselves, risk management and lifetime event logging, still exist on a later clock. This lays out what applies when, by role, and the record-keeping obligation that runs underneath most of it.
Read post →GDPR predates the LLM era, but its obligations attach the moment personal data reaches a prompt. Lawful basis, purpose limitation, data minimization, special-category handling, automated-decision rights, records of processing, and cross-border transfer rules all apply to AI request traffic. This maps each requirement to the control that satisfies it at the AI request boundary, and shows why prompt content is the layer most GDPR programs currently cannot see.
Read post →The hardest third-party AI risk to manage is the AI you did not know a vendor was running. A SaaS tool summarizes your tickets with an LLM, a quality vendor scores your files with a model, and your data leaves for an endpoint you never approved. This walks the third-party AI risk lifecycle, from discovery through offboarding, centered on embedded and subprocessor AI, model-provider concentration, and the due-care obligation a SOC 2 report does not discharge.
Read post →A general AI gateway routes traffic and manages keys. A regulated deployment needs more from the same layer: identity bound to every request, prompt-level classification of PHI, NPI, and PII, data-residency control over which endpoints a prompt may reach, a fail-closed posture, and a per-decision audit record that survives a regulator's questions. This walks through the control requirements and maps them to healthcare, finance, government, and legal regimes.
Read post →Open source AI gateways solved the operational problem of talking to many model providers through one interface: unified APIs, routing, rate limiting, caching, key management, and observability. They are strong at the operational layer and mostly leave the control layer, identity-bound authorization, prompt classification, and a tamper-evident per-decision audit record, as a build-it-yourself exercise. This walks through what the open source category covers, where the regulated-deployment gap sits, and how to evaluate the difference.
Read post →