Governance

Control that holds, and a record that shows it.

Policy runs in the model broker and the tool broker, on the server, where a person cannot get around it. Budgets stop spend before it happens. Every model call and tool call is kept in a chain you can check.

Where it is enforced

What a person can and cannot bypass.

We do not claim more than this table.

Where each control is enforced, and whether a person can bypass it
WhatEnforced byCan a person bypass it?
Model calls The model broker in the control plane. It authenticates the caller, checks policy and budget, attaches the provider key, meters the call and records it. No
Connector actions The tool broker: the person’s identity, fine-grained authorization, policy, approval where a rule asks for one, and inspection of what is sent out. No
Sessions the platform runs The runner’s sandbox, on a network of its own whose only way out is an egress proxy to the platform. No
Tool calls on a developer’s machine The agent runtime: its operating-system sandbox, permission rules and tool firewall, set by managed settings. Only on an unmanaged device
Network traffic from developer machines Your own network controls. Outside our scope

Managed settings can require sign-in and turn off model endpoints people add themselves; the runtime does not start if it cannot fetch them.

Policy

Rules as code, tried before they apply.

Policy as code.

Write rules in Rego. The policy engine checks them for every model call and every call to a connected system, after the platform's own rules, and a rule can only make things stricter: refuse a call, or have a person approve it first.

Try a draft against what already happened: every recorded call is run through it, and you see which would be treated differently before you save.

The console's Policy page with a Rego module of two rules: nothing is deleted from a connected system after working hours, and a runner's write actions wait for a person. Below it: It compiles.
Shown with sample data.

The record.

Model calls, calls to connected systems and every other event are kept in hash chains, one per tenant. Each entry carries the hash of the one before, so a changed, removed or reordered entry is found by walking the chain.

The console checks the chain on request, and one command does the same on the server and names the first entry that does not hold.

The console's audit log: the chain ends at entry 278, the hash of the newest entry, and a mark saying all 278 entries were checked and hold.
Shown with sample data.
Controls

Each control does one job.

Approvals

What an agent would change in a connected system can wait for a person. The approval is for that one call, with that input.

Budgets and ceilings

Soft and hard monthly limits for the organization, its groups, its people and kinds of agent. A hard limit refuses the call before it costs anything.

Tool firewall

Outbound tool calls are checked for secrets and personal data on the server before a connector call leaves the platform.

Executive report

Spend, adoption, value and risk from the same record. Every figure has its definition and source query, and says unavailable when the record cannot answer.

Every agent has an identity

The platform issues short-lived tokens that name the person, the agent and the session, so audit, budgets and authorization know who acted.

Keys stay on the server

Provider keys are kept in the platform's secret store and attached by the broker. People and agents never hold them.

How we handle security

Walk through it with your security team.

We will go through each control in the table, and where it runs in your installation.