Skip to content

PATTERN Cited by 1 source

Runtime governance enforcement layer

Shape

Place an enforcement layer between the agent workflow and every system it touches. Every proposed action — tool invocation, dataset access, model call — routes through this layer first. The layer:

  1. Captures the proposed action as a multidimensional trace record.
  2. Reads live workflow context from a knowledge graph of everything this workflow has already touched.
  3. Evaluates the action against policy using that live context.
  4. Returns allow / deny / modify synchronously.
  5. Writes the decision (and the underlying action, if allowed) back to the graph so the next action in the workflow sees it.

The defining property is synchronous gate before execution — steps 1–4 complete before the downstream action runs. Latency is architecturally load-bearing: the layer must not add meaningful overhead to agent execution.

┌────────────────┐                 ┌────────────────────┐
│ agentic        │  action         │ enforcement layer  │
│ workflow       │ ──────────────► │ (LangGuard-shape)  │
│ (plan, tools,  │                 │                    │
│  models)       │ ◄───────────────│ allow / deny /     │
└────────────────┘   decision      │ modify             │
                                   │                    │
                                   │ reads: live GRAIL  │
                                   │         + policy   │
                                   │ writes: trace      │
                                   └────┬───────────────┘
                                        │
                                        ▼ on "allow"
                             ┌──────────────────────────┐
                             │ 15+ systems of record    │
                             │ (ServiceNow, IAM, CRM,   │
                             │ HR, Wiz, MCP, API GW...) │
                             └──────────────────────────┘

(Source: sources/2026-04-27-databricks-inside-one-of-the-first-production-deployments-of-lakebase-langguard)

When it fits

  • Autonomous agents acting across multiple systems of record — the logic is generated on the fly; pre-registering every legal action sequence is infeasible.
  • Consequences are irreversible or expensive to reverse — sending email, authorising transactions, deploying configuration. Post-hoc audit is not enough.
  • Cross-system blast radius — a misconfigured permission on one system exposes data that cascades into others.
  • Live workflow context matters — whether an action is in policy depends on what the workflow has already done, not just per-request attributes.

When it doesn't fit

  • High-throughput data-path traffic — placing a synchronous graph-query policy engine on every byte of traffic is not viable; governance here should be design-time + sampling.
  • Workloads where post-hoc audit is acceptable — back-office batch, analytical workloads where the action's consequences are contained and reversible.
  • Single-system + static-role access control — if the question is "is this role allowed to touch this resource?" and the answer doesn't depend on what happened earlier, plain access control is the right tool.

Substrate requirements

The enforcement layer's substrate must support:

  • Bursty write + read shape — agent workflows fire in bursts, so the policy engine's substrate needs to autoscale (see concepts/scale-to-zero and LangGuard's choice of Lakebase).
  • Millisecond indexed reads on hot working set — live workflow context + policy subset must be queryable fast enough to stay off the agent's latency budget.
  • Live write-visible state — writes from the decision (trace records + decisions) must be visible to subsequent reads in the same workflow immediately; stale-read windows break cross-action reasoning.
  • Branching for policy testing — new policies must be validated against real trace data without touching production state (see patterns/policy-testing-via-database-branching).

Relationship to adjacent patterns

  • patterns/embedded-opa-in-proxy — the narrow-waist HTTP-altitude analogue: an inline proxy runs an OPA-based policy engine on HTTP requests. Runtime governance enforcement at agent altitude is structurally similar (inline, synchronous, policy-as-code), but operates on semantic actions (tool call, dataset read, model invocation) rather than HTTP requests, and maintains live workflow context across actions.
  • patterns/enforcement-throttler-proxy — Vitess-side enforcement primitive at the query altitude; same synchronous gate shape, different decision surface.
  • patterns/circuit-breaker — a degenerate case where the policy is "are downstream errors elevated?" and the decision surface is binary allow/deny. Runtime governance is the three-valued (with modify), policy-rich generalisation.

Canonical instance

systems/langguard on Lakebase — LangGuard intercepts every agent tool/data/model invocation; the GRAIL data fabric holds the live workflow behavior graph on Lakebase Postgres; policy evaluation reads from the graph and returns allow/deny/modify before the action executes. Governs workflows that span 15+ Systems of Record (ServiceNow, IAM/IDP, Salesforce, Workday, Wiz, CrowdStrike, TalkDesk, MCP Gateways, API Gateways).

Scale framing: "tens of coordinated agents, hundreds of tool invocations, multiple foundation models" per workflow. Built by former IBM QRadar SIEM engineers; the QRadar experience is cited as the empirical prior on "database architecture is destiny" for bursty security-telemetry-shaped workloads.

Failure modes

  • Latency injected onto agent critical path. If policy evaluation takes even 50 ms, it's felt in every agent action; the substrate must bring this to single-digit ms.
  • Live context stale-read. If step 2 reads an out-of-date snapshot of the workflow graph, cross-action policies misfire.
  • Policy engine as single point of failure. An outage in the enforcement layer blocks every agent action — requires HA design or a graceful-degradation mode (fail-open on non-critical actions; fail-closed on high-risk).
  • Over-permissive modify defaults. If "modify" quietly redacts without surfacing the redaction, workflows may depend on data they can't legally see.

Seen in

Last updated · 434 distilled / 1,256 read