Analysis on enterprise AI governance, inline policy enforcement, agentic AI security, and regulatory compliance.
The AI-SPM market splits into five architectural categories: discovery-first scanners, CNAPP-bundled posture, runtime enforcement gateways, agent governance platforms, and AI-aware DLP. This guide describes where each sits in the stack, what to verify before buying, and how to sequence a purchase so visibility and enforcement reinforce each other instead of overlapping.
Read post →AI security posture management (AI-SPM) inventories where AI runs, scores how each deployment is configured, and tracks the data those deployments reach. This guide covers the four capability areas of AI-SPM, where its point-in-time visibility ends, and why the per-request decision and per-decision audit record belong to a runtime enforcement layer at the AI request boundary.
Read post →A healthcare AI agent chains several PHI accesses to complete one task, and HIPAA still asks who accessed what and whether the access was the minimum necessary. This article walks the two obligations agents strain hardest, attribution under the audit-control standard and minimum necessary applied per action rather than per session, and shows why a shared agent credential and session-level logging leave both unmet at the request layer.
Read post →A federal agency that wants to use an LLM inherits FedRAMP, and the question that decides compliance is where the agency data goes when a prompt leaves the authorized boundary. This article walks the authorization boundary problem, the NIST SP 800-53 audit and access-control families that AI traffic has to satisfy, and why keeping agency prompts inside the authorized estate is an enforcement problem on the request path, not a policy statement.
Read post →A fintech fraud model makes a real-time decision on every transaction, and when it declines a legitimate customer it creates an adverse-action obligation and a fair-lending exposure. This article walks the governance a fraud model needs in production: version control on the live decision, drift monitoring as fraud patterns shift, and a per-decision record that reconstructs why a specific transaction was blocked, so a dispute or a regulator can be answered.
Read post →DORA is read as a third-party register exercise, and its ICT risk management and testing chapters also reach the runtime AI request path. This article walks the DORA obligations that land on inference itself, protection and detection under Articles 9 and 10, incident reconstruction under Article 17, and threat-led testing under Articles 24 to 27, and shows what a financial entity has to enforce and record on its live AI traffic to meet them.
Read post →When an edtech tutoring bot or grading assistant sends student work to a language model, the student record travels inside the prompt, and three privacy regimes attach: FERPA on education records, COPPA on data from children under 13, and state laws like California SOPIPA. This article walks what each regime requires of that data flow and shows where the exposure actually happens, in the prompt payload heading for a third-party model.
Read post →SR 11-7 defines a model as any quantitative method that produces output to inform a decision, which puts LLMs and AI agents squarely in scope for a bank. This article walks the three pillars of the guidance, sound development, independent validation, and governance, and shows why the validation team cannot challenge an opaque non-deterministic vendor model without production telemetry on what the model was actually asked and what it returned.
Read post →A bank running LLMs answers to model risk guidance, operational resilience rules, fair lending law, and data protection statutes at the same time. This article maps the regimes a bank compliance officer has to satisfy at once, SR 11-7, DORA, the ECB AI cyber letter, ECOA, and the EU AI Act, points to the deep dive on each, and shows the operational thread that runs through all of them at the AI request layer.
Read post →HIPAA does not have an AI section, and the Security Rule and Privacy Rule already govern any AI system that touches protected health information. This article walks the three obligations that bind an LLM deployment: access control and audit controls under 45 CFR 164.312, the minimum necessary standard, and the business associate agreement a third-party model provider triggers. It then marks where most deployments leave those obligations unmet at the request layer.
Read post →Teams front Vertex AI with a gateway for three jobs: token quotas and cost attribution, regional routing for data residency, and content screening on prompts through Model Armor. This article walks the patterns engineers run on Apigee in front of Gemini, shows where Model Armor sits, and marks the line between screening scoped to Google Cloud and the identity-bound payload governance a mixed model estate needs.
A RAG request crosses four trust boundaries before the answer comes back: what gets indexed, who can retrieve which chunks, what the assembled prompt carries into the model, and what the response returns. This article lays out the reference architecture for each boundary, marks which two are data-plane controls and which two sit on the HTTP path to the model, and shows where identity-bound policy and a per-decision audit record belong.