Published on

Securing the Inference Lifecycle

Authors
  • avatar
    Name
    Parminder Singh
    Twitter

On March 18, Meta's internal AI agent exposed sensitive user and company data to engineers who shouldn't have seen it. The issue was classified as Sev-1 and lasted for two hours. The agent was fully authenticated, had valid tokens and passed every identity check. And it still caused a data breach.

Meta AI Agent Photo by Pawel Janiak on Unsplash

IAM

The agent had a valid token and as per IAM policy, it was allowed to access the model. But IAM doesn't evaluate what the identity does once it's inside. It doesn't inspect the request payload. E.g. it doesn't know if the agent is asking the model to summarize public documentation or to retrieve classified customer records. Crucially, IAM has no visibility into identity propagation—it sees the agent's service account, but it doesn't necessarily understand the permissions of the end-user driving the agent.

Model guardrails

Model guardrails answer a different question: Is this request harmful? Safety filters block requests for malware, hate speech, or illegal content. But a request like "retrieve all records where status = 'inactive'" isn't "harmful" in a safety context. A request like "summarize the engineering thread about authentication" is a normal business query and the model has no reason to refuse it.

Post-authentication gap

So the gap is between "authenticated" and "safe".

An agent passes IAM and calls the LLM. At no point is there a stateful evaluation of the transaction:

  • Does this specific identity have the clearance to ask this specific question?
  • Does the prompt contain PII or secrets that should never reach a third-party or internal model?
  • Does the response, whether retrieved via RAG or generated through inference, contain data that exceeds the caller's clearance?
  • Is there an immutable, out-of-band audit record of the full exchange?

In the Meta incident, the answer to all four was "unknown." There was no Policy Enforcement Point (PEP) between authentication and model invocation.

Per request policy enforcement

The missing control is per-request policy enforcement at the AI API layer.

This is a distinct architectural layer that sits between your application and the LLM. To be effective at scale, this layer must function as a high-performance proxy that evaluates every request and response against organizational policy in real-time.

The Architecture:

  1. Identity-Aware Request: The application makes an API call. The proxy extracts the identity context (JWT, forwarded headers) and the payload.
  2. Inbound Inspection: The proxy evaluates the prompt. If sensitive data or classified markers are detected and the user lacks clearance, the request is redacted or blocked before it reaches the model.
  3. Low-Latency Pass-Through: If the policy passes, the request proceeds to the LLM.
  4. Outbound Response Interception: As the model responds, the proxy scans the completion.
  5. Pre-Custody Audit: Before the application receives the response, the proxy writes an immutable audit record: identity, prompt, response, and policy decision.

By writing the audit log before the application has custody of the data, you ensure non-repudiation. The application cannot modify or omit the record of what happened.

Regulated environments

If you're in healthcare, finance, or government, you already enforce data classification at the storage and network layers. You have DLP at the email gateway.

But AI is the new egress point. A user can query an LLM that has access to sensitive data, and the response flows back without ever hitting your traditional DLP stack. The model doesn't know your classification scheme. It doesn't know that a specific user shouldn't see a specific customer's history.

The post-authentication gap is where your compliance posture breaks down.

The Liability Gap

In 2026, a "Sev-1" is a legal event. Whether it's the EU AI Act's mandate for traceability or the SEC's updated disclosure rules for data breaches, the burden of proof remains. If you can't prove exactly what was sent to a model or what the model sent to a specific user—and that you took "reasonable steps" to prevent a policy violation—the liability rests squarely on the organization.

Compliance by Design

You can't solve a real-time data flow problem with a static IAM policy. To stay compliant, you need a control surface that understands the content of the conversation.

DeepInspect.ai acts as that control surface. We don't just "monitor" for compliance; we enforce it at the API layer:

  • Redaction in Transit: Automatically scrub PII, secrets, or classified markers before they hit the model or return to the user.
  • Tamper-Proof Evidence: We write the audit log before your application even sees the response. It's an immutable record that stands up to an audit.
  • Policy as Code: Turn complex legal requirements (like HIPAA's "Minimum Necessary" or GDPR's "Data Minimization") into executable rules that block non-compliant prompts in milliseconds.

The post-authentication gap is a choice. You can either wait for your first Sev-1 to realize your IAM is insufficient, or you can build governance into your stack today.

DeepInspect.ai sits at the AI API layer, enforcing per-request policies based on identity, role, and data classification. Our high-performance gateway ensures your security and compliance posture scales without the latency tax.