RESEARCH INSTITUTIONS
WHEN YOU HOST THE MODEL, YOU OWN THE CONSEQUENCES
Most AI security assumes the model belongs to someone else. On a research campus it does not. The cluster is yours, the weights are yours, the agents are yours, and so is every action they take. Mountain Theory sits between what an AI system decides and what it actually does, on your hardware, and returns ALLOW, HOLD or BLOCK before the action executes.
The controls you were sold do not exist on your own cluster
When an institution calls a hosted API, the provider supplies a layer of safety behaviour with it. Filtering, refusals, usage policy, rate limits. Imperfect, but present.
Bring the weights in house and all of that stays behind. A model running on institutional GPUs has no vendor sitting between it and your systems. The moment a researcher gives that model tools, a shell, a filesystem, a database, an API key, the only thing standing between a proposed action and a real one is whatever you put there.
Most products in this category cannot help, because they attach to a vendor API that you are no longer calling. Mountain Theory is model and framework agnostic by design. It governs the action, not the API, so it reaches self-hosted models, open weights, custom agents and research code that never touches a commercial endpoint.
Evidence, on the kind of hardware you already run
We publish the test rather than describing it. The same 10 actions an autonomous agent might attempt, run in the same order under three configurations on lab hardware, alongside NVIDIA OpenShell, NVIDIA's open-source secure runtime for agents.
| Configuration | What happened |
|---|---|
| Ungoverned baseline | 10 actions attempted, 10 executed. That is the blast radius. |
| NVIDIA OpenShell only | All 5 sandbox-boundary crossings denied at the kernel. All 3 in-bounds bad decisions allowed, including a secrets read that printed credentials to the screen. |
| OpenShell plus Mountain Theory | The same 3 in-bounds actions return HOLD, HOLD and BLOCK. The secrets read is stopped before it executes, so the credentials never print. Boundary denials still fire underneath. |
The two layers do different jobs and they stack. OpenShell decides what an agent can touch. Mountain Theory decides whether an in-bounds action should happen at all. The published run includes the two actions Mountain Theory has no policy for, because a result that hides its gaps is not a result.
Watch all three runs, with the full action list
The risk is not what the model says. It is what the agent does
Content filtering asks whether a model produced something objectionable. On shared research compute that is the smaller problem. The larger one is an agent that was given real access and takes a step nobody authorised:
- Destroying governed state, including data another lab depends on
- Disabling a compliance control because it was in the way of the task
- Reading application secrets from a path it is technically permitted to read
- Exfiltrating to an external host, or to the cloud metadata endpoint
- Escalating privileges to finish a job faster
None of those require a malicious prompt. They happen when a capable system infers a wrong next step and has the permissions to act on it. That is also why signature-based thinking does not transfer: you cannot write a rule against an action sequence nobody has seen yet.
We watched exactly that happen. A third-party provider updated a vendor-hosted model driving one of our demo agents, in a change aimed at making it more persistent at chaining tools together. Nothing on our side changed. The agent began attempting multi-step paths it had never tried before. Every attempt was stopped on the days the behaviour first appeared, with no new rule, no signature and no patch, because the check evaluates what an action would do and whether the agent has authority to do it.
Read what happened when the model changed underneath us
One control plane, many campuses, local authority
A university system is not one organisation. Campuses, colleges, labs and medical centres run their own infrastructure, answer to different regulators and make their own risk decisions. Central IT rarely gets to dictate, and should not have to.
Policy is written in plain English by the person who owns the risk, not in code by whoever is free. A campus can hold its own rules while the system keeps a consistent enforcement layer underneath. Every decision is recorded who, what, when and why, append-only, so a unit can answer for its own AI use without waiting on a central team to reconstruct it.
HOLD is the option that makes this workable. An action can pause for a human, escalate along a path declared in advance, and fail secure if nobody answers. Turn it on for the narrow set of actions that genuinely warrant a person, and let the rest run at full speed.
Past FERPA
Student records are the obligation everyone names first, and AI systems touching enrolment, advising or student support sit squarely inside FERPA. A research institution carries more than that at once:
- Controlled unclassified information and NIST 800-171 obligations on federally funded work
- Export-controlled research, where the question is not only who read the data but what a system did with it
- Human-subjects data under IRB protocols that assume a person is accountable for each use
- Protected health information wherever an academic medical centre is in scope
- Sponsor and grant conditions that require you to show, not assert, how the work was handled
Every one of those turns on the same question: can you produce evidence of what an automated system was permitted to do, what it attempted, and what was stopped. Mountain Theory is built so that record exists as a by-product of enforcement rather than as a reporting exercise afterwards.
How to evaluate anyone in this category, including us
Claims here are easy to make and hard to check. Ask every vendor on your list for the same four things and put the answers side by side:
- The action set. Exactly which actions were attempted, in what order.
- The control condition. What happened with nothing in the path, so there is a baseline.
- The outcome per action, including the ones the product did not stop.
- The recording or the log. Something a sceptic can check.
A vendor who publishes all four is making a claim you can test. A certification, an integration list or a customer logo answers a different question, about how that vendor runs its own service and who has bought it. Both are worth knowing. Only one tells you whether an action gets stopped.
Where this fits on campus
Mountain Theory is enterprise-first and deploys where your models already run, including on-premises GPU infrastructure with no dependency on a commercial model provider. It is model agnostic and framework agnostic, so it covers hosted assistants, self-hosted open-weight models and custom research agents through the same control plane and the same evidence trail.
Book a working session and we will run your action set, not ours