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: 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 constrain model/agent behavior, including inputs, outputs, tool use, or other interaction surfaces according to their design.
  • 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.


SEAL 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 Primarily Answers


IAM — Identity & Access Management

“Who or what is allowed to access this system or resource?”

IAM establishes identity, authentication, and access posture.



Guardrails / Model Safety

“What is this model or AI system allowed to generate or do?”

Guardrails govern model interaction and behavior.




GRC / Policy & Risk

“What policies, controls, obligations, and risks apply?”

GRC helps define, document, assess, and oversee institutional control requirements.




SEAL Legal Runtime

Action Governance at the Commit Layer

“May this particular person or system take this particular legal action, in this matter, under this authority, before the firm is committed?”

For the scoped legal workflow, SEAL supplies an action-specific authority decision at the final-submit boundary.


Existing systems provide the governance facts.

SEAL evaluates the authority question before the action binds.

What Existing Controls Already Govern and

the Question That Can Remain at Final Submit

Where Each Control 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 evaluats  Action Governance at the Commit Layer. Under separately approved controlled enforcement, the governed outcome becomes authoritative for the wired path.


  • If identity, role, or authority is missing or ambiguous → refuse (fail-closed governance).
  • If consent, jurisdiction, or matter policy is out of bounds → refuse (fail-closed governance).
  • 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 records designed to make the authority decision reviewable later.

How Each Control 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 records.


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 records for governed outcomes within the scoped workflow.