Blog

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

CCPA CPRA AI Compliance Checklist: Ten ADMT Controls Before January 2027

A working checklist for businesses running AI over California consumer data before ADMT-specific requirements begin January 1, 2027. Each item names the duty, the concrete action, and the evidence it produces, so the list functions as an audit-readiness pass rather than a statement of intent. Ordered the way a CPPA review moves: scope and identity first, then notice and opt-out, then access, appeal and security.

Compliance & Regulationcomplianceai-governanceregulationauditai-security
Read post →

CCPA CPRA AI Audit Evidence: What the CPPA Expects Once the ADMT Rules Bite

California finalized its automated decisionmaking technology rules on 23 September 2025. The regulations took effect on 1 January 2026, ADMT obligations attach from 1 April 2027, and the first risk assessments go to the California Privacy Protection Agency by 1 April 2028. This walks the specific evidence a CCPA review asks for when a prompt carrying personal information reaches a model, from pre-use notice through opt-out and appeal, and names which system each artifact has to come from.

Compliance & Regulationcomplianceai-governanceregulationauditai-security
Read post →

California AI Law in 2026: Which Statutes Bind an Enterprise Deployer, and When

A compliance owner tracking California AI law in 2026 has five statutes to sort: SB 1001 bot disclosure, AB 2013 training-data transparency, SB 942 (delayed to August 2, 2026 by AB 853), the CPPA automated-decisionmaking rules under the CCPA, and SB 53 frontier-model safety. This piece separates the obligations that bind you as a deployer from the ones that bind model developers, with effective dates and the primary sources for each.

Compliance & Regulationcompliancecalifornia-ai-lawregulationautomated-decision-makingaudit-trail
Read post →

Shadow AI vs Shadow IT: Why the Old Detection Stack Misses the AI Request Layer

Shadow IT is the SaaS subscription the security team did not approve. Shadow AI is the LLM the employee opens in the browser tab next to the approved SaaS. The two look similar to the procurement team. They differ at the detection layer the security team built. This piece walks through the four mechanisms shadow IT detection uses, why each one misses the AI request layer, what shadow AI detection has to read instead, and the inspection topology that closes the gap.

Problem-Awareshadow-aishadow-itdiscoverycasbai-discoveryvisibility
Read post →

LLM Proxy vs API Gateway: Why a Generic Gateway Cannot See Model Traffic

A generic API gateway routes requests, checks a key, and counts calls, which is why teams reach for one in front of their LLM traffic. It stops short of the decisions AI traffic needs: who the caller is at a user grain, what the prompt contains, and a record of the AI decision. This piece compares the two on what each can see and enforce, and where the boundary between them sits.

Platform & Architectureai-gateway'llm-proxy''api-gateway''ai-security''architecture'
Read post →

LLM Gateway vs API Gateway: Where the Inspection Targets Diverge and Why You Need Both

API gateways inspect HTTP requests against rate limits, authentication tokens, and schema validation. LLM gateways inspect the prompt body, the response body, the identity carrying the request, and the policy bundle bound to the AI route. The inspection targets differ. The two run side by side in a production deployment. This piece walks through the inspection targets each gateway covers, the decisions each commits at request time, the audit record each produces, and the topology where the two compose.

Comparisons & Alternativesllm-gatewayapi-gatewayinline-enforcementaudit-logsai-architectureai-security
Read post →

LiteLLM vs an AI Security Gateway: What Each One Does and Where They Compose

LiteLLM is an open-source LLM proxy that normalizes the API surface across more than 100 model providers and handles routing, retries, fallbacks, cost tracking, and basic key management. An AI security gateway sits at the same network position but answers a different question: identity-bound policy on prompt content, data classification at the request boundary, and a per-decision audit record that holds up under EU AI Act Article 12 review. The two products compose in production deployments. This piece walks through what each one does, where they overlap, and where the architectural responsibilities split.

Platform & Architecturelitellmai-gatewaycomparisoninline-enforcementai-architectureaudit
Read post →

How to Choose an AI Gateway: The Security and Governance Criteria That Matter

AI gateways cluster into two camps: those built to route and cache model traffic for cost and speed, and those built to enforce identity, policy, and audit on it. This buyer guide walks the criteria that separate them, so a security or governance owner evaluating an AI gateway can tell which problem a given product actually solves before the trial.

Comparisons & Alternativesai-gatewaybuyer-guideai-securityai-governancellm-gateway
Read post →

EU AI Act vs GDPR: How the Two Regimes Diverge on Record-Keeping, Identity, and the Per-Decision Trace

Compliance teams reach for the GDPR record-keeping playbook when the EU AI Act lands on the legal calendar. The two regimes overlap on data subject rights and personal-data scope. They diverge on the cadence of evidence, the identity of the actor the record describes, and the per-decision trace the AI Act requires. This piece walks through the five axes where the regimes diverge, the record formats each regulator reads, and the architectural changes the AI request path needs before August 2, 2026.

Compliance & Regulationeu-ai-actgdprcompliancearticle-12audit-logsgovernance
Read post →

AI Gateway vs AI Firewall: The Architectural Difference

AI firewall and AI gateway get used as synonyms, and they describe different postures. A firewall filters content against known-bad patterns: prompt-injection signatures, jailbreak strings, disallowed topics. A gateway sits in the request path and decides, per identity and per policy, whether a call is permitted, then records it. This walks the architectural distinction, where each fits, and why a regulated deployment needs the identity and audit properties a pattern filter does not provide.

AI Security Solutionsai-gatewayai-securityinline-enforcementllm-securityarchitecture
Read post →

AI DLP vs Traditional DLP: Why the LLM Request Path Needs a Different Control

Traditional DLP classifies documents and watches known egress channels like email, USB, and web uploads. AI DLP inspects the content of a prompt or response on the LLM request path. This comparison walks the three structural differences, identity correlation, data classification, and enforcement location, and shows why the AI request boundary is where prompt-level policy has to run.

AI Security Solutionsdata-loss-preventiondlpai-securityshadow-aipolicy-enforcement
Read post →

Shadow AI Risks: Quantified Loss Exposure, Regulatory Liability, and the Per-Incident Math

Shadow AI risk lives in three separate ledgers: the per-incident breach cost, the regulatory liability that attaches to the deploying organization regardless of which employee pasted what, and the contractual liability already shifting from AI vendors to enterprises. This piece walks through each ledger with the numbers from IBM, the EU AI Act, Fannie Mae, and Gartner, and shows where the architecture closes the exposure.

Problem-Awareshadow-airiskai-governancecomplianceliabilityaudit
Read post →