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
- Cómo trabajan los agentes de AI dentro de los permisos empresariales Las empresas no necesitan agentes de AI como superadministradores. Necesitan agentes controlados que hereden permisos, envíen acciones riesgosas a aprobación y dejen auditoría.
- Cuando tu agente de IA borra la base de producción: el caso de las barreras de ejecución El incidente de base de datos de Replit muestra una lección estructural: el radio de impacto de un agent no debe depender solo de un prompt. Permisos, aprobaciones y auditoría deben ser impuestos por el runtime.
- Por qué las plataformas empresariales de AI deberían ser self-hosted primero Cuando la AI lee datos de negocio, dispara flujos, genera aplicaciones y llama herramientas, la empresa debe controlar el runtime que gobierna objetos, permisos, herramientas, aprobaciones y auditoría.