MeridianSeal

Architectural governance for agentic AI

MeridianSeal

Governing AI agents by instruction is not enough. The architecture has to enforce the limit.

The idea, in one line: the boundary is not a line through the space of actions, it is a function.

The problem

Instruction is not enforcement

This section works through one illustrative example: the taxonomy’s own catalogue of sixty action classes an autonomous AI agent could take, each one scored against what would actually stop it under a worked reference configuration.

Four kinds of rule

Every action an agent might take is bound by one of four kinds of rule – this is the vocabulary the rest of the site uses, and the same four labels used in the chart below.

None

No rule and no control. The action is simply possible, and nothing anywhere records or resists it.

Instructional

A rule that lives in prose – a policy document, a system prompt, a briefing. The agent is told. Nothing stops it from doing otherwise.

Conditional

A rule checked by something at run time – but the actor being checked can also reach that check: alter it, or route around it another way.

Structural

A rule the architecture enforces on its own – an identity boundary, a gate, a control the agent cannot reach around. Compliance is not a term in the outcome.

The pattern, measured

This is what shows up whenever the only boundary is instruction, or there is no architectural boundary at all: real capability keeps outrunning what is actually enforced. Scored across a reference catalogue of sixty action classes an autonomous agent could take, under a bare, ungoverned starting configuration:

0of 60 action classes

an agent’s real access already exceeds its written mandate

0of 50 mandate gaps

closed by a guardrail the agent cannot reach around

  • None 36 of 60 no control of any kind
  • Instructional 8 of 60 bounded by prose alone
  • Conditional 12 of 60 checked by something the agent could also alter
  • Structural 4 of 60 behind a control the agent cannot reach around

One sentence, every control

The decision layer is well built. The layer that would bind the decision to the world is not.

– the pattern this worked scoring surfaces behind every control in the catalogue

Meridian Seal closes that gap directly – not by writing a stricter policy, but by putting a structural boundary behind it. See it decide, live, next.

See it live

Which rung holds which control

The four kinds of rule above, live: select one to see who can defeat it, how many of the sixty catalogued action classes rest on it today, and real guardrail examples of that class.

56 of 60 action classes in this catalogue have no structural enforcement.

Instrument · Access vs mandate

The gap between can and may

Every action class gets two grades: the access level an agent technically holds, and the mandate level it is authorised for. Where access outruns mandate, governance exists only on paper – scored across this reference catalogue, 50 of 60 action classes show access exceeding mandate, and 0 show the reverse. Select a cell to list its action classes.

Level I is autonomous, Level II supervised, Level III prior approval or prohibited.

Interactive · The Guardrail Lab

Watch enforcement decide, not describe

Pick a configuration below, from a bare, unprotected deployment to the fully hardened catalogue, then press play. Every attempted action resolves against a single rule: a structural guardrail blocks it outright, a conditional check catches most of it, an instructional rule just reminds and lets it through, and no rule means nothing noticed at all. Switch on adversarial mode to see which of those still hold once the agent can alter its own checks.

0 Attempts
0 Boundary crossings
0 Blocked
0 Detections

    Didactic simulation driven by the real research registers; simplified, not the full research model.

    The catalogue · 134 guardrails, 12 layers

    The guardrail stack

    The catalogue spans twelve layers, from identity and credential up to the model and prompt layer. Each bar is one layer, segmented by population – present, partial, proposed. Of 134 entries, 39 are present, 17 partial and 78 proposed; 49 are structural on paper, but 47 of those 49 are proposed, not built. Select a layer to open its guardrails.

    Platform

    What Meridian Seal does

    One console, five real jobs. Every panel below is illustrative – not a screenshot, to protect the product ahead of general availability – but every claim next to it is a real, running capability, not a mockup of a mockup.

    Agent Farm

    Orchestrate a whole fleet of coding agents from one board. Configuration changes stage first and apply on your schedule, so nothing changes mid-task under an agent that is still working.

    Governance

    A live dashboard of what your policy actually enforces today, not what the policy document claims. Run a configuration through the simulator before you trust it in production.

    Servers

    A fixed, known inventory of every host in your fleet, with a real terminal into each one from the browser. Nothing is reachable that isn’t on the list.

    Files

    A real code editor over a real, allowlisted filesystem – every path resolved and checked before a byte is read or written, never a free-form address.

    Audit

    Every state-changing action, in one append-only, filterable log – written by the infrastructure, not by the agent describing its own work.

    Instrument · Supervision viability

    Is your human oversight real?

    A human-in-the-loop point is only real if six conditions all hold. Try the test on three familiar supervision points below, and see how each one actually scores.

    Select a supervision point above to run the six-condition test.

    How it works

    MeridianSeal runs the separation it sells

    This site is not only a description of architectural governance – it is a small, working instance of it. MeridianSeal ships as two hosts with one job each, connected only where a job requires it, and it says in public which of its own protections are structural and which are still just watched.

    plane-meridianseal

    The Console

    MeridianSeal’s own control plane – the operator-facing admin console for the reference implementation. It carries no public listener of any kind.

    unisinos-meridianseal

    Showroom, Launcher

    • This showroom – the public page you are reading now
    • The Launcher – the single sign-on entry point that authenticates a visitor once and hands them to whichever host their role needs

    Traffic between the two hosts never leaves the private network: the Console has no path reachable from the public internet at all, and the only route from one box to the other is the segmented link between them – the same network-segmentation contract (CB-05) that this framework’s roadmap gap analysis is designed to mark not transferable wherever a deployment provides no segmentation between agent workspaces at all. Small as this deployment is, the boundary between its two hosts is drawn on purpose, not inherited as an accident of infrastructure choice.

    What the Console actually enforces

    This is also where the pitch stops being only descriptive. MeridianSeal is architectural governance built as a running product, not left as a diagram:

    • Independent, append-only evidence. Every session’s activity is captured by a hook running outside the agent’s own process, into a transcript the agent cannot edit after the fact – the shape the supervision framework names as the answer to SD-05 unverifiability.
    • Session lifecycle confirmed independently, not by self-report. Verified during this build against the real running process, not against the API’s own account of itself.
    • Structural separation, not a shared account. Mandate, policy enforcement and evidence sit in the Console’s own process, reachable only through its session-gated, CSRF-checked API – outside any single agent session’s own working directory.
    • New capability, fail-closed by construction. The Interactive Voice module ships with no telephony credentials configured on this deployment, and stays inert rather than degrading into an open line.

    Enforced versus monitored, on this build

    Enforced

    A rule the box boundary or the network itself makes true, whether or not anyone remembers to check it – which host is reachable from where, and which of the two needs no public listener at all.

    Monitored

    A rule this build watches and logs but has not yet made unreachable outright – labelled plainly as such, the same way the roadmap document’s gap analysis refuses to round a monitored control up to an enforced one.

    The candour is inherited, not decorative. This framework’s own roadmap gap analysis is built to rate most of what looks like a control on a single-host deployment – the policy enforcement point, the egress path, the workload identity – not transferable, precisely because the party each control is meant to bind still holds the means to defeat it. MeridianSeal’s two-host split is a direct, if modest, answer to that finding: keep the boundary honest by drawing fewer of them and enforcing every one you draw.

    Enter the Launcher

    unisinos.meridianseal.com · single sign-on entry point

    Want to see it against your own estate? Get in touch.

    Contact

    Talk to us

    Want a walkthrough, a pilot, or just have a question about how Meridian Seal enforces its boundaries? Reach us directly.