One architecture, two deployment pathways
This is VaHive Systems Lab’s governance architecture: the specification behind the preprints under The Lab, extended into an implementable design. There are two specification series because there are two genuinely different problems, and the thing that separates them is not who the operator is. It is where the model runs.
When the model is a remote service, the boundary between model and governance is the API call. That boundary is structured, auditable and controllable, and it comes for free.
When the model runs on the operator’s own hardware, referred to as running a model locally, that boundary does not exist by default. The weights are files on your own disk, loaded into your own GPU. The inference process shares an operating system with everything governing it. Without deliberate isolation, a model process does not need to attack through the governed channel; it can simply go around it: read the token store, truncate the append-only record, read the signing key out of another process’s memory. None of that requires a sophisticated attack. It requires access, and a locally hosted model has exactly that kind of access purely because of the environment it runs in. That’s a deployment choice, not a model choice.
That single difference generates every other difference between the two pathways. That deployment variable is why VSL developed two architectures, as peers, instead of one covering both.
The shared foundation.
Both pathways inherit the same core, and most of the architecture lives here.
- A deterministic enforcement layer: fixed, code-level rules, with no neural computation anywhere in the decision
- An evaluator with structurally zero execution rights, separated by routing rather than by policy
- An append-only, hash-chained governance record, sealed before a change takes effect
- Epistemic control: the governance layer tracks confidence itself and never takes it from what the model says about itself, with drift measured as a gradient rather than a threshold
- A memory graph with explicit human anchoring signals and a contamination guard
- An agent hierarchy where authority is structural, not linguistic: an agent cannot talk its way into a permission it was not given
- A stress-test harness that exists to attack the governance layer itself
How they were hardened.
The method is the same one VaHive Systems Lab applies to its code: publish, red-team, register every issue by name, close them, bump the version, repeat.
v3.0 was published in March 2026, and every round of hardening since has followed the same discipline: candidate designs analysed and rejected with their failure modes recorded, at least one issue reclassified upward in severity when review showed it had been underrated. Local and Agent API have each continued that work independently since the pathways split, at their own pace.
The register is the point. An architecture nobody has attacked has an unknown number of holes.
Magus Local.
The model runs on the operator’s hardware, beside the thing governing it. Everything in the shared foundation, plus the machinery required when the thing being governed sits on the same machine as the thing governing it:
Magus Local’s v4 specification is still being written. What follows describes v3.
- Mandatory process isolation, stated as a compliance boundary rather than a recommendation. An implementation that does not meet it is not MAGUS-compliant, and none of the governance claims apply to it
- Cryptographic boot binding and a runtime attestation guard
- Governed model-weight loading: the enforcement layer opens the weights, verifies them, and passes a file descriptor, so the model process never resolves the path itself
- A recovery architecture: state journal, host sentinel, and a global state transition matrix, because a crash must not become an opportunity
Magus Agent API.
An agent reached over an API doesn’t run on hardware you control. Everything it acts on, instructions, documents, another system’s response, arrives through that same connection, mixed in with the ordinary content it’s supposed to be reading. That’s not a hypothetical: it’s the actual, demonstrated way an autonomous agent gets tricked into doing something nobody authorized, because instructions disguised as content look identical to real content once they’re inside the model. Once that agent can actually do something, send an email, update a record, move money, that trick stops being a curiosity and starts being an unattended action taken in your name, with nobody finding out until after it’s happened.
There’s a second, quieter version of the same problem. The part of the agent that actually decides what to do next isn’t something you host or can watch happen. It lives on someone else’s infrastructure, reached over a connection, and all that ever crosses back to you is the output. You can’t watch it reason, and you can’t reach in and stop a decision mid-formation. What you can actually govern is what goes in, what comes back, and what the agent is allowed to do once it has an answer. That’s not a shortcoming of any particular provider. It’s just what “the model is a connection away” means in practice, and it’s why governance for this kind of deployment has to work entirely at that boundary, rather than by watching the model think.
Everything below governs exactly that boundary:
- Containment for external content, with untrusted material structurally unable to acquire authority
- Session boundaries defined explicitly, including what must be re-established when one opens
- Long-horizon drift detection anchored against a genesis state, so slow deviation is visible without a single failure event to point at
- Provenance on proposals, so an action can be traced to what actually caused it
- Oversight of the operator, not only the agent, because a supervisor who has stopped watching is a governance gap even when the agent itself is behaving
- An absolute execution ceiling, with no override, including the operator’s own, at the point past which continuing is structurally too dangerous to permit
Built on the same base, for a different environment.
Magus Agent API traces back to the same governance philosophy as Magus Local, the earlier work on the harder problem: securing a model running where an operator has direct, low-level control. Reached over an API, a model doesn’t expose that same access, so a specification built for Local’s assumptions would either overclaim what Agent API can enforce or waste what Local can actually see. One philosophy, two specifications, each built for what’s true of its own environment. Agent API is currently at v4.0.1.
Watching the operator, without overruling them. When a system works reliably for long enough, the person overseeing it tends to stop looking closely. The Agent API specification measures that from timing and structure, never by reading what the operator writes, and records it with everything else. It can detect the slip, flag it, escalate it and restrict what the agent may do. It never overturns a person’s decision because of that measurement, and the final say always stays with a person: an approval given while oversight had slipped still stands, permanently marked as given under those conditions.
Attacked on purpose, again. After the Agent API specification was completed, it went through a second, independent adversarial review, the same method used the first time. Every issue that review raised is tracked to closure by name, and the specification’s version was bumped to reflect that real content changed, not folded in silently. Nobody finds every hole in an architecture on the first pass, which is why this one has now been through two.
Want to talk about applying this to your own system?
VSL is a research and development organisation and does not take on clients. Virasai is currently the only company approved to apply the Magus architecture, and Virasai’s own Secure engagements are built on these same deterministic principles, applied to a real, deployed system. All enquiries go through Virasai.