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
- How AI Agents Stay Inside Enterprise Permission Boundaries Enterprise teams do not need AI agents to become unrestricted administrators. They need agents that act as controlled users, inherit permissions, route risky actions for approval, and leave an audit trail.
- When an AI Agent Deletes Production Data: Runtime Guardrails Beat Prompts The Replit database incident shows a structural lesson: an agent's blast radius must be controlled by runtime permissions, approvals, and audit logs, not only by a prompt.
- Self-Hosted AI Application Platforms: Why the Runtime Belongs to You Once AI reads business data, triggers workflows, generates applications, and calls tools, enterprises need control over the runtime that governs objects, permissions, tools, approvals, and audit evidence.