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.



It works with IAM, guardrails, and GRC — but it is not any of them.

The One-Line Summary

  • IAM controls who can access systems.
  • Guardrails control what models can say.
  • GRC controls how policies and risks are defined and evidenced.
  • SEAL Runtime controls whether a governed high-risk action may execute at runtime — based on identity, context, and authority — and produces a sealed decision artifact for every approve / refuse / supervised override.


Sealed decision artifact = an integrity-verifiable decision record (trace reference + policy reference + governance anchors + verdict) designed for client-controlled audit retention and review, and bound to the attempted action.

What Question Each Layer Answers

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?”


Only SEAL Legal Runtime answers the execution-time authority question.

What Makes SEAL Different From Approvals or Generic Workflow Gates



  • Pre-execution authority gate: called at the moment a tool is about to file / send / sign / submit / approve.
  • Operator-agnostic: humans, service accounts, and AI systems hit the same gate (no shortcut lane).
  • Fail-closed semantics: missing or ambiguous identity, authority, or context → refuse, not “best effort.”
  • Non-bypassable when wired: if the workflow is wired through SEAL, the action cannot proceed without a verdict.
  • Evidence-grade output: every decision produces a reviewable decision artifact tied to a policy reference and trace reference.


Where Each Acts in the Stack

IAM

  • Sits before systems — at login, SSO, API access.
  • Governs access to tools, data, and services.
  • Once a user or service is authenticated and authorized, IAM is done.


Guardrails

  • Sits around or inside models.
  • Filters inputs and outputs, blocks certain prompts or responses.
  • Governs language behavior, not whether the resulting action executes.


GRC

  • Sits in documentation and oversight.
  • Stores policies, control libraries, attestations, and audit records.
  • Governs what should be true on paper, not live execution paths.


SEAL Legal Runtime

  • Sits in the Commit Layer for high-risk actions (wired workflows), immediately upstream of any irreversible step.
  • Acts as a pre-execution authority gate for actions such as file / send / approve / move money / other binding steps.
  • Returns a governed verdict — approve, refuse, or supervised override — before the action is allowed to execute.

How Each Treats Evidence

IAM

  • Logs authentication and access events.
  • Good for reconstructing who accessed what, but not always why an action was allowed to proceed.


Guardrails

  • May log blocked prompts or responses.
  • Evidence is about content filtering, not authority.


GRC

  • Stores policy documents, risk registers, control mappings, and attestations.
  • Evidence is about governance design, not individual execution decisions.


SEAL Runtime

  • Creates a sealed, integrity-verifiable decision artifact for every governed decision — approval, refusal, or supervised override.
  • Artifacts are action-bound: they reference the attempted action, the relevant policy context, and the decision trace reference.
  • Artifacts are designed for client-controlled audit retention and review so GCs, regulators, insurers, and internal oversight can see:
  • who acted,
  • on what,
  • under which authority,
  • what decision SEAL made, and
  • when it happened.


Screenshot below is from a simulated matter where a governed actor attempted to file under the wrong authority.The pre-execution authority gate refused the action and emitted a refusal artifact the firm can hand to regulators or insurers later.

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 defines policies, controls, and risk posture (what should be true).
  • SEAL Runtime enforces those rules at execution time for high-risk actions (what may run at all).


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 turns policies from PDFs into execution-time enforcement for irreversible legal actions.


SEAL Legal Runtime does not replace IAM, guardrails, or GRC. It gives them an execution-time enforcement point  for high-risk actions.


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.