Blog

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

OWASP LLM07: System Prompt Leakage and Why Secrets in System Prompts Are Always Wrong

OWASP LLM07 covers system prompt leakage: the application embeds secrets, internal policy, or sensitive instructions in the system prompt, and an attacker extracts them through prompt manipulation. The category gets misread as a prompt-injection variant. The actual lesson is architectural: anything the application would not publish should not sit in the system prompt at all. This article walks through the LLM07 mechanism, the leakage techniques that work in practice, and the architectural fix.

Problem-Awareai-securityowaspllm-securityprompt-injectionarchitecturesecrets-management
Read post →

OWASP LLM02: Insecure Output Handling and the Trust Boundary Most Apps Get Wrong

OWASP LLM02 covers insecure output handling: the application trusts the model output and passes it to a downstream sink (database, browser, shell) without classification or filtering. The result is SSRF, XSS, SQL injection, and command injection where the LLM is the unintended source. This article walks through the LLM02 categories, the trust-boundary error most applications make, and the gateway-layer controls that contain the blast radius.

Problem-Awareai-securityowaspllm-securityoutput-handlingarchitecturetrust-boundary
Read post →

EU AI Act Systemic-Risk Models: How the 10^25 FLOPs Threshold Triggers Article 55 Obligations

The EU AI Act treats a subset of general-purpose AI models as systemic-risk under Article 51, with the principal trigger set at 10^25 FLOPs of training compute. Models in that bucket inherit additional Article 55 obligations on model evaluation, systemic-risk assessment, serious-incident reporting, and cybersecurity. This article walks through the threshold mechanics, the Commission designation pathway, and the second-order obligations that flow to enterprise deployers integrating a systemic-risk model.

Compliance & Regulationeu-ai-actsystemic-riskcompliancegpairegulationfoundation-models
Read post →

EU AI Act Foundation Model Provider Obligations: A Reading of Articles 53-56 Before August 2

Articles 53 through 56 of the EU AI Act describe the provider obligations for general-purpose AI models. The obligations take effect August 2, 2026. They cover model documentation, downstream-deployer disclosure, copyright compliance, and additional safety, security, and post-market obligations for systemic-risk models. This article walks through the article-level requirements, the systemic-risk threshold, and the obligations that flow downstream to enterprise deployers that integrate the model.

Compliance & Regulationeu-ai-actfoundation-modelscompliancegpairegulationai-governance
Read post →

EU AI Act GPAI Code of Practice: What Foundation Model Providers Have to Sign Before August 2

The GPAI Code of Practice is the EU Commission instrument that operationalizes the August 2, 2026 General-Purpose AI obligations from the EU AI Act. Providers that sign the Code get a presumption of compliance with Articles 53 through 56. Providers that do not sign must demonstrate equivalent compliance by other means. This article walks through the Code chapters, the August 2 enforcement consequences, and what enterprise deployers downstream of a non-signatory provider need to add to their own control stack.

Compliance & Regulationeu-ai-actgpaicompliancefoundation-modelsregulationai-governance
Read post →

OWASP AISVS 1.0 Is Here: Which of the 514 Verification Requirements a Policy Gateway Enforces

OWASP released the AI Security Verification Standard (AISVS) 1.0 on June 24, 2026. The framework spans 14 chapters and 514 testable requirements, modeled after ASVS but covering prompt injection, MCP server authentication, supply chain, and runtime response handling. This article maps the gateway-relevant chapters to specific controls a stateless identity-aware policy proxy enforces, and separates them from the model, training, and supply-chain chapters that sit outside the gateway boundary.

Platform & Architectureai-securityowaspverificationpolicy-enforcementauditarchitecture
Read post →

AI Gateway Deployment Patterns: Four Topologies and When Each One Fits

Where an AI gateway sits in the network topology determines what it can enforce and what it can record. Four deployment patterns dominate production: inline reverse proxy in front of the model, sidecar to the agent runtime, in-region replicas for low-latency multi-region, and dedicated tenant gateway per customer in a multi-tenant SaaS. This piece walks through the four, what each enforces, what each records, and the operational trade-offs.

Platform & Architectureai-gatewayengineeringarchitecturedeployment-patternssre
Read post →

Agent-to-Agent Authentication: How One Agent Verifies Another at the API Boundary

Multi-agent systems route work between agents that authenticate to one another. The pattern that worked for service-to-service traffic (mTLS plus a shared service account) under-attributes the action. Agent-to-agent authentication needs the workload identity of the calling agent plus the delegation chain back to the natural person, plus per-call records that capture the chain. This piece walks through the three properties an agent-to-agent auth model must support, the token-exchange pattern that satisfies them, and where the policy decision lands.

Problem-Awareai-agentsauthenticationidentityengineeringmulti-agent
Read post →

AI Agent Tool Permissions: The Authorization Layer Between Reasoning and Action

An AI agent that holds the union of every tool permission its operating role might ever need is over-privileged on every call where the actual task uses only one tool. Tool permissions need a per-task authorization layer: identity of the requesting user, scoped delegation for the task, and a gateway decision per tool call. This piece walks through the four properties a tool-permission policy needs and where the policy decision lands at the AI request boundary.

Problem-Awareai-agentstool-permissionsauthorizationengineeringidentity
Read post →

Shadow AI for the CISO: The Three Boards a Detection Program Has to Cover

Cloud Radix data shows 90% of CISOs rank shadow AI as their top security concern for the year. The detection program has to cover three boards a typical detection stack does not look at: browser extensions, IDE plug-ins, and chat-platform apps. This piece walks through the three populations, the detection signal for each, the regulatory exposure under EU AI Act Article 26 and HIPAA, and the policy enforcement layer that closes the loop after detection.

Industry Verticalsshadow-aicisodetectionenforcementai-security
Read post →

What to Log for AI Compliance: The Eight Fields Every Per-Decision Record Needs

EU AI Act Article 19, Fannie Mae LL-2026-04, HIPAA, and SOC 2 with AI all converge on a per-decision record. The vocabulary differs across regimes. The fields do not. This piece walks through the eight fields every per-decision record needs to satisfy the converged requirement: identity of the natural person, identity of the agent, role and scopes, data classification, policy version, model and route, decision outcome, and a tamper-evident timestamp.

Compliance & Regulationai-audit-logscomplianceeu-ai-actauditregulation
Read post →

Non-Human Identity for AI Agents: Why Service Credentials Are the Wrong Primitive

Non-human identity covers the API keys, OAuth tokens, and workload identities that authenticate services and agents to APIs. AI agents have outgrown the static-service-credential model. A single agent can act on behalf of many users, hold delegated authority that varies by task, and produce decisions that need per-action attribution. This piece walks through the four properties an NHI for AI agents must have, why static API keys fail each of them, and how identity-bound policy at the AI request boundary closes the gap.

Platform & Architecturenon-human-identityai-agentsidentityengineeringnist-ai-rmf
Read post →