Analysis on enterprise AI governance, inline policy enforcement, agentic AI security, and regulatory compliance.
An AI security policy fails at the same place every time: it states what employees and services may send to a model, and nothing in the environment can observe whether that happened. This walks eleven clauses a working policy needs, marks which of them are enforceable at the AI request layer versus which stay administrative, and gives the evidence question to ask of every clause before it ships.
Read post →Six documents get called AI governance standards: ISO/IEC 42001, ISO/IEC 23894, the NIST AI RMF, ISO/IEC 27001 with AI extensions, the EU AI Act harmonized standards work, and OWASP AISVS. Only one of them is certifiable, two are law-adjacent, and they differ sharply in how much production evidence they expect. This sorts them by what they are, how they overlap, and which clauses require runtime records rather than documents.
Read post →The UK has no AI Act. AI use is governed under the UK GDPR and the Data Protection Act 2018, enforced by the ICO, with sector regulators layering their own expectations on top. Six obligations do the work: lawful basis, purpose limitation, data minimisation in the prompt, Article 22 automated decisions, international transfers when a prompt crosses a border, and Article 30 records. This walks each and marks where the evidence has to come from.
Read post →Enterprise data reaches a model through five distinct paths: a user pasting into a prompt, an application assembling context programmatically, a retrieval system injecting documents, a tool call returning results mid-loop, and training or fine-tuning. Each path has a different owner and a different control point. This walks all five, marks which are governable at the HTTP request layer, and explains why prompt-time classification is the one that cannot be substituted.
Read post →Pydantic AI gives an agent a typed output contract, typed dependencies, and validated tool signatures, which removes a real class of parsing and argument bugs. Schema validation runs after the model call and inside the process, so it covers structure rather than authorization, egress, or evidence. This walks what the type system enforces, the four gaps that remain, and how to route a Pydantic AI agent through a gateway without changing agent code.
Read post →Giving a model tools converts text generation into action. The model emits a structured call, your code executes it, and the result goes back into the context window. Three trust boundaries sit inside that loop: the tool description the model reads, the arguments it emits, and the output that returns as trusted context. This walks the failure at each boundary, the validation each one needs, and where credential scoping does work no HTTP control can substitute for.
Model version drift occurs when a deployment route, provider alias, prompt contract, or capability changes after an approval decision. A usable control record ties the deployed route and version context to the identity, data class, business purpose, and policy evaluated for each request. This article explains how change management and request-path evidence work together.
Read post →AI model monitoring needs more than provider availability and application latency. A useful program connects each model route to the requesting identity, data classification, policy version, prompt or response handling outcome, and accountable owner. This article separates model-quality monitoring from request-path governance and explains the evidence a security review can retrieve.
Read post →AI consent enforcement depends on a specific purpose, a data subject reference, and a policy decision made when an application sends data to a model. Privacy notices and consent registers establish context, but the operational test is whether a live request carries that context into an enforceable decision. This article defines that request-path evidence and the controls outside the AI boundary.
Read post →Browser agents can read a page, carry session context, and send instructions to an LLM or tool. The security review needs to separate browser-local execution and credential abuse from the HTTP AI requests that carry user data and delegated intent. This article maps that boundary, the evidence it creates, and the adjacent controls that still need owners.
Read post →AI API key sprawl occurs when model credentials are copied into scripts, agents, CI jobs, notebooks, and vendor integrations without clear ownership or narrow scope. Inventory, short-lived workload identity, secrets management, per-route authorization, and audit evidence reduce the uncertainty around each model request.
Read post →Agent privilege escalation appears when an agent receives authority broader than the user, workflow, or tool invocation requires. The operational fix begins with bounded delegation, per-action authorization, short-lived credentials, and evidence that preserves who requested an LLM action and which policy allowed it.
Read post →