Runtime Governance for AI Agents

Runtime governance for AI agents is the practice of enforcing policy at execution time — deciding whether a model call, a provider route, a fallback, or a tool execution is allowed to happen, and recording that decision as evidence.

The one-sentence distinction that drives this page:

Observability records what happened. Governance decides what was allowed to happen — before it happens.

Why "At Runtime" Matters

Prompt engineering can ask a model to behave. Documentation can recommend that developers follow rules. Neither can decide at the moment of execution whether a specific tool call with specific arguments may run.

Governance becomes a runtime concern at the moment the AI system can do something irreversible:

write data
send email
delete records
create payments
invoke MCP tools
call external APIs

At that point, "we told the model not to" is not a control. A runtime enforcement point is.

The Enforcement Chain

A governed execution passes through a sequence of decisions. TramAI implements each stage:

classify
   → constrain
   → select
   → authorize
   → approve
   → execute
   → observe
   → evidence

Stage	Question	TramAI mechanism
Classify	What kind of data is this?	DLP interception and data classification
Constrain	Which models, providers, tools are allowed at all?	Sovereign profile allowlists (models, providers, fallback providers, tools, permissions)
Select	Which provider may handle this data?	Trust-zone routing (`LOCAL` / `EU_CLOUD` / `GLOBAL_CLOUD`) and classification-aware `ProviderRoutingConfiguration`
Authorize	Is this call permitted right now?	Policy engine at `BEFORE_PROVIDER_RESOLUTION`, `BEFORE_PROVIDER_INVOCATION`, `BEFORE_TOOL_EXPOSURE`, `BEFORE_TOOL_EXECUTION`, `BEFORE_TOOL_RESULT_REINJECTION`, `BEFORE_FALLBACK`
Approve	Does a human need to decide?	Approval gate with `RequireApproval`, suspend/resume lifecycle
Execute	Run the call	Engine executes within the governed boundary
Observe	What happened?	OpenTelemetry spans/metrics, engine events
Evidence	Prove it stayed within policy	Hash-chained audit events, `policy.decision` and `tool.permission` evidence exporters, evidence packs

Enforcement Points in TramAI

The policy engine evaluates Allow, Deny, or RequireApproval at six enforcement points:

Enforcement point	What it gates
`BEFORE_PROVIDER_RESOLUTION`	Model resolution and allowlist check
`BEFORE_PROVIDER_INVOCATION`	The actual provider HTTP/stream call
`BEFORE_FALLBACK`	Falling back to an alternative provider
`BEFORE_TOOL_EXPOSURE`	Whether tool definitions are exposed to the model
`BEFORE_TOOL_EXECUTION`	Whether the tool call may actually run
`BEFORE_TOOL_RESULT_REINJECTION`	Whether tool results are fed back into the model context

A denial at any point stops the execution and is recorded as evidence. Exposure permission is not execution permission: a tool can be visible to the model (to plan around) while its execution is denied or gated behind human approval.

Governed Fallback

Fallback is a governance decision, not just a resilience feature. In TramAI:

Fallback providers must be in allowedFallbackProviders, a subset of allowedProviders.
The BEFORE_FALLBACK enforcement point lets policy intercept the fallback itself.
In the sovereign profile, RESTRICTED data has no fallback — if the local provider fails, the request fails rather than silently crossing a trust boundary.

This is the difference between "resilient" and "governed": a governed system knows where the fallback may go.

Observability vs Governance: Seeing Is Not Enforcing

Teams often discover governance through observability. They add tracing, see a surprising tool call, and ask "how do we prevent that?" — at which point they need enforcement, not more dashboards.

	Observability	Governance
When it acts	After the fact	Before and during
Question it answers	What happened?	What is allowed to happen?
Failure mode	You learn about the violation	The violation never happens
Artifacts	Logs, traces, metrics	Policy decisions, approval records, evidence
Example	"A payment tool was called at 14:03"	"The payment tool call was DENIED at 14:03 by policy `payments-disabled`"

TramAI ships both — native OpenTelemetry observability and a policy engine — because production AI needs the pair. But the governance boundary is the part that prevents the incident.

Tradeoffs

Runtime governance costs something:

Configuration — allowlists and profiles must be declared and maintained.
Validation — fail-fast build-time checks reject invalid profiles; that is the point, but it changes the setup experience.
Approval latency — human approval suspends execution until an authorizer responds. Budget for it or don't gate that path.

It pays back when the workload can take irreversible actions or handle sensitive data. For read-only, public-data workloads, a plain Tramai.builder() may be all you need — governance is a tool, not a tax. See when not to use this.

AI agent governance — the category pillar
Tool governance — ALLOW / DENY / REQUIRE_APPROVAL in depth
Human approval — the approval lifecycle
JVM AI governance — in-process governance for Java/Kotlin teams
Sovereign Mode — composed fail-fast runtime profile
DLP — classification and redaction
Evidence Packs — deployment attestation
TramAI on GitHub