How SEAL Runtime Compares:

IAM, Guardrails, and GRC

Where Refusal Infrastructure fits — and what it is not.

Why This Page Exists

When people first see SEAL Runtime, they often ask:


  • “Is this a kind of IAM?”
  • “Is this just guardrails for models?”
  • “Is this GRC or policy software?”


This page gives a clear answer.



SEAL works with IAM, model guardrails, GRC, and existing firm systems. It does not replace them.

Evaluation Mode Matters


Observe-only Phase 1: SEAL evaluates the authority boundary and records what would have been approved, refused, or routed for supervision without production blocking.


Controlled enforcement: for separately agreed wired paths, the governed outcome can become authoritative for whether the scoped action proceeds.

The One-Line Summary

  • IAM establishes who or what may authenticate and access systems or resources.
  • Model guardrails and safety controls constrain model behavior, inputs, outputs, and tool use according to their design.
  • Guardrails control what models can say.
  • GRC and policy systems help institutions define, document, attest to, and oversee governance posture.
  • SEAL Legal Runtime evaluates whether a particular scoped high-risk action satisfies the configured authority conditions at the Commit Layer before commitment.


These controls are complementary. They answer different questions.


Sealed decision artifact = an integrity-verifiable decision record designed for client-controlled audit retention and review, and bound to the attempted action.



What Question Each Control Owns

IAM (Identity and Access Management)

“Who is allowed to sign in or see this system or resource?”


Guardrails / Model Safety

“What is this model allowed to say or generate?”


GRC / Policy & Risk Platforms

“What are our policies, controls, and risks — and are we compliant?”


SEAL Legal Runtime (Refusal Infrastructure for high-risk legal actions)

“May this specific action run at all — by this person or system, in this context, under this authority, right now: approve, refuse, or supervised override?”


SEAL Legal Runtime owns the execution-time authority question for the scoped legal workflow wired through it.

Where Each Acts in the Stack

IAM primarily establishes trusted identity, authentication, access, roles, and permissions.

Model guardrails primarily govern model behavior and the model/tool interaction surface.

GRC and policy systems primarily define, document, manage, and oversee governance posture and controls.

SEAL Legal Runtime occupies a different downstream point: the Commit Layer for the scoped consequential action.


The distinction is not which control matters. The distinction is which control point owns which question.

How They Work Together

In a mature legal execution stack:


  • IAM confirms the actor’s identity and roles (who can reach the tools).
  • Guardrails constrain model behavior (what can be generated).
  • GRC and policy systems help define and oversee the firm's governance posture (what should be true).
  • SEAL evaluates the configured authority conditions for the scoped action at the Commit Layer (what may run at all).
  • Under controlled enforcement, that governed outcome can become authoritative for the wired path.


At runtime, SEAL enforces Action Governance in the Commit Layer:

  • If identity, role, or authority is missing or ambiguous → refuse (fail-closed).
  • If consent, jurisdiction, or matter policy is out of bounds → refuse (fail-closed).
  • If the action requires supervision → route to supervised override with a named authority.


This gives the institution a downstream authority control point where its configured governance posture can be applied to a particular consequential action.


SEAL Legal Runtime is Thinking OS™'s product implementing Refusal Infrastructure for high-risk legal actions. It applies Action Governance at the Commit Layer through a pre-execution authority gate and produces reviewable decision evidence for governed outcomes.


What Makes SEAL Different From

Approvals or Generic Workflow Gates


  • Pre-execution authority control — operates at the Commit Layer for the scoped consequential action.
  • Actor-neutral authority question — humans, service accounts, automation, workflows, and AI may all be governed actors.
  • Fail-closed governance posture — required authority context that cannot be safely established does not become silent governance approval.
  • Scope-bounded non-bypassability — under controlled enforcement, the wired path cannot effectively complete without the required governed outcome; unwired paths remain out of scope.
  • Reviewable decision evidence — governed outcomes produce artifacts designed to make the authority decision reviewable later.

How Each Treats Evidence

IAM evidence commonly establishes identity and access events.


Model-control evidence commonly establishes model/input/output/tool-policy behavior.


GRC evidence commonly establishes policy, control, risk, attestation, and oversight posture.


SEAL's evidence surface is action-bound: it is designed to preserve what governed action was evaluated, what authority outcome was returned, and the relevant decision context.


SEAL produces action-bound decision evidence for governed outcomes.

What SEAL Legal Runtime Is Not

To avoid confusion:


  • Not IAM – it does not manage logins, passwords, or access to systems.
  • Not guardrails – it does not tune prompts or supervise model tokens.
  • Not GRC – it is not a policy library, risk register, or control documentation system.
  • Not a chatbot or assistant – it does not draft, coach, or summarize.
  • Not an approval workflow engine — it is an execution-time authority enforcement point that emits evidence-grade decision artifacts.


SEAL Legal Runtime is Refusal Infrastructure applied to high-risk legal actions: a pre-execution authority gate that enforces Action Governance and produces integrity-verifiable decision artifacts for every approve / refuse / supervised override.