Blog

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

HIPAA Business Associate Agreements for AI Vendors: The Clauses That Actually Matter When PHI Reaches an LLM

A signed BAA does not, on its own, make an AI deployment HIPAA-compliant. The BAA covers the vendor relationship; the deployer still owns the safeguards under 45 CFR 164.308, 164.312, and 164.316. This walks through the clauses that matter when PHI flows into an LLM, the training-on-PHI question every BAA now has to address, and the audit-trail requirements HIPAA imposes on the deployer regardless of what the vendor logs.

Compliance & Regulationhipaacomplianceai-securityphibusiness-associate-agreementhealthcare
Read post →

ISO 27001 Annex A Controls Applied to AI Systems: Where the 2022 Revision Already Covers AI and Where It Does Not

The 2022 revision of ISO 27001 collapsed the Annex A control set from 114 to 93 controls across four themes. Several controls apply cleanly to AI systems without any AI-specific supplement. Others surface gaps the auditor tests when AI is in scope. A walk through the controls that matter (5.15 access control, 8.10 information deletion, 8.15 logging, 8.16 monitoring, 8.24 cryptography, 8.28 secure coding) with the specific evidence a policy gateway produces.

Compliance & Regulationiso-27001complianceai-governanceannex-aauditai-security
Read post →

SOC 2 AI Controls: Which Trust Services Criteria a Policy Gateway Actually Evidences

SOC 2 does not have an AI-specific control category, but every AI deployment inside a Type II audit surfaces control gaps under the same five Trust Services Criteria. The auditor questions center on who accessed the model, what data flowed through it, whether policy enforcement is deterministic, and whether the audit trail is tamper-evident. Application-controlled logs fail the CC7 evidence bar. The fix is architectural.

Compliance & Regulationsoc-2complianceai-governanceauditai-securitytrust-services
Read post →

AI Firewall vs AI Gateway vs AI Proxy: The Category Distinctions Buying Teams Keep Blending Together

The three terms describe overlapping but distinct control points on AI traffic. AI firewall filters prompts and responses for policy violations. AI gateway aggregates traffic across LLM providers with rate limiting and routing. AI proxy is the transport layer that inspects the HTTP session. The buying decision turns on which control you actually need at what latency budget, and where identity binding happens in the request path.

AI Security Solutionsai-gatewayai-firewallai-proxyai-securityarchitectureai-policy-enforcement
Read post →

AWS Bedrock Guardrails alternatives: where the model-bound control falls short

AWS Bedrock Guardrails covers content filtering, denied topics, and PII redaction for traffic that lands on Bedrock. The control is bound to Bedrock-mediated requests. Enterprises running multi-model AI need a gateway that covers OpenAI, Anthropic direct, Azure AI, and self-hosted models with a single policy plane. This is the alternatives comparison: what the gap is, who fills it, and what to look for when evaluating.

Comparisons & Alternativesalternativesbedrock-guardrailsawsai-gatewaymulti-model
Read post →

AI tool-use authorization: what the caller can invoke, what the model is allowed to attempt, and where the line sits

AI tool-use authorization decides which tools an LLM caller can invoke, which arguments the caller can pass, and which tool calls the model is allowed to attempt on the caller behalf. Production deployments enforce three layers: caller-role authorization (what the identity is entitled to use), argument-value authorization (what values fall inside the caller scope), and model-behavior authorization (which tool call sequences the deployer permits). This piece walks through the three layers, the failure modes each one catches, and the evidence each layer produces on the per-decision audit record.

Platform & Architecturetool-callingai-agentauthorizationai-gatewayagent-security
Read post →

AI response tool-call validation: the five checks that run before a tool call reaches the executor

When an LLM response contains a tool call, the tool call sits between the model output and a side effect in a real system. Untouched tool calls execute whatever the model produced, including hallucinated tools, malformed arguments, and unauthorized parameters. Production deployments run five checks at the gateway before the tool call reaches the executor: schema validation, tool-allowlist check, argument authorization, idempotency-key attachment, and audit-record production. This piece walks through each check, the failure modes it catches, and how the checks compose across the OpenAI, Anthropic, and Bedrock tool-call formats.

Platform & Architecturetool-callingai-agentai-gatewayagent-securityllm-response
Read post →

AI usage quota enforcement: the four counters production deployments actually need

AI usage quota enforcement is the mechanism that keeps AI spend, provider rate limits, and cross-tenant fairness under control. Production deployments need four counters at the gateway: per-caller request rate, per-tenant token throughput, per-workload cost, and per-model concurrency. Each counter answers a different failure mode. This piece walks through the four counters, where each one sits in the request flow, the fail-closed behavior each one demands, and the audit fields the enforcement decisions produce.

AI Security Solutionsai-quotarate-limitingai-gatewaycost-controlai-policy-enforcement
Read post →

LLM multi-model routing: the invariants that hold when you serve traffic from more than one provider

LLM multi-model routing spreads traffic across two or more model providers so a single-vendor outage, price change, or policy shift does not stop production. The pattern is simple in principle and complicated in practice because different providers have different token formats, streaming semantics, tool-call schemas, and safety-refusal patterns. This piece walks through the six invariants that hold regardless of provider (identity resolution, classification, policy, audit, idempotency, and response normalization) and the three variances that do not (token accounting, streaming chunking, and tool-call format).

Platform & Architecturellm-routermulti-modelai-architectureai-gatewayanthropicopenaibedrock
Read post →

LLM fallback routing: the retry chain that survives provider outages without leaking policy

LLM fallback routing chains a primary model to a secondary and tertiary so provider outages, rate-limit errors, and quality regressions do not cause user-visible failures. The failure modes are usually not the fallback logic itself but the boundary between the fallback chain and the policy decision that authorized the request. This piece walks through the four common triggers for fallback, the retry semantics per trigger, the authorized-endpoint constraint, and the idempotency requirements for tool-calling workloads.

Platform & Architecturellm-routerllm-fallbackai-architectureai-gatewayreliability
Read post →

LLM routing strategies: five patterns for production, and where the policy decision constrains each one

LLM routing strategies decide which model, provider, or endpoint handles a given request. Five patterns cover most production deployments: static routing, cost-optimized routing, quality-tiered routing, latency-budgeted routing, and fallback routing. Each pattern operates on request metadata after the policy decision at the gateway has authorized the request and produced the audit record. This piece walks through the five patterns, what each optimizes for, and the constraints the gateway places on all of them.

Platform & Architecturellm-routerllm-routingai-architectureai-gatewaymulti-model
Read post →

The LLM inference gateway: what sits between authenticated callers and the model, and what belongs somewhere else

The LLM inference gateway is the identity-aware policy enforcement point between authenticated users or agents and any model endpoint. It is the layer where authorization, data classification, and audit-record production live. This piece defines the term, walks through the four fields the gateway resolves per request, contrasts it with the inference server, model router, and API gateway it is often confused with, and shows why the audit-write path must be isolated from the caller. Applies to any deployment running an OpenAI-compatible or provider-native LLM API in production.

Platform & Architecturellm-gatewayllm-inferenceai-architectureai-control-planepolicy-enforcement
Read post →