Glossary term
Governed runtime
A governed runtime is an application runtime that enforces identity, permissions, approvals, and audit logging on every read, write, and tool call, so that an AI agent and the person it acts for are held to exactly the same rules.
Also known as governed application runtimepolicy-enforcing runtime
In practice
Most AI integrations put the rules in the wrong place. A prompt that says "never modify closed opportunities" is a suggestion; a service account with database credentials has no rules at all. A governed runtime moves the boundary underneath the model: the agent calls a tool, the runtime resolves the acting identity, applies row- and field-level permissions, routes anything material through an approval, and writes an audit record — whether the caller was a browser session, an API client, or an MCP tool call.
This is why "self-hosted AI" is usually a question about the runtime rather than the model. Where the weights run matters less than which component decides what the agent may read, which action it may execute, and what evidence remains afterwards. A chat interface cannot enforce those decisions reliably; the layer that owns the data access path can.
The practical test is a single question: if the agent were replaced tomorrow by an intern with the same login, would anything about the safety of the system change? In a governed runtime the answer is no, because the enforcement never depended on the caller being well-behaved.
Where this term is used
Pages and articles that put this term to work.
Product pages
- Permissions & security Role-based, row-level, and field-level access control with a permission matrix editor and an audit log viewer, record sharing, and tenant isolation — enforced on people and AI agents alike.
- Trust center Review the ObjectOS trust model: data residency, self-hosted deployment, identity, permissions, approvals, audit logs, AI tool boundaries, and enterprise security review materials.
- Tools & MCP The @objectstack/mcp server turns objects, queries, and actions into policy-checked tools for Claude, Cursor, or any MCP client — with permissions enforced on every call.
Articles
- Wie AI Agents innerhalb von Unternehmensberechtigungen arbeiten Unternehmen brauchen keine AI Agents als Super-Admins. Sie brauchen kontrollierte Nutzer, die Berechtigungen erben, riskante Aktionen zur Freigabe senden und auditierbar bleiben.
- Wenn dein KI-Agent die Produktionsdatenbank löscht: Warum es Laufzeit-Leitplanken braucht Der Replit-Datenbankvorfall zeigt eine strukturelle Lehre: Der Wirkungsradius eines Agents darf nicht nur durch einen Prompt begrenzt werden. Berechtigungen, Freigaben und Audit müssen von der Runtime erzwungen werden.
- Warum Enterprise-AI-Anwendungsplattformen zuerst selbst gehostet werden sollten Sobald AI Geschäftsdaten liest, Workflows auslöst, Anwendungen erzeugt und Tools aufruft, muss das Unternehmen die Runtime kontrollieren, die Objekte, Rechte, Tools, Freigaben und Audit steuert.