Blog

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

Prompt Injection in Production: Where It Happens, What It Costs, and How To Prevent It at the Request Boundary

Prompt injection is the class of attacks where adversarial content in a prompt overrides the application instructions or extracts data the model was not authorized to reveal. The attack surface includes direct user prompts, indirect injection through retrieved documents and tool results, and chained injection through agent loops. OWASP has consistently ranked prompt injection as the top LLM vulnerability. This piece walks through the attack mechanisms in production, the failure modes of model-side defenses, the request-boundary controls that produce a defensible posture, and the audit record format that holds up after an attempt is detected.

Problem-Awareprompt-injectionllm-securityai-securityinline-enforcementowasp-llmai-governance
Read post →

OWASP LLM01 Prompt Injection: The 2025 Update and What the Inspection Layer Enforces

OWASP LLM01 captures both direct and indirect prompt injection in a single category in the 2025 update. The architectural reason is that the control point is the same: the request boundary. Application-side defenses fail by construction because the application cannot tell which spans of the prompt the model treats as instructions. Model-side defenses fail because refusal training is probabilistic. This piece walks through the LLM01 attack surface, the inspection-layer controls that produce a defensible posture, the audit record that survives review under EU AI Act Article 12 and DORA Article 19, and the deployment pattern that fits a production AI stack.

Problem-Awareowaspllm01prompt-injectionllm-securityinline-enforcementaudit-logs
Read post →

OWASP LLM Top 10: How the 2025 Update Maps to Production AI Security Controls

The OWASP LLM Top 10 enumerates the application-security risks that show up when an LLM is wired into a production application. The 2025 update reorganized the list to reflect what production teams actually see: prompt injection at the top, sensitive information disclosure and supply chain risk close behind, and a new category for unbounded resource consumption. This piece walks each risk to the inspection layer control that produces a defensible posture, the gap each risk exposes in standard application-side defenses, and where the audit record series intersects EU AI Act Article 12 and DORA Article 19 evidence obligations.

Problem-Awareowaspllm-securityai-securityprompt-injectioninline-enforcementaudit-logs
Read post →

LLM Audit Logging: The Implementation Pattern That Holds Up Under Regulator Review

LLM audit logging implementations split along three architectural patterns: in-application logs, sidecar collectors, and inline inspection layers. The inline pattern is the only one that produces records the EU AI Act Article 12, DORA Article 19, and Fannie Mae LL-2026-04 reviewers accept because it is the only one that satisfies the write-path independence test. This piece walks through the three patterns, the architectural reason the first two fall short, the integration points the inline pattern requires, the field set the records have to carry, and the latency budget that fits a production deployment.

Problem-Awarellm-audit-loggingaudit-logsinline-enforcementeu-ai-actdoracompliance
Read post →

Jailbreaking LLMs: What the Attack Looks Like in Production and the Request-Boundary Defense That Holds Up

Jailbreaking is the class of attacks where adversarial prompts cause the model to disregard the safety training and produce content the provider intended to suppress. The attack catalog spans role-play framing, multi-step persuasion, encoded payloads, and the fine-tuning bypass that targets the refusal patterns directly. Stanford Trustworthy AI and the AIUC-1 Consortium research found that refusal behaviors degrade significantly under adversarial pressure. This piece walks through the attack patterns in production, why the model alone cannot defend, and the request-boundary controls and audit record format that produce a defensible posture.

Problem-Awarejailbreakingllm-securityai-securityinline-enforcementmodel-guardrailsai-governance
Read post →

Indirect Prompt Injection: How RAG and Tool-Use Pipelines Get Compromised Through Retrieved Content

Indirect prompt injection is the attack pattern where adversarial content reaches the model through a retrieved document, a tool result, or any other source the model treats as part of its context. The attacker never interacts with the application directly. The injection succeeds when the model executes the embedded instructions on the next retrieval or the next agent loop iteration. RAG pipelines and tool-using agents are exposed by construction. This piece walks through the attack mechanics, the surface area in production deployments, why the model alone cannot defend, and the request-boundary controls that produce a defensible posture.

Problem-Awareindirect-prompt-injectionragtool-usellm-securityai-securityinline-enforcement
Read post →

AI Security for RAG Systems: The Inspection Layer Between the Retrieval Output and the Model Call

Retrieval-augmented generation systems read documents from a vector store or a search backend into the model context window before the model reasons. The retrieval step is the point where the system pulls content of varying provenance, authorization, and trustworthiness into the prompt. The security boundary sits at the HTTP path between the retrieval output and the model call. This piece walks through the threat model RAG opens, the identity and authorization decisions the inspection layer commits, the audit record for retrieval-derived content, and the indirect prompt injection surface the retrieved documents expose.

Problem-Awareragai-securityindirect-prompt-injectionidentity-awareaudit-logsretrieval
Read post →

AI Security for Internal Copilots: The Identity, Data, and Audit Controls a Production Deployment Has To Run

Internal copilots reach across the organization with the user identity that opens the copilot session and the application identity that calls the model. The boundary between the two identities is where the security and audit obligations sit. This piece walks through the request-time data the copilot reads, the identity-aware policy decisions the deployment has to commit, the audit record format that survives EU AI Act and HIPAA review, and the architectural pattern that closes the post-authentication gap most internal copilots leave open.

Problem-Awareinternal-copilotai-securityidentity-awareaudit-logsinline-enforcementpost-authentication-gap
Read post →

AI Security for Customer Support Bots: The Inspection Layer Between the Bot and the Customer Data

Customer support bots reach customer records, payment data, account history, and PII at request time through tool calls and retrieval. The bot reads customer data into the LLM context window, the LLM reasons over it, and the bot acts on the result. The security boundary sits at the HTTP path between the bot and the upstream LLM and tool APIs. This piece walks through the data flows the bot exercises in production, the identity and authorization decisions the inspection layer commits, the audit record the customer auditor and the regulator consume, and the prompt-injection surface that retrieved customer content opens.

Problem-Awarecustomer-support-botai-securityidentity-awareaudit-logsindirect-prompt-injectionpii
Read post →

AI Audit Logs: The Format Spec That Survives EU AI Act, DORA, and Fannie Mae Review

AI audit logs that survive regulatory review carry a specific set of fields the EU AI Act Article 12, DORA Article 19, Fannie Mae LL-2026-04, NIST AI RMF, and HIPAA all expect on the same record. The fields cover identity, decision provenance, model identity, policy state, and integrity metadata. The format has to support per-record retrieval and per-series replay. The write path has to sit outside the application so the application cannot modify the record. This piece walks through the field-level format specification, the integrity model, the storage characteristics, and the deployment pattern that produces records the regulator and the customer auditor will accept.

Problem-Awareai-audit-logsaudit-logseu-ai-actdoracomplianceinline-enforcement
Read post →

The Accountability Gap in Agentic AI Pipelines: Who Owns the Decision When the Agent Acts

Agentic AI pipelines compose multiple model calls, tool invocations, and external retrievals into a single autonomous workflow. The compositional structure produces an accountability gap: the record series the application keeps shows the workflow outcome, the record series the model provider keeps shows the inference call, and neither shows who authorized the agent to act with whose authority at the moment of action. This piece walks through where the gap appears in production pipelines, the structural reason application logs cannot close it, and the inspection-layer record series that produces a defensible answer.

Problem-Awareagentic-aiai-agent-accountabilityaudit-logsinline-enforcementnist-ai-rmfai-security
Read post →

Langfuse Alternatives: How to Pick a Different LLM Observability or Enforcement Layer

Langfuse is an open-source LLM observability platform that captures application traces (prompts, completions, spans, evaluations, scores) via in-process SDKs. Teams that want a proxy-based observability product, a hosted gateway with observability bundled in, a managed evaluation platform, an MLflow-anchored experimentation workflow, or identity-bound policy enforcement for regulated workloads pick a different layer. This piece walks through the credible Langfuse alternatives across five use cases and where each one fits.

Comparisons & Alternativeslangfusellm-observabilityalternativescomparisoninline-enforcementeu-ai-act
Read post →