AI Risk Engine

The AI Risk Engine is Breeze’s control plane for AI-assisted execution. It decides which actions run on their own, which wait for a human, and which never run at all. Every tool call — from the built-in assistant or an external MCP client — passes through the same evaluation, the same approval gate, and the same rate-limit envelope.

For MSPs, this is what makes AI safe to actually use against production fleets. Triage and observation move at machine speed; anything that mutates a customer device at scale still gets a human signoff.

Four Execution Tiers

Every AI action resolves to one of four tiers:

• Tier 1 — Auto-execute (read). Listing devices, retrieving alerts, querying patch status, pulling compliance posture. No approval needed.
• Tier 2 — Auto-execute (low-risk mutating). Acknowledging alerts, resolving alerts, adding incident notes, generating reports. Logged at execution.
• Tier 3 — Approval required. Patch deployment, script execution, device reboots and isolation outside maintenance windows, configuration policy changes. Submitted as pending approvals; nothing runs until an operator clicks approve.
• Tier 4 — Blocked. No API key scope, environment variable, or admin role unlocks Tier 4. Attempts return a denial and are recorded as security events.

All 17 MCP tools carry tier classifications, with the same governance applied no matter which client invokes them. See MCP Server for the full tool list.

Context-Aware Risk Assessment

Tiers are not static labels — they’re evaluated against the context of each request. The same tool can resolve to different tiers depending on target scope, timing, and intent:

• Reboot inside a maintenance window → Tier 2. Same reboot outside the window → Tier 3.
• Run script on a single device → Tier 3. Same script across a whole org → still Tier 3, but the broader blast radius is flagged on the approval card.
• Patch deployment to a test group vs. production fleet — both Tier 3, scope surfaced to the reviewer.
• Device isolation on one endpoint vs. a multi-device group — both Tier 3, scope visible on the approval payload.

Context inputs include target device count, active maintenance windows, the requesting API key’s scope, tenant boundary, and the originating client. The reviewer sees what would actually run before deciding.

Approval Workflow

Tier 3 actions submit as pending approvals rather than executing directly. The Approval History view shows intent, target scope, the requesting identity (user or API key), tenant context, and the parameters that would run. An operator with the right role explicitly approves or rejects; approved actions execute immediately under the same audit trail as direct execution, and rejections are logged with the operator’s identity attached.

There is no implicit timeout that auto-approves a pending action. If nobody reviews it, it never runs.

Rate-Limit Dashboard

Rate limits apply per-org and per-API-key, with current state visible in the Risk Engine dashboard. Operators can see per-tool execution counts across 24-hour, 7-day, and 30-day windows; how close each tenant is to its budget; which keys are currently throttled and when they’ll recover; and which actions were denied by rate limits versus by tier or approval rules.

For MSPs running shared infrastructure, per-org visibility matters: one tenant burning through its budget no longer creates mystery latency for the others. The dashboard makes the cause obvious before it becomes a support ticket.

Guardrail Visibility

Five primary views give operators a single lens on AI activity regardless of where it originated — the Breeze UI, the built-in assistant, or an external MCP client:

• tool execution analytics across configurable time ranges
• per-tool and per-org rate-limit state
• rejection, denial, and security-event logs
• approval history with operator identity, decision timing, and approved parameters
• guardrail trigger events — Tier 4 attempts, scope-mismatched calls, allowlist violations

Why It Matters

The Risk Engine lets AI move quickly on the safe stuff and keep operators in the loop for everything else. Tier 1 and 2 cover the bulk of triage and observation. Tier 3 keeps a human between the assistant and any action that touches device state at scale. Tier 4 makes the truly dangerous calls structurally impossible.

Combined with per-org rate-limit visibility, you get automation that is practical to run on production fleets without giving up change control or auditability.

Learn More

• AI Assistant — how the built-in assistant uses the Risk Engine.
• MCP Server — every external AI client routes through these same tiers.
• Authentication — scoped API keys and identity that map onto the tier model.