Most universities did not decide to adopt AI; it arrived. Faculty draft with it, students code with it, research groups wire agents into shared lab accounts and departmental data, and central IT finds out afterward. EDUCAUSE research (2025) describes the gap plainly: AI use is now widespread across higher-ed faculty and staff, while formal AI governance and acceptable-use-policy coverage lags behind. A policy nobody can see, and that nothing enforces, is not a control — it is a PDF.
That gap is not unique to campus, but campus makes it sharper. Accounts are shared by design. Research integrity depends on knowing what touched what. And the people you most want to enable — researchers — are exactly the ones a heavy-handed control would drive to shadow tooling.
The problem, concretely
Three things tend to be true at once on a campus network:
- Acceptable-use policy exists but isn’t enforced. There’s a rule about which systems AI may touch and what it may do. Nothing turns that rule into a decision at the moment an agent tries to act.
- Shared accounts erase attribution. A lab’s agents run as one service account behind a connection pool. Native audit attributes the access to that credential — not to the person or the agent that actually did it.
- Researchers need to move fast. They want to try a new agent against real-ish data today, not file a ticket and wait. If governance is a gate they have to beg past, they route around it.
This is the same shape the wider market is hitting. Of organizations that suffered an AI-related breach, about 97% lacked proper AI access controls (IBM Cost of a Data Breach 2025, Ponemon), and Gartner expects more than 40% of agentic-AI projects to be cancelled by the end of 2027 — governance debt is a large part of why. The campus version is cheaper to fix early, while the agents are few and the blast radius small.
How Olivares AI helps
Olivares AI is an open, self-hostable platform that discovers AI agents on your infrastructure, maps what each one can read and write, and lets you govern and audit that access. It is read-first: it observes and records out of band before it gates anything, and it is deny-closed where it does gate. For a campus that means you can start by seeing the truth — and only then decide what to enforce.
Enforce acceptable-use policy, deny-closed
The governance layer turns AUP into policy that produces a decision. Its ABAC engine runs after role-based access and can only further-restrict: it denies when a deny-rule matches, otherwise the existing decision stands, and a malformed policy fails closed rather than open. So a “no AI agent may write to the grades system” or “sandbox agents may not reach the SIS” rule becomes an enforced denial, not a memo.
Be precise about what v1 matches. Deny-rules today key on the principal, the permission/verb, and the resource — the attributes that actually reach the evaluator. Rules that branch on resource sensitivity (e.g. “anything tagged FERPA”) need a resource-attribute seam that is a documented follow-up, not yet shipped. Where you need a human in the loop, the platform records an approval request plus an append-only decision trail, so “who approved this agent reaching that dataset” is answerable later.
See /docs/concepts/governance for the read-first, deny-closed model and where actuation is live versus on-demand.
Attribute who-did-what across shared accounts
This is the load-bearing capability for campus. The access map records, with honest confidence levels, which agent reads or writes which resource and whether that access is permitted or merely observed. Identity governance (/product/identity) binds an agent to the canonical identity its credential presents, so an access can be attributed firmly.
The honesty rule matters here more than anywhere: attribution is firm only when a per-agent or per-session identity is propagated into the access. When several agents run as one shared lab account behind a pool, attribution collapses to that single identity — and the product says so, surfacing the shared binding as a governance finding rather than guessing a person. An identity bound to more than one agent is flagged, not papered over. The remedy is operational: propagate per-agent identity (for example into the connection’s application name) and the attribution sharpens. We will not print a name the signals can’t support.
Governed sandboxes for researchers
Researchers get isolated, ephemeral execution of agent scenarios against mocked resources — not production. The default sandbox runner is isolated by construction: it holds no handle to your store, network or secrets, and a step that asks for a resource the scenario didn’t mock returns a deterministic mock-miss marker rather than reaching anything real. Runs are ephemeral; each one records the real runner and whether it was isolated, so a degraded backend is visible, never hidden. Stronger OS-level isolation (a hardened container or a microVM) is a pluggable backend the self-host operator wires in.
This gives a lab a safe place to try a new agent before it ever touches real data — which is how you keep fast-moving researchers inside governance instead of routing around it. For agents that do govern real systems, a consent-gated, defensive red-team battery (prompt injection, jailbreak, exfiltration) can probe an agent’s resistance, scored against the OWASP Top 10 for Agentic Applications. It runs only against agents you own and have authorized — it is a test suite, not an offensive tool.
Evidence for research integrity and audits
Evaluations score candidate agent outputs against versioned golden suites — useful when a research group needs a reproducible record that an agent met a criterion, run to run. The judge is honest: if no scoring backend is wired, a run is recorded as skipped, never a silent pass, and raw outputs are never persisted — only a one-way hash and a scrubbed label. See /product/evals.
For the institution, the compliance layer (/product/compliance) aggregates what the platform already observes and audits into a sealed, append-only evidence package anchored to a hash-chained ledger. A control with backing evidence is marked satisfied; one without is marked a gap, never a faked pass. This is a technical mapping to frameworks like the EU AI Act and ISO/IEC 42001 — it is not legal advice and the product does not claim certification.
What this is — and isn’t
- It is an open, self-hostable governance and observation layer for AI on your infrastructure. The control plane can run offline / air-gapped on your own hardware, so attribution and policy data never leave campus.
- It is read-first and deny-closed. It observes and governs broadly; it does not broadly actuate. Where it can take an action, that surface is live, on-demand, or a declared seam — and the modules catalog marks which.
- It is pre-1.0. The catalog is 23 modules with roughly 20 wired; some capabilities above are present, some are on-demand, some are documented follow-ups. We label which.
- It does not run your models, and it is not air-gapped inference. The air gap is the control plane. Only self-hosted models (vLLM, Ollama) run offline; hosted models like Claude do not.
- It is not a certification. No SOC 2 / ISO / EU AI Act certification — the compliance mapping is “designed toward” those frameworks and produces evidence, not a seal. See /security for the posture and /docs/concepts/governance for the governance model.
Adoption is widespread; oversight is what lags (EDUCAUSE, 2025). The honest starting point is to see what your AI already touches, decide what it may do, and prove it — in that order.