Governance

The three rings

The governance architecture is three concentric rings. Each ring builds on the one inside it. You cannot have routing without identity. You cannot have interop without routing. The rings are:

Ring 1: RBAC

Identity and access control for every entity type. If it touches your infrastructure, it has an identity and a permission set. Roles and permissions work the same way whether the actor is a human developer or an AI agent. This is the foundation everything else builds on.

Ring 2: Routing

Intelligent task routing across model providers. Three modes:

• Cheap-first fanout — try small, fast models first. Escalate to larger models only on failure. Keeps costs low for simple tasks.
• Complexity-based escalation — route to the appropriate model tier based on task complexity. Simple queries go to fast models; complex reasoning goes to capable models.
• Shared policy — org-wide guardrails applied to all agent entities regardless of provider. Cost caps, rate limits, and access restrictions enforced at the routing layer.

Ring 3: Universal Bridge

Vendor-agnostic tool interop. OpenTool's manifest system (opentool.json) describes capabilities, triggers, and inputs for any tool, skill, or plugin. The bridge translates between provider-specific formats so your tools work everywhere without rewiring. Write once, run on any provider.

The entity model

In > tool_os, every actor that interacts with the system is a first-class entity with identity, role, and permissions. This is what makes AI governance possible — agents are not anonymous processes, they are identified entities with defined capabilities and restrictions.

Roles and capabilities

Each entity is assigned a role within an organization. Roles define what the entity can do — which tools it can call, which app surfaces it can access, and what actions require additional approval.

Guardrails

Guardrails are declarative rules that the policy engine enforces on every tool call. They are defined in opentool.json manifests and in org-wide policy configuration. Examples:

• Path restrictions — block writes to /etc/, ~/.ssh/, or any path matching a pattern
• Command patterns — block destructive shell commands (rm -rf, DROP TABLE, terraform destroy)
• Cost caps — per-session and per-org cost limits that pause execution when exceeded
• Rate limits — maximum tool calls per minute to prevent runaway agent loops
• Provider restrictions — which AI providers an entity can route to, preventing cost escalation
• File size limits — maximum file size for read/write operations

The quarantine flow

When a tool call is flagged for quarantine, it enters a human review loop. The operation is paused, the request appears in the Quarantine app surface, and an admin reviews the details before approving or rejecting.

The quarantine surface shows the full context: which entity made the request, what tool was called, with what parameters, and why the policy engine flagged it. The admin sees everything the policy engine evaluated, making informed approval possible.

If the admin rejects the request, the agent receives a denial message and can adjust its approach. The rejection is logged in the audit trail.

Why this matters for enterprise

Enterprise teams face a specific problem: AI agents are getting real infrastructure access. kubectl commands, Terraform applies, database queries, API calls with production credentials. And most agent systems have no governance layer.

This matters for:

• Compliance — SOC2, HIPAA, PCI-DSS, and FedRAMP all require audit trails and access control. The entity model and policy engine provide both by default.
• Cost control — per-session and per-org cost tracking with budget alerts. Agents cannot escalate to expensive providers without budget authorization.
• Incident response — session replay lets you reconstruct exactly what an agent did, when, and why. Every tool call is a span in the OTEL trace.
• Separation of duties — different roles for different entity types. A development agent does not have the same permissions as a deployment pipeline.
• Vendor independence — the universal bridge means you are not locked into a single AI provider. Switch providers without changing your governance model.

Change management is the final safety layer

The policy engine decides whether a tool call is allowed in the current runtime. Change management decides whether an artifact is allowed to become real in production. Those are related but not identical decisions.

That distinction matters when the system discovers a new threat surface. Exploration can be intentionally permissive inside a local workspace or a draft branch. Promotion to production should still pass through supply-chain and change-control checks: