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
- Comment les agents AI travaillent dans les permissions d’entreprise Les entreprises n’ont pas besoin d’agents AI super-administrateurs. Elles ont besoin d’agents contrôlés, qui héritent des permissions, demandent validation pour les actions risquées et restent auditables.
- Quand votre agent IA supprime la base de production : le cas des garde-fous à l'exécution L'incident Replit rappelle une leçon structurelle : le rayon d'impact d'un agent ne doit pas dépendre d'un prompt. Permissions, approbations et audit doivent être imposés par le runtime.
- Pourquoi les plateformes AI d’entreprise devraient d’abord être auto-hébergées Quand l’AI lit les données métier, déclenche des workflows, génère des applications et appelle des outils, l’entreprise doit contrôler le runtime qui gouverne objets, permissions, outils, validations et audit.