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.


  • Refusal Infrastructure is the category.
  • Action Governance is the missing discipline it enforces.
  • SEAL Legal Runtime is the implementation for regulated industries (starting with law) — a sealed governance layer in front of high-risk actions.


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 on paper.
  • SEAL Runtime controls whether a high-risk action is allowed to execute at runtime — based on identity, context, and authority — and emits a sealed decision artifact for every approve/refuse/override.


Sealed decision artifact = a cryptographically verifiable decision record (trace ID + policy version + anchors + verdict) written to a tamper-evident store 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 Legal AI)

“Is this specific person or system allowed to take this specific action, in this context, under this authority, right now — yes or no?”


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

What Makes SEAL Different From Approvals or Generic Workflow Gates


  • Execution-boundary enforcement: called at the moment a tool is about to file / send / sign / submit / approve.
  • Operator-agnostic: humans, service accounts, and agents hit the same gate (no “AI shortcut lane”).
  • Fail-closed semantics: missing/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 emits a verifiable artifact tied to a policy version + trace ID.


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 on the execution path for high-risk actions (wired workflows), immediately upstream of any irreversible commit step.
  • Acts as a pre-execution authority gate: file / send / approve / move money / commit a binding step.
  • Returns a deterministic verdict (approve / refuse / supervised override) before the action is allowed to execute.
  • For each governed action, decides approve, refuse, or supervised override at runtime.

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, tamper-evident decision artifact for every governed decision — approval, refusal, or supervised override.
  • Artifacts are verifiable (integrity-checkable) and action-bound: they reference the attempted action, the controlling policy set/version, and the decision trace ID.
  • Artifacts are designed to be written to client-owned, append-only audit storage and structured so GCs, regulators, and insurers can see:
  • who acted,
  • on what,
  • under which authority,
  • what decision SEAL made, and
  • when it happened.

How They Work Together

In a mature legal AI 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:

  • If identity/role/authority is missing or ambiguous → refuse (fail-closed).
  • If client 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: a sealed, pre-execution authority gate for high-risk actions that enforces Action Governance and produces verifiable decision artifacts for every approve/refuse/override.