Skip to content
Brutor AI Docs

Autonomy & response

Detection tells you something changed; this page is about what the platform may do about it. Every AI System has an autonomy level, and an armed response policy can downgrade it automatically — the closed loop a read-only observability tool cannot close.

Autonomy

Section titled “Autonomy”

How much a system may do without a human. A separate axis from an agent’s enforcement_mode, which decides whether policy bites at all — a dry-run agent can still be suspended, and an enforcing one can still be fully autonomous.

Level Effect
autonomous Runs unattended
approval_required Side-effecting tool calls route through tool approvals
restricted Read-only; effecting calls denied
suspended Everything denied, with a specific error rather than a generic 403

Resolution is min-wins across the resource-group hierarchy and the acting agent. An agent identity may be more restricted than its AI System, never less — which is what makes “suspend this AI System” mean something: it suspends every actor inside it.

An unset level contributes nothing to the minimum, so an unclassified group cannot cancel a restriction set above it. A fleet where nobody has set the field behaves exactly as it did before the field existed.

Suspension applies to every caller, not only agent principals. A plain API key or a human session pointed at a suspended AI System is refused the same way — suspension is a property of the system, not of how the caller authenticated. (approval_required is the exception: it exists to interpose a human where an agent would otherwise act unattended, and its approval flow is keyed on an agent identity a plain API key does not have.)

When the governance database is unreachable

Section titled “When the governance database is unreachable”

Autonomy is resolved on every governed action, which is what makes suspension take effect immediately. That also makes a database failure a decision point, and the proxy never resolves it to autonomous:

  1. The last level successfully resolved for that actor, if it was seen in the last 5 minutes.
  2. Otherwise BRUTOR_AUTONOMY_FALLBACK_FLOOR — restricted by default.

Completions classify as read-only, so a blip degrades side effects rather than taking the fleet offline. Denials taken this way say “authority could not be verified” rather than naming a restriction nobody configured, and the audit row records whether the level was live, last_known_good or floor — so a decision taken on degraded information stays distinguishable from one taken on current configuration.

The closed loop

Section titled “The closed loop”

Detection tells you something changed. A response policy acts on it.

on:
  drift_class: behavioural
  severity_at_least: high
then:
  - set_autonomy: approval_required
require_human_to_restore: true

Find it under AI Estate → AI Systems → (a system) → Automatic response.

The blast radius is shown before you arm

Section titled “The blast radius is shown before you arm”

Autonomy resolves min-wins down the resource-group tree, so a policy attached to a team-level group restricts every inheriting system beneath it. The editor previews the affected set as you write the policy, and will not offer to arm it until that preview has come back.

Refusals are recorded, not swallowed

Section titled “Refusals are recorded, not swallowed”

Every finding is considered exactly once, and the result is stored even when nothing fires — with the reason. “No policy matched” and “the response loop is down” would otherwise look identical, and the panel reports how many findings are still waiting to be considered so a stalled loop is visible.

Every automatic action is written to the audit trail as actor system:drift-response, with the triggering drift event, the previous value and the blast radius. That row is what answers “who changed this, and why”.

Section titled “Related”