Zero-Trust enforcement for enterprise AI.

DeepInspect authorizes, redacts, or blocks every AI request inline, then writes a cryptographically signed forensic record for regulatory defense.

CALLERUsersApplicationsAgentsrequestDEEPINSPECT GATEWAY< 50ms · fail-closedIdentityrole · env · tokenData classPII · PHI · PCIPolicy v12per-role action mapallowredactblockUPSTREAMModelsMCP toolsProvidersSIGNED FORENSIC RECORDidentity · policy · payloads · hmac

Who Owns AI Governance Liability in an Enterprise?

AI governance is a responsibility boundary. Regulators and boards want enforcement records, not dashboards.

The boundary falls on the enterprise rather than the model provider. Provider terms of service place contractual responsibility for how a model is used inside a customer environment on the customer. A regulatory inquiry about a specific AI decision reaches the CISO and the compliance officer, and the durable answer is a runtime record of how each AI request was handled together with the policy version in effect at the time.

Enterprises own:

Regulatory exposure
Audit outcomes
Breach narratives
Board accountability

Each obligation maps to an operational record only the enterprise can produce. Regulatory exposure resolves when the enterprise shows the specific decisions the system made and the policy versions in effect. Audit outcomes improve when the auditor reads records that each carry a per-record cryptographic signature verifiable on its own. Breach narratives hold together when every AI interaction in the sequence carries its own integrity proof. Board accountability follows the pattern of financial controls, signed attestations rather than best-effort summaries.

Governance requires reconstruction of who accessed what data and why a decision was allowed.

The risk lives in ungoverned AI usage inside your enterprise.

Recent thinking.

All posts →

September 5, 2026

Llama Security: What Llama Guard, IAM Scoping, and the License Actually Cover

Securing a Llama deployment layers three separate mechanisms: Llama Guard and Prompt Guard filtering content, cloud-native IAM or RBAC scoping which identity can call the model, and Meta'"'"'s Acceptable Use Policy setting legal boundaries on use. None of the three evaluates a specific request against an enterprise'"'"'s own policy at the moment it is made. Two 2026 CVEs in the serving layer underneath Llama show what that gap costs.

Read →

September 5, 2026

Llama Audit Logs Depend Entirely on Which Hosting Layer You Picked

Llama is an open-weight model with no logging of its own, so audit logging for a Llama deployment depends entirely on the hosting layer. AWS Bedrock offers detailed model invocation logging that ships disabled by default. Azure AI Foundry routes similar detail through diagnostic settings that must be explicitly configured. Self-hosted deployments on vLLM or TGI have no audit logging at all until a team builds it. This article separates the three paths.

Read →

September 5, 2026

LangChain and LangSmith Audit Logs: Why the User ID Field Is Not an Identity Check

LangSmith traces every LangChain LLM call in detail: messages, tool calls, token counts, and custom metadata. The user_id and session_id fields that group those traces into threads are optional strings a developer chooses to attach, not values LangSmith verifies against an identity provider. This article separates trace completeness from identity verification and lists what a security review should check before relying on either.

Read →