← All posts

Problem-Aware

202 posts on problem-aware.

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.

ai-agentsauthenticationidentityengineeringmulti-agent
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.

ai-securityowaspllm-securityoutput-handlingarchitecturetrust-boundary
Read post →

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.

ai-securityowaspllm-securityprompt-injectionarchitecturesecrets-management
Read post →

OWASP LLM03 Training Data Poisoning: Why the Defense Lives Outside the Gateway

OWASP LLM03 covers training and fine-tuning data poisoning: an attacker contaminates the data the model learned from, and the contamination becomes a property of the model. The defense lives in the data and model supply chain, upstream of any runtime gateway. A policy gateway cannot un-poison a model, but it sits in the right place to detect the downstream behavior a poisoned model produces and to block the actions that behavior would trigger. This article walks through the LLM03 mechanism, where the gateway helps, and where it does not.

ai-securityowaspllm-securitydata-poisoningsupply-chainarchitecture
Read post →

OWASP LLM04 Model Denial of Service: Gateway Controls That Actually Hold Under Load

OWASP LLM04 covers model denial of service: resource-exhaustion attacks that exploit the cost asymmetry between issuing a prompt and serving it. A single user can drive an LLM workload to consume orders of magnitude more compute, tokens, or wall-clock time than a benign request. The defense is rate-limiting and shaping at the boundary where every request is visible. This article walks through the LLM04 attack patterns, the gateway controls that hold under load, and the metrics to instrument.

ai-securityowaspllm-securityrate-limitingai-gatewaycost-management
Read post →

OWASP LLM05 Supply Chain Vulnerabilities: Mapping the Surface a Gateway Can Cover

OWASP LLM05 covers supply chain vulnerabilities across the AI stack: model weights from public hubs, serving frameworks with their own CVE histories, third-party tools the agent calls, dependencies in inference dependencies. The defenses split across the supply chain itself, the runtime, and the network boundary. A policy gateway covers the network-boundary piece. This article maps the LLM05 surface, sorts the controls by which layer enforces each one, and shows what an identity-aware gateway adds.

ai-securityowaspllm-securitysupply-chainai-bomvulnerability-management
Read post →

OWASP LLM08 Excessive Agency: Bounding What an Agent Is Allowed to Actually Do

OWASP LLM08 covers excessive agency: the AI agent has the ability to take actions that exceed what the application or the user intended. The category is the agentic equivalent of the post-authentication gap: authentication and authorization happened, but the action the agent took was not the action the authorization actually permitted. The control point is the boundary between the agent loop and the tool surface. This article walks through the LLM08 mechanisms, the agency-bounding controls a gateway enforces, and where the architecture differs from classic API authorization.

ai-securityowaspllm-securityagentic-aiauthorizationtool-permissions
Read post →

MCP Tool Poisoning Prevention: Gateway Controls for the Model Context Protocol Surface

Model Context Protocol tool poisoning is the agentic analog to supply-chain compromise. An MCP server presents a set of tools to an agent host; an attacker who controls the MCP server (or the tool definitions an MCP server advertises) can change what the tools do, what they return, or what parameters they accept. The agent loop calls the tool in good faith and the actions executed against downstream systems are the attacker'"'"'s. The prevention surface splits across MCP server selection, tool-definition pinning, and per-decision authorization at the agent-tool boundary. This article walks through the MCP poisoning patterns and the gateway controls that contain them.

mcpai-securityagentic-aitool-permissionssupply-chainai-gateway
Read post →

MCP Confused Deputy: Why the Server Acting on the User Is the Wrong Principal

The confused deputy attack describes the case where a privileged intermediary acts on behalf of a less-privileged caller and ends up doing things the caller could not have done directly. In the Model Context Protocol (MCP) world, the confused deputy lives in the MCP server. The MCP server holds credentials for upstream tools and acts on behalf of an LLM client. When the client identity is not propagated to the upstream calls, the upstream services see the MCP server, not the user, and authorization decisions get made against the wrong principal. This article walks the attack pattern, the architectural cause, the controls a policy gateway enforces at the MCP boundary, and the operational checklist.

mcpconfused-deputyauthorizationagentic-aipolicy-enforcementsecurity
Read post →

RAG Poisoning Prevention: Defending the Retrieval Layer Against Adversarial Content

Retrieval-augmented generation grounds an LLM response in a corpus of documents the application retrieves at query time. The retrieval surface is also an attack surface. An attacker who can write to the corpus or to a source the corpus ingests from can inject content that steers the model toward attacker-chosen outputs. RAG poisoning has three production patterns: corpus injection, indirect prompt injection through retrieved content, and adversarial document crafting that pollutes the embedding space. This article walks the failure modes, the defense layers, the controls a policy gateway enforces against the model-call boundary, and the operational checklist.

ragprompt-injectionllm-securityagentic-aipolicy-enforcementdata-poisoning
Read post →

AI Usage Policy Template: The Clauses That Actually Get Enforced at the Gateway

Most AI usage policies get written as documents and stored in a compliance drive. The document alone changes no request that leaves the employee's browser and reaches ChatGPT, Claude, or a shadow copilot. The clauses in this template are the ones that map to enforcement at the AI request layer, where a policy statement translates into a permit-or-deny decision on live traffic. The template covers scope, sanctioned providers, data classes prohibited from AI prompts, allowed use cases per role, monitoring, incident reporting, and the enforcement mechanism that binds the policy to the traffic. Adopt the template as the policy artifact, then wire the clauses to the gateway that produces the audit records the policy owner samples at quarterly review.

shadow-aiai-policypolicy-templateai-usage-policygovernanceciso
Read post →

AI Jailbreak Monitoring: Detecting the Prompts That Bypass Model Guardrails in Production Traffic

Jailbreak attempts against production LLM deployments have moved from novelty to routine traffic. Attackers, curious employees, and automated red-team tools all produce prompts intended to bypass the model's built-in safety layers. Detection at the model provider catches some patterns but not the enterprise-specific patterns tied to the deployer's own system prompt and policy configuration. Detection at the AI gateway catches both categories. This piece walks through the four detection surfaces (input pattern, response deviation, session behavior, follow-through action), the signals each surface produces, and the SIEM integration that lands the detection in the SOC's existing workflow.

jailbreakai-securityprompt-injectionsiemthreat-detectionmonitoring
Read post →