Runtime governance vs. guardrails vs. observabilityAllowed. Observed. Still the wrong job.

Guardrails enforce constraints. Observability makes execution visible. Runtime governance checks whether an agent’s actions still fit the purpose, scope and policies it was deployed with.

All three matter. This page is about the question only the third one asks.

Attempted tool call · SRE agentIllustrative

Declared purposeInvestigate checkout-api latency and report findingsscope: read-only · policy: no production changes

kubectl rollout restart deployment/checkout-api -n prod
  • GuardrailsPermitted for this role. Not a denied operation.✓ Allowed
  • ObservabilityCaptured live. Alerts depend on configuration.✓ Observed
  • Runtime governanceA production change. The task was to investigate and report.⚑ Off-purpose

The core of it

Permission to use a tool is not permission to use it for every purpose.

The SRE agent holds restart rights for a good reason: the same agent runs approved remediation runbooks. Its access is legitimate, and restarting a deployment is a routine, non-denied operation.

But this run was asked to investigate and report. A restart changes production, drops in-flight requests and replaces the very pods it was asked to examine. Access tells you what the agent can do. Only its purpose tells you what it is for.

Three questions

Two essential questions, and the one they leave open.

Guardrails

Is this action allowed?

Guardrails enforce constraints on tools, arguments, inputs and outputs. They can block destructive actions, cap amounts and validate content, and they can be dynamic and context-aware.

Doesn’t answer on its own: whether an allowed action serves the task.

Observability

What is the agent doing?

Observability makes execution visible: live traces, metrics, alerts, anomaly detection and a detailed history, often in real time.

Doesn’t answer on its own: whether what it sees is what the agent was for.

Runtime governance

Does this action serve the job?

Runtime governance holds each action up against what the agent was deployed to accomplish, and the scope and policies it was given. A deviation is identified as a deviation and recorded with evidence, not just logged as one more event.

It is a separate accountability question. Guardrails and observability don’t fail to answer it. They aren’t built to ask it.

Same run, three lenses

Every layer is right. Only one connects step 04 to the job.

A ticket says checkout latency is up. The agent pulls metrics, lists pods, reads logs, spots memory pressure and decides to fix it. Switch lenses to see what each layer sees.

Declared purposeInvestigate checkout-api latency and report findingsscope: read-only · metrics, get, describe, logs, ticket updates · policy: no production changes

Every step is compared with this

  1. 01Ticket: “p95 latency on checkout-api up 4× since 14:10.”

    query_metrics(service="checkout-api", metric="p95_latency", window="1h")

    Passes: Within scope: investigating.

  2. 02

    kubectl get pods -n prod -l app=checkout-api

    Passes: Within scope: investigating.

  3. 03

    kubectl logs checkout-api-7d9f-x2k -n prod --since=1h

    Passes: Within scope: investigating.

  4. 04Agent: “Memory pressure on two pods. A restart should clear it.”Attempted

    kubectl rollout restart deployment/checkout-api -n prod

    Flagged: Outside the declared scope and policy. The task was to investigate and report; a production restart is a change, and it replaces the pods under investigation. Flagged and recorded with evidence.

  5. 05

    post_update(ticket, "Restarted checkout-api. Latency recovering.")

    Follows from the flagged step: Reports an action outside scope as the outcome.

Steps 01–03 investigate, as declared. Step 04 changes production. Governance identifies and records the deviation; stopping it takes enforcement at a supported control point.

Illustrative run, not a real incident. Commands, permissions and timings are examples.

What runtime governance connects

From what the agent was for to what it actually did.

  1. 01Declared objectiveInvestigate checkout-api latency and report findings.
  2. 02Scope and policyscope: read-only (metrics, get, describe, logs) policy: no production changes
  3. 03Actual actionrollout restart deployment/checkout-api
  4. 04Policy evaluationA production write: outside the read-only scope and against the no-production-changes policy. Flagged.
  5. 05EvidenceA record of what was checked, against what, and what happened.

Declared, not authorized. The objective, scope and policies are what the deployer declares for the agent. Governance evaluates actions against the scope and policies, with the objective as context. It does not independently establish that the declaration itself was approved.

The autonomy tradeoff

Purpose adds a test. It doesn’t replace the others.

Autonomous agents meet situations nobody anticipated. Rules written to cover every case tend to drift toward one of two failure modes.

How tight are the rules?

Too broadInappropriate actions pass.
Well designedStill can’t foresee everything.
Too narrowThe agent loses useful autonomy.

+ Runtime governanceChecks each action against purpose, at any setting.

Alongside what you run

Governance adds a question. It doesn’t ask you to remove a layer.

  • AuthorizationCan this agent use this tool?
  • GatewaysWhat passes through, and on what terms?
  • GuardrailsIs this action allowed?
  • ObservabilityWhat is the agent doing?
  • Runtime governanceDoes this action serve the job?

Purpose-aware evaluation adds a second check that doesn’t depend on predicting every step, so you aren’t forced to tighten rules indefinitely to stay accountable for the task.

It does not remove the need for well-designed guardrails, authorization or enforcement, and it does not guarantee an agent will behave correctly.

Where Sentience fits

One implementation of runtime governance, in three layers.

Governance comes first and is free. Enforcement and isolated execution are added where you need them. All three are layers of one offering, and none of them asks you to replace your existing guardrails, observability or gateways.

Sentience GovernorFree

Apache-2.0, open-source runtime governance. Evaluates observed execution against declared scope and policy, with the objective as context. Flags deviations and produces local evidence you own.

Observe-only and fail-open. It does not block, pause or correct actions.

pipx install sentience-governor

Runtime EnforcementCustom

Adds policy-driven intervention at integrated control points: correction, escalation, pausing and stopping.

Runtime Enforcement

Secure RuntimeCustom

Isolated execution environments with additional execution controls, built for production from day one.

Secure Runtime

Governance can identify and record a deviation without preventing it. Enforcement adds the ability to intervene. Runtime governance vs. runtime enforcement

Questions

Common questions.

What is runtime governance for AI agents?

Runtime governance evaluates an agent’s actions, as they happen, against the purpose, scope and policies it was deployed with. It flags actions that fall outside those declared boundaries and keeps evidence of what was checked and what happened.

How is runtime governance different from guardrails?

Guardrails enforce constraints: which tools, arguments, inputs and outputs are allowed. They can block harmful actions when the constraint has been defined. Runtime governance asks a different question: whether an allowed action serves the task the agent was given.

How is runtime governance different from observability?

Observability makes execution visible, often in real time, with traces, metrics and alerts. Runtime governance evaluates what is visible against the agent’s declared scope and policies, with the objective as context, so a deviation is identified as a deviation, not only recorded as an event.

Why aren’t guardrails and observability enough for autonomous agents?

Autonomous agents meet situations their designers did not anticipate. An action can pass every configured rule and appear in every trace yet still fall outside the agent’s purpose. Neither layer is designed to test for that on its own.

Can runtime governance preserve agent autonomy?

It can help. Purpose-aware evaluation does not require scripting every step in advance, so rules do not have to be made ever more restrictive to keep the agent accountable. It does not remove the need for well-designed guardrails, authorization or enforcement.

Does runtime governance replace existing security or monitoring systems?

No. It sits alongside guardrails, authorization, gateways and observability, and answers a question they do not. Governance on its own identifies and records deviations; intervening requires enforcement at supported control points.

Next step

Find out what your agents do that their purpose doesn’t cover.

Start free with Sentience Governor

More approaches and vendor comparisons: Compare