In-process runtime observability vs. proxy & network-based AI controls

Published August 20, 2026 · 9 min read

Enterprises rolling out AI agents are stacking up governance tools fast: a GRC platform for the compliance story, a network gateway for traffic inspection, and increasingly, something running inside the agent itself. These aren't competing choices — they watch from different vantage points, and each is structurally blind to what the others see. Here's the actual boundary between them, and where it matters most.

Governance and network controls: a view from outside the process

Two distinct categories have grown up around AI risk, and it's worth separating them before comparing either to in-process controls:

AI governance and compliance platforms — Credo.ai, Trustible, and Monitaur are the ones enterprises reach for first — operate at the program level. They maintain a model/agent inventory, run risk and impact assessments, map controls to frameworks like the EU AI Act and NIST AI RMF, and produce the audit evidence a legal or risk team needs. This is essential work, and it runs on a documentation and review cadence: point-in-time assessments, periodic audits, policy sign-off. It answers "do we know what AI systems we operate, and can we prove we're managing them responsibly?" — a question no amount of code instrumentation answers by itself.

Network and proxy-layer security — Lasso Security and similar LLM gateways — sit inline on the network path between an application and a model provider. They inspect the traffic that crosses that boundary: scanning for secrets and PII patterns, flagging known prompt-injection strings, enforcing rate limits. Because they operate at the network egress point, they cover every application that routes through them, regardless of language or framework, without touching a line of app code.

These two categories differ in almost everything — cadence, artifact, audience — but they share one structural trait that matters for this comparison: both sit outside the application's own process. One reads documentation and periodic exports; the other reads bytes on the wire. Neither executes inside the agent's runtime alongside the code that holds the request's actual identity and business context.

In-process runtime observability: a view from inside

In-process observability and governance — the pattern behind tools like OpenTelemetry-based tracing, and enforcement layers like Parapet — runs as middleware inside the agent's own execution, in the same memory space as your application code. It doesn't need traffic to cross a network boundary to see it, because it's already there when the tool call is constructed: the function name, the arguments before serialization, the caller's session object, and whatever identity your app's own authentication layer already resolved before the agent ever started reasoning.

That vantage point is what makes two things possible that are structurally out of reach from outside the process: authorizing (or denying) an individual action before it executes rather than after the fact, and doing so using identity that was never serialized onto the wire in the first place.

The actual boundary: what's on the wire vs. what's in the app

A network proxy or gateway can only act on what arrives in the HTTP request: headers, payload, and the credential attached to it — typically a shared API key or service credential. If your application forwards a user ID in a custom header, the proxy can read that header. But it cannot independently verify that the header is accurate, that it wasn't set by a bug, or that the human it names is actually authorized for this specific record — because the session, the role, and the authorization state all live inside the application, one hop upstream of where the proxy sits. Wiring a proxy to re-verify identity against your identity provider on every call is possible, but it means re-implementing, outside the trust boundary that already has the answer, a check your app's own auth layer already performed.

The same gap shows up with non-human identity. Enterprise deployments increasingly run several distinct agents — a scheduling agent, a refunds agent, an internal-tools agent — that often share the same outbound network path or the same service-level API key. From the wire, that traffic can be indistinguishable: same route, same credential, same destination. In-process, each agent's own identity is simply available — it's the object the code was constructed with — with nothing to infer.

None of this is a shortcoming in the governance or network products; it's a consequence of where they're deployed. A control that lives at the network edge or in a compliance dashboard was never meant to reach into a specific function call's arguments or the session object your app's auth middleware already validated. That data doesn't cross the boundary those tools observe.

Side-by-side: what each layer can see

Positioning based on how these categories describe themselves publicly as of 2026; individual products evolve and some add capabilities across categories. The durable distinction is vantage point: outside the process vs. inside it.

Benefits and trade-offs of each

GRC / compliance platforms give you the artifact regulators, auditors, and your own risk committee actually want: an inventory of what AI you run, an assessment of its risk, and evidence you're managing it. No engineering integration required to get started, and the same platform covers agents built in any language. The trade-off is cadence: it's built for periodic review, not for stopping an individual bad tool call in the second it happens.

Network / proxy gateways give you broad, low-friction coverage: point traffic at the gateway and every app that uses it gets secret-scanning, injection detection, and rate limits, with no per-app SDK to install. The trade-off is depth: they see the wire, not the app, so anything that depends on session state, role, or business data that never gets serialized into the request is out of reach — and any app or tool call that doesn't route through the gateway isn't covered at all.

In-process runtime layers give you the opposite trade-off. Because they run inside the agent, they can authorize a specific action for a specific identity using the app's own context, before the action executes, with no network round trip. The cost is integration surface: it has to be added per language and framework, and it only covers the process it's embedded in — it says nothing about the model/agent inventory or risk narrative your compliance team needs to hand an auditor.

Where identity-scoped rules need the inside view

The clearest way to see why the in-process vantage point matters isn't abstract — it's in the specific rules enterprises actually want to enforce, several of which simply have no wire-level or documentation-level equivalent:

• Financial services — refunds scoped to assigned book of business. "This support agent may issue a refund only for accounts in the requesting user's assigned queue." The queue assignment lives in the app's own data model; a network gateway sees a refund API call and a shared service credential, not whose queue the account is in.
• Healthcare — PHI access scoped to an active care relationship. "This clinical documentation agent may retrieve a patient's record only if the logged-in clinician has an open care relationship with that patient." That relationship is an in-app RBAC/ABAC fact, not something present in the request payload a proxy inspects.
• Internal IT/DevOps — distinguishing scheduled automation from a human-initiated request. A maintenance agent running on a cron schedule and the same agent invoked mid-session by an on-call engineer can generate near-identical outbound traffic through a shared credential. In-process, the two are different identities by construction — one is a service principal, the other carries a specific engineer's session — and can carry different risk policies. On the wire, they can be indistinguishable.
• Multi-tenant SaaS — row-level scoping to tenant and end-user. "This agent may only read or write records belonging to the current tenant, filtered further to what this specific end user is permitted to see." Tenant and permission context is application state; a network boundary that only sees API traffic to a model provider has no way to evaluate a rule phrased in terms of it.

None of these is a defect in a GRC platform or a network gateway — they were never designed to evaluate a rule phrased in terms of application-internal state, because that state doesn't reach the vantage point they observe from. It's a boundary, not a bug.

Why they're complementary, not competing

Each layer catches what the others are structurally unable to:

• The GRC layer catches the question a network trace or a decision log can't answer on its own: "do we even know every AI system we operate, and can we prove we're managing the risk?" That's an organizational and evidentiary problem, not a runtime one.
• The network layer catches misconfigured or unknown applications that bypass in-process controls entirely, and pattern-based risks — leaked secrets, known injection strings — regardless of which app or framework produced the traffic.
• The in-process layer catches per-identity, per-action authorization that depends on data that was never on the wire and never in a compliance document: who the real human is, which specific agent is acting, and the business context that determines whether this particular action, for this particular identity, right now, should be allowed.

A mature AI governance posture in 2026 tends to use all three: a compliance platform for the inventory and audit story, a network gateway for fleet-wide traffic hygiene, and an in-process layer for the identity-and-action-specific decisions that only exist where the identity and the action actually meet.