How AutoPIL Detects Every Data Source Your Agent Touches

Governance only works if you know what you're governing. That sounds obvious, but it's where most AI governance implementations quietly fail. You wrap your LangChain retriever with a policy guard, you watch the audit log fill up with decisions — and you feel covered. Then someone on your team connects an agent directly to a PostgreSQL database using psycopg2, or wires up a Kafka consumer, and none of that ever appears in the governance layer.

The problem is architectural. SDK-based guards only see traffic that passes through the SDK. If the data access doesn't go through LangChain, LlamaIndex, or your REST API middleware, it's invisible to a guard that lives there. This is especially acute with direct database connections — PostgreSQL wire protocol on port 5432 doesn't look like an HTTP request, and no API gateway is going to intercept it.

We spent a significant amount of time mapping out exactly where these gaps exist and what it would take to close them. What follows is an honest accounting of where AutoPIL's coverage stands today and how we're building toward complete source visibility.

The Three-Stage Model

Complete source coverage requires three distinct mechanisms operating at different points in the agent lifecycle. No single approach covers everything.

Each stage catches what the others miss. Stage 1 is the only way to detect TCP-protocol sources like direct database connections before they ever make it to production. Stage 2 gives you per-call policy enforcement with full context. Stage 3 provides a safety net for anything that bypasses the SDK layer entirely.

What's Covered Today

Stage 2 — SDK and gateway coverage — is fully built. The matrix below shows where things stand across the most common data source categories.

The pattern is clear: anything that speaks HTTPS is well covered today. Anything that speaks a native TCP wire protocol — PostgreSQL on 5432, MySQL on 3306, Kafka on 9092, MongoDB on 27017 — has a gap at the SDK and gateway layers.

The Gateway Layer

For HTTP-based sources, we've built native plugins for the three most common enterprise API gateway platforms:

• Kong Gateway 3.x — a Lua plugin that intercepts requests in the access phase, with path wildcard route rules and a shadow mode for testing policy without enforcement
• AWS Lambda Authorizer — a REQUEST-type authorizer for both API Gateway v1 (REST) and v2 (HTTP) with zero external dependencies and a Terraform module included
• Apigee X — a JavaScript policy with a Java callout for organizations running Google's enterprise gateway, with KVM-based config and encrypted secrets

These three cover the majority of enterprise API gateway footprints. Every request that passes through any of them is evaluated against AutoPIL policy before it reaches the data layer. The source_type="gateway" stamp on the audit event tells you exactly which path the request took.

Stage 3: Why the Sidecar Matters

The SDK and gateway layers share a common dependency: the developer has to wire them in. That's a reasonable ask for greenfield agent development, but it's a real problem for agents built by teams that didn't know governance was a requirement, or for agents that evolve over time to include new data connections.

The Envoy ext_authz sidecar operates at the container network layer. It intercepts every outbound call regardless of how the code was written. You deploy the sidecar alongside your agent container, and from that point forward, every outbound connection — HTTP or TCP — is visible.

The architecture is straightforward: the sidecar implements the envoy.service.auth.v3 gRPC interface, translates each outbound connection into an AutoPIL evaluate request, and enforces policy before the connection completes. For HTTP traffic this gives full L7 visibility — path, headers, method. For TCP traffic on known ports (5432, 3306, 1521, 27017) it gives L4 block/allow plus source identification from port pattern matching.

A Coverage Score, Not Just an Audit Log

The most useful thing we can do with all of this detection is give teams a number. Not just "here are your audit events" but "here is your coverage confidence" — a score derived from combining what the static scan found with what the runtime audit log actually observed.

An agent that the scanner detected as having a PostgreSQL connection, but for which no PostgreSQL activity has ever appeared in the audit log, is an agent with a coverage gap. Maybe that connection is never actually used. Maybe it bypassed the governance layer entirely. Either way it deserves a flag, not silence.

This is live as GET /v1/agents/{id}/coverage. The report classifies every source an agent has touched into one of four buckets: permitted and accessed (clean), accessed but not registered (governance blind spot), accessed but not permitted (policy gap), and permitted but never accessed (dead permission). Each bucket feeds directly into your coverage score, and you can set an uncovered_host alert rule to fire the moment an agent starts reaching unregistered sources in production.

Where This Lands

As of July 2026: all HTTPS sources are covered end-to-end. The gRPC ext_authz server (Stage 3 Phase 1) is live — every outbound HTTP call from an agent container is intercepted and policy-evaluated before it completes. The per-agent coverage score and uncovered_host alert rule are live in the dashboard. TCP sources (Postgres, MySQL, Mongo, Redis) are caught at design time by the static scanner.

What's still ahead: a hot-reload source inference engine for custom endpoint mappings, Envoy and Istio configuration YAMLs in integrations/envoy/, and a Helm chart. Those are gated on the first enterprise Kubernetes deployment — the gRPC server is a working prerequisite that makes the customer conversation real.