AI in Breeze

Operators run Breeze. The workers do the work. Wisp runs your day.

Operators run Breeze.            → people, roles, permissions, Approvals (you hold them)
The workers do the work.         → the built-in AI everyone has:
                                    Breeze AI (the chat door) · Agents (the roster) ·
                                    Runs · AI tasks (long-running jobs) · Library (recipes)
Wisp runs your day.              → one per person, hosted: home · thread · brief ·
                                    nudges · memory · grant · spend meter
Governance                       → Risk engine · Approvals · Budgets & usage ·
                                    Providers & models · Tool sources · Kill switch · Audit
Doors for other people           → Breeze Helper / Breeze Assist (end users on the device)
                                    Breeze AI for Office (end users in Office)
                                    MCP server (AI clients) · Mobile

Operators

You and your technicians are the operators. Roles and permissions decide who can use AI at all (ai_sessions:use), who can manage agents (ai_agents:*) and who can approve what the AI proposes. There is one approval object and one place for it: Approvals. See Approvals below and Approval security.

The workers

The workers are the built-in AI every Breeze deployment has.

• Breeze AI is the chat door: the side panel and the full chat page, suggested fixes and per-device memory.
• Agents are named, permission-scoped workers that wake on a trigger and write up what they found. Each pass is a run; see also Analysis runs and AI impact.
• AI tasks are long-running, multi-step jobs you hand off and walk away from, started from a recipe in the Library.

Wisp

Wisp is one per person and sits above the workers. It keeps an eye on the estate that person can see, nudges them when something needs a human, and hands focused jobs to the workers. What it hands off shows up as a run or an AI task. Wisp runs on Breeze Cloud only: on a self-hosted server its sidebar entry and page show a lock, and there is nothing to configure.

Governance

AI settings have one home, Settings → AI (/settings/ai, v0.125.0+). It gathers the AI cards you are allowed to open, including AI Usage, Script authoring and Tool Sources; their pages keep their addresses.

The same controls apply to every worker: the AI risk engine and its tiers, Approvals, rate limits, cost tracking, bring your own LLM key, tool sources and the audit trail.

Doors for other people

• Breeze Helper gives end users an AI chat on their own device (see Helper AI Chat).
• Breeze AI for Office brings it to your clients in Office.
• MCP server connects Claude Desktop, Cursor and other AI clients.
• Mobile carries approvals and Wisp nudges in your pocket.

---

AI Risk Engine

The AI Risk Engine categorises every AI tool into one of four tiers that control how it executes. Navigate to it via Security → AI Risk in the sidebar.

AI-authored scripts

You can also extend the assistant with your own tools: point Breeze at an MCP server you run and its tools appear alongside these, with the same tiers and approvals — see Tool Sources.

The assistant and background agents can author a script mid-conversation, have it independently reviewed, and run it once you approve — see AI Script Authoring & Review for the full walkthrough. The AI Risk Dashboard’s Script Proposals panel tracks proposals per day, unattended runs, and how often a human’s decision disagrees with the independent reviewer’s recommendation.

Tool tiers

Tier	Execution	Examples
Tier 1	Auto-execute (read-only, no approval)	query_devices, analyze_metrics, get_security_posture, ioc_hunt (list_rule_sets/preview_sweep/list_sweeps/sweep_status), get_active_users, disk_cleanup (preview), system_cleanup (status), propose_action_plan, list_configuration_policies, get_effective_configuration, preview_configuration_change, get_configuration_policy, configuration_policy_compliance, get_service_monitoring_status, query_monitors, manage_monitors (get/create/update/delete), query_backups, get_backup_status, browse_snapshots, get_incident_timeline, generate_incident_report, manage_software_policy (list/get), manage_browser_policy (list), list_playbooks, get_playbook_history, get_vulnerability_report, find_proven_fixes, get_device_vulnerabilities, search_documentation, propose_script, get_script_proposal
Tier 2	Auto-execute + audit logged	manage_alerts (acknowledge/resolve), manage_services (list), ioc_hunt (cancel_sweep), manage_processes (list), manage_scheduled_tasks (list), system_cleanup (list), analyze_disk_usage (refresh), analyze_boot_performance (triggerCollection), set_device_context, resolve_device_context, apply_configuration_policy, remove_configuration_policy_assignment, manage_configuration_policy (activate/deactivate), create_incident, revoke_elevation, assign_security_training, acknowledge_network_device, registry_operations (read_key/get_value), file_operations (list), execute_command (list_processes/file_list/event_logs_list)
Tier 3	Requires human approval before execution	execute_command (kill_process/start_service/stop_service/restart_service/file_read/list_services/event_logs_query), run_script, disk_cleanup (execute), system_cleanup (run/cancel), network_discovery, security_scan (quarantine/remove/restore), ioc_hunt (sweep/import_iocs), file_operations (read/write/delete/mkdir/rename), manage_configuration_policy (create/update/delete), manage_processes (kill), manage_scheduled_tasks (run/disable/enable), registry_operations (set_value/create_key/delete_key), create_remote_session, request_elevation, trigger_agent_restart, trigger_agent_upgrade, configure_network_baseline, trigger_backup, restore_snapshot, execute_containment, collect_evidence, execute_playbook, remediate_vulnerability, manage_ai_agents (authorize_supervised_key)
Tier 4	Blocked — never executed	Cross-org operations

manage_monitors supports get only. Its retired create, update, and delete actions return guidance without approval or write permission. Author network checks with manage_monitor_definitions using kind network_check; retire unconverted checks through the conversion ledger to preserve history.

Note

Tier classification is action-level, not tool-level. For example, disk_cleanup is Tier 1 when previewing and Tier 3 when executing. system_cleanup follows the same split — reading a run’s status is Tier 1, listing the OS-native cleaners a device offers asks the device live and is Tier 2, running them or cancelling a running run is Tier 3; analyze_disk_usage and analyze_boot_performance read stored data at Tier 1, and only a fresh scan (refresh) or collection (triggerCollection) from the device is Tier 2; manage_alerts is Tier 1 for list/get and Tier 2 for acknowledge/resolve. execute_command resolves per commandType: list_processes, file_list, and event_logs_list are Tier 2; list_services and event_logs_query stay Tier 3 despite being reads, because they can return unredacted credential- or PII-bearing content (service binary paths, raw event-log messages); mutating types and file_read are Tier 3 too. collect_evidence is Tier 2 when it collects logs, processes or connections, and Tier 3 as soon as the request includes a screenshot (it is listed under Tier 3 because the unqualified call is checked at the stricter level). The AI resolves the tier for each specific action at runtime. Within Tier 2, strictly read-only entries — the execute_command types above, file_operations (list), manage_services (list), manage_processes (list), manage_scheduled_tasks (list), system_cleanup (list), a fresh analyze_disk_usage or analyze_boot_performance read, and the single-purpose get/list/search catalog, contract, invoice, and quote tools — auto-execute (with the audit-trail entry) under every approval mode, including the default per-step mode. Tier-2 mutations still take a lightweight inline confirmation under per-step approval, and a paused session always confirms everything Tier 2 and above.

Note

When a partner-scoped agent lists configuration policies (list_configuration_policies), the results now include partner-wide (“All orgs”) policies — those that belong to the partner rather than a single organization — alongside org-owned ones. Previously partner-wide policies were invisible to the AI, so a policy defined once for every customer wouldn’t show up in a fleet-wide question; it now appears as expected.

Approval workflow

When the AI proposes a Tier 3 action, it enters a pending state and waits for human approval. Tier 3 actions fall into one of two approval scopes:

• Supervised (the default) — the technician who asked for the action approves it themselves, directly in chat. The model here is that the AI is the actor and you are the approver: routine device work you could do by hand should not need a second person.
• Four-eyes (a fixed high-stakes list) — a second person must approve. Reviewing a proposed high-stakes action and authorising it are kept as separate responsibilities.

Supervised actions — approve in chat

Routine device work is supervised: running commands and scripts, file and registry operations, starting/stopping services, killing processes, installing patches, disk cleanup, agent upgrades, triggering backups, and policy, deployment, monitor, group, and automation changes.

The chat approval card offers a plain Approve / Deny. Approving is gated on your own permissions for the underlying action — if your role lets you do the operation by hand, you can approve the AI doing it; no second person is involved. The request is still stored durably and the execution is written to the audit trail, marked as a self-approval. A supervised request raised in chat waits for your decision for the approval timeout — 5 minutes unless your partner or organization has changed it.

Note

If your partner enforces an authentication-assurance floor, approving a supervised action prompts the corresponding step-up verification (for example Touch ID / Windows Hello) instead of accepting a plain click.

Four-eyes actions — a second person approves

A small, fixed set of actions always requires a different user to approve:

• Financial or externally binding — issuing invoices, recording or voiding payments, activating or cancelling contracts, sending quotes
• Tenant shape — creating organizations, changing an organization’s status, moving tickets between organizations
• Identity and account control (Microsoft 365 / Google Workspace) — password and 2FA resets, mail forwarding and delegates, mailbox permissions, disabling or offboarding users, device wipe
• Restores and rollbacks — VM checkpoint delete/apply, restore-as-VM and DR plan runs, patch rollback, snapshot and database restores
• Computer control and unattended remote session creation
• Releasing security containment — un-isolating a device, rolling back threats. (Isolating or quarantining stays supervised — urgent protective containment should not wait on a colleague.)
• AI agent governance — granting an agent a pre-authorized action key, so its future runs may take that action unattended

To decide a pending four-eyes request:

1. Open Security → AI Risk.

2. Click Approval History.

3. Find the pending request and review the action details.

4. Click Approve to allow execution, or Reject to cancel it.

Approved actions execute immediately. Rejected actions are logged and the AI is notified. A four-eyes request raised in chat stays open for 60 minutes. The chat turn itself only waits for the approval timeout; an approval that arrives after the chat turn has moved on still executes, and the session shows the result when you return to it.

If what the request refers to changes while it waits — the script is edited, the quote or invoice is revised, the organization’s state moves on — the approved action does not run against the drifted content. It fails with a content-changed error instead, and the AI has to raise a fresh request.

Approval timeout

A chat turn that is waiting on an approval is held open, so the wait is bounded. The approval timeout is how long the chat waits for someone to approve a gated action before it gives up:

• Default: 5 minutes. Range: 5 to 60 minutes.
• Partner default: Settings → Partner → AI Approval Timeout. Applies to every organization that has not set its own value.
• Organization override: Settings → Organization → AI. Choose a value to override the partner default, or Inherit to follow it. The organization’s value always wins. The selector shows the inherited value and where it comes from.
• A change applies from the next chat message. It does not change a wait that is already in progress.

A timeout never approves anything. When the timeout elapses with no decision:

• A Tier 2 inline confirmation is rejected. The AI is told, and nothing runs.
• A supervised Tier 3 request stops waiting and expires at the same moment. It never runs. To proceed, ask the AI again.
• A four-eyes request stops holding the chat, but it stays open for its full 60 minutes. If a second person approves it in that time, it still runs.

The timeout is for interactive chat only. It deliberately stops at 60 minutes. Work that must wait longer, such as scheduled or overnight AI agent runs, goes through the durable approvals queue (Security → AI Risk → Approval History and the mobile app), where a request stays open for 24 hours.

Approving your own request when you are the only approver

If the technician who asked for a four-eyes action is also the only user eligible to approve it (a sole-operator setup), the chat’s approval card offers Verify & Approve directly inline. Clicking it runs a Touch ID / Windows Hello (WebAuthn platform authenticator) verification in the browser, and that verification — not the click — is what satisfies the assurance requirement for approving your own request. Cancel the prompt and nothing is approved.

When other users are eligible to approve, the inline button does not appear: someone else must approve from Approval History or the mobile app. That four-eyes separation is deliberate. Disabled and invited (not-yet-accepted) users do not count as eligible approvers, so a team whose only other admin account is disabled behaves as a sole-operator setup.

Who can approve

Opening the assistant at all requires the ai_sessions:use permission, granted by default to Org Admin, Org Technician and Partner Technician (Partner Admin holds it through its full-access role). Roles without it do not see the assistant button, the Wisp sidebar entry, or the /wisp and /ai/chat pages. The permission opens the conversation only — each tool the assistant calls is checked against the same permission the equivalent page or API route requires.

Approving or rejecting a four-eyes action requires the approvals:decide permission. It is granted by default to Org Admin (and to Partner Admin through its full-access role) and is deliberately not granted to Org Technician or Org Viewer. Approving a supervised action needs no extra permission — only the requester’s own permission for the underlying action, which was already checked when the AI proposed it.

To let another role approve four-eyes actions, add approvals:decide to it under Settings → Users & Roles. See Users and Roles.

Note

If an organization has no user whose role grants approvals:decide, a four-eyes request has nobody who can act on it and is automatically cancelled rather than left pending indefinitely.

Pending approvals survive a restart

Tier 3 requests raised from AI chat or the MCP server are stored durably, so a pending approval is no longer tied to the session that created it. If the server restarts — or you simply close the browser and come back later — the request is still waiting in Approval History, and approving it there executes the action.

This also means an approved identity action against a connected Google Workspace or Microsoft 365 tenant (for example a password reset, sign-out, or user disable) runs against that organization’s connection without needing the original chat session to still be open. Microsoft 365 write actions additionally require the Graph-actions executor to be enabled — see Customer Microsoft 365 Graph-actions (write) executor.

When an approved Microsoft 365 password reset executes this way, the requesting technician retrieves the temporary password afterwards with a one-time Reveal temporary password action in Approval History — see Identity Console → Retrieving a reset password.

Rate limits

Many tools have a per-tool sliding window rate limit. Requests that exceed the limit are rejected and logged in the Rejection & Denial Log. Read-only or lower-risk tools not listed here (for example get_user_experience_metrics, query_backups, get_backup_status, browse_snapshots, create_incident, get_incident_timeline, generate_incident_report, and list_playbooks) currently have no rate limit.

Tool	Limit	Window
execute_command	10 requests	5 min
run_script	5 requests	5 min
disk_cleanup	3 requests	10 min
system_cleanup	30 requests	60 min
network_discovery	2 requests	10 min
security_scan	3 requests	10 min
ioc_hunt	30 requests	10 min
file_operations	20 requests	5 min
manage_services	10 requests	5 min
analyze_disk_usage	10 requests	5 min
manage_configuration_policy	20 requests	5 min
manage_processes	15 requests	5 min
query_monitors	30 requests	5 min
manage_monitors	10 requests	5 min
get_service_monitoring_status	30 requests	5 min
trigger_backup	5 requests	10 min
restore_snapshot	3 requests	10 min
execute_containment	5 requests	10 min
collect_evidence	10 requests	5 min
execute_playbook	5 requests	10 min

The limits above are the shipped defaults. The counter is kept per user and per tool, across every organisation that user works in.

Raising the per-tool limits

A self-hosted or smaller model usually retries and re-plans more than Claude does, so it reaches these limits sooner. To give it more room, set Per-tool rate limit multiplier in the AI budget settings. It takes a whole number from 1 to 10, and the default is 1.

Every per-tool limit becomes ceil(limit × multiplier). At a multiplier of 3, for example, run_script allows 15 requests per 5 minutes instead of 5. The window stays the same. The multiplier applies to the built-in assistant and to the MCP Server.

• The multiplier can only raise a limit. It never lowers or removes one. The API rejects a value outside 1–10, and a stored value that is out of range is treated as 1.
• You set it in the same two places as the other budget fields (see Configuring thresholds): Org settings → AI for one organisation, or the AI Budgets tab of Partner Settings for every organisation under the partner. A partner value overrides the organisation value and locks the field.
• The organisation of the current call selects the multiplier: the chat session’s organisation, or the MCP API key’s organisation. A partner-scoped MCP caller that has no organisation uses the partner’s value. Because the counter is shared across organisations, a user who works in two organisations with different multipliers is checked against the limit of the organisation they are working in now.
• AI Risk → Rate Limits shows the limits that are in effect for the selected organisation, with the multiplier applied, and shows the default next to each limit that was raised.

Action Plans

The AI can propose multi-step action plans for complex operations that require human review before execution. When the AI invokes propose_action_plan, it creates a structured plan with pre-flight checks for each step. Plans operate in two modes:

Mode	Description
action_plan	A sequence of concrete steps to be executed after approval
hybrid_plan	A mix of informational analysis and executable steps

Action plans are subject to the same approval workflow as Tier 3 tools — the plan must be approved before any steps execute.

Dashboard sections

The Risk Engine dashboard provides five views, each filterable by time range (24 h / 7 d / 30 d):

Section	What it shows
Tier Overview Matrix	Tool counts per tier with colour-coded risk levels
Tool Execution Analytics	Execution status breakdown, top tools, average duration
Approval History	Pending, approved, and rejected Tier 3 requests
Rate Limit Status	The per-tool limits in effect for the selected organisation, with the rate-limit multiplier applied
Rejection & Denial Log	Failed, rejected, and security-denied operations

API reference

Method	Path	Description
GET	/ai/admin/tool-executions	Tool execution analytics (?since=ISO&limit=1–200, default 100)
GET	/ai/admin/security-events	Guardrail audit trail (?since=ISO&limit=1–100&action=filter)

---

AI attribution on the device page

Scripts and commands that an AI assistant or an autonomous AI agent dispatches to a device are now recorded as such. Each script_executions and device_commands row carries who decided the work — ai_assistant (a person asked, in chat or over MCP) or ai_agent (an autonomous agent run decided, with no human in the loop) — plus the conversation or agent run it came from, and an ai.command.executed / ai.script.executed audit event is written alongside the dispatch.

This answers a question the audit trail could not answer before: who decided to do this to my machine. It is deliberately separate from three other facts the row already carried — who wrote the script (authorship), what scheduled the run (trigger_type), and who the request authenticated as (the principal). An AI can start a policy-driven run, and a person can hand-run an AI-authored script, so collapsing them would destroy information.

What is not yet attributed

Work an AI schedules rather than dispatches — patch jobs, software deployments, automation runs, playbook executions, elevation requests and backups — is still recorded without an AI marker, because the device command is issued later by a background worker that runs under its own context. SentinelOne isolation and threat actions are performed through the vendor’s API and never create a Breeze command, so they are unmarked too.

Rows created before this release are unmarked

An unmarked row means AI initiation was not recorded — never a human did this. There is no backfill: every AI-run library script that already exists was stamped with the invoker’s user id and a manual trigger, so historical AI work is indistinguishable from human work. The UI renders an unmarked row as the absence of a marker, not as a “human” badge.

Best effort, not a guarantee

The AI marker on the audit event is written alongside the dispatch on a fire-and-forget path, so a dispatch that already succeeded is never failed by a lost audit write. A dropped write leaves a real action unmarked; it never marks a human action as AI. The columns on the command and execution rows themselves are written in the same statement as the row, so they are not subject to this.

Tenant boundaries

The origin pointers are severed whenever the row could otherwise reach across tenants:

• Device moved to another organisation — the execution follows the device, but its session and agent-run pointers are nulled (agent-run history stays with the source organisation). The ai_initiator_kind marker is kept: the fact that an AI did the work survives the move, the cross-tenant pointer does not.
• Organisation merge — the execution is re-tenanted to the surviving organisation with the same detach, because the originating agent run stays with the merged-away shell.
• Erasure — deleting an AI session nulls the pointer on any surviving execution while leaving the marker intact.

All three columns are included in the tenant data export, so a customer asking “who did this to my machine” gets the answer in the one artifact designed to hold it.

---

Helper AI Chat

The Breeze Helper tray application includes an AI chat interface designed for end users (not just administrators). When enabled at the organisation level, end users can ask the Helper questions about their device, troubleshoot issues, and request common IT actions — all without opening a support ticket.

How it works

The Helper AI agent runs on the API server using a filtered tool set. Not all AI tools are available to the Helper — the helperToolFilter service restricts access to safe, device-scoped operations appropriate for end users.

Capability	Description
Device diagnostics	“Why is my computer slow?” — analyzes CPU, memory, disk, and boot data
Vision troubleshooting	Captures a screenshot and uses AI vision to interpret error dialogs or UI issues
Self-service actions	Common IT tasks like clearing temp files, restarting services, checking updates
Computer control	AI can interact with the desktop to perform guided actions (Tier 3, requires approval)

Organisation toggle

Helper chat is controlled per organisation. Administrators can enable or disable it via organisation settings. The toggle is delivered to agents through the heartbeat response — when disabled, the Helper hides its chat interface.

Note

Helper AI chat uses the same cost tracking and guardrail infrastructure as the main AI assistant. All tool executions from the Helper are audit-logged with actorType: 'helper'.

---

AI Cost Tracking

Every AI session tracks token usage and estimated cost. The aiCostTracker service records input tokens, output tokens, and total cost per session, per user, and per organisation.

Viewing costs

Navigate to Settings → AI → AI Usage (/settings/ai-usage) to view:

Metric	Description
Total sessions	Number of AI conversations
Total tokens	Combined input + output tokens consumed
Estimated cost	Dollar cost based on Claude API pricing
Per-user breakdown	Token usage grouped by user
Per-session detail	Individual session cost and token counts

Cost data is stored alongside the conversation history.

Model quality

The AI usage by model card has two views. Spend shows cost, tokens and refusals by the model that served each call. Quality shows how conversations went, grouped by model, feature, or model family:

Column	What it counts
Conversations	Chat sessions and agent runs whose last model call in the period was on that row
Cost / conversation	Average spend on that row for each conversation that used it
Refusal rate	Calls the model declined, per call
Failover rate	Calls that moved to a backup model because this one failed or was unavailable
Flag rate	Sessions a person flagged. Automatic flags after a tool error are listed separately
Left for another model	Conversations that switched model, or continued in a new session on another model
Turns to resolve	Median messages a technician sent in sessions that finished without a person’s flag or a move to a new session
Agent runs completed	Agent runs that completed, out of runs that finished

A call served by a refusal fallback or a backup model counts toward the model that was chosen, so a model that often needs its fallback shows it. A conversation counts toward the model it last used, and a switch counts toward the model it left. A session counts as finished when it is closed, expired, or idle for 24 hours.

Breeze has no explicit “this was solved” signal, so Turns to resolve is an estimate. Compare rows with many conversations; rows with fewer than 20 are marked. Columns that need data this server does not record yet show “—”.

Billing credit integration

When a billing service is configured (BILLING_SERVICE_URL and BILLING_SERVICE_API_KEY), AI sessions check the organization’s credit balance before starting. If credits are exhausted, the user sees a message to purchase more credits. After each chat turn, that turn’s estimated cost is deducted from the balance. Each turn is charged only for its own usage (v0.120.0+; earlier releases charged some chat turns the running total of the conversation so far).

When billing is not configured, AI usage is unlimited — cost tracking still records usage for visibility, but no spending limits are enforced.

Credits remaining. A partner-scoped login sees a Breeze AI credits remaining tile at the top of the AI Usage page, and the same figure follows the AI cost indicator elsewhere in the app — so you find out you are running low while you can still do something about it, not when a session refuses to start. The tile breaks the balance into what came with your plan and what you have bought on top. It is absent when you are signed in to a single organization rather than the partner, when the organization bills for its own AI usage, when no billing service is configured, or when the balance could not be fetched. An absent tile never means zero credits.

Tip

Cost tracking is automatic — no configuration required. It works for both the main AI assistant and the Helper AI chat. Billing credit enforcement is optional and requires the billing service environment variables. See Environment Variables for details.

Budget alerts

Independent of hard budget enforcement, an organisation can get warned as its AI spend approaches its cap. Each period (daily and monthly) is checked against a ladder of percentage thresholds, and once spend crosses a rung, an alert fires for that rung.

Alerts only fire for an organisation that has AI enabled and a daily or monthly cap set. With no cap there is nothing to measure a percentage against, so no rung can be crossed.

The default ladder is 50%, 80%, and 95% of the configured budget. On top of the ladder, a 100% “cap reached” alert always fires when the budget is exhausted, even if the ladder is empty or disabled, since that alert cannot be turned off. Each rung fires once per period; the ladder resets automatically when the daily or monthly period rolls over.

Alerts are delivered to active users with the billing:manage permission, whether they belong to the organisation directly or are partner users whose access covers that organisation. Delivery has two channels:

• Monthly rungs and the 100% cap-reached alert are delivered both in-app and by email.
• Daily 50/80/95 rungs are delivered in-app only, to avoid an email per day as spend climbs toward a much smaller cap.

Configuring thresholds

The threshold ladder is configured in two places:

• Organisation: Org settings → AI (v0.114.0+; previously on the AI Usage page). The AI Usage page itself is now usage-only, and shows a read-only Effective budget panel with each field’s value and where it came from (Set by partner, Set by organization, or Default).
• Partner: the AI Budgets tab of Partner Settings, which can set a value that applies across every organisation under the partner.

A partner-set value locks the corresponding field in Org settings → AI: the field is grayed out and shows a Managed by partner note, so the org can see the value but can’t edit or submit it. If every field is locked, the org’s Save button is disabled entirely. A partner-scoped user with permission to manage partner-wide policies also sees a View partner-wide budgets link from the locked field straight to the Partner Settings AI Budgets tab.

Either field takes two kinds of input: leave it empty to inherit (the org inherits the partner value, or the 50/80/95 default when the partner sets nothing), or type an explicit ladder of up to five whole percentages, such as 60, 90. Turning pre-cap warnings off entirely requires storing an empty list, which the UI cannot produce; do that through PUT /ai/budget with "alertThresholdPercents": []. The 100% cap-reached alert still fires regardless.

---

AI Input Sanitization

The aiInputSanitizer service validates all user inputs before they reach the AI agent. This layer prevents prompt injection, command injection, and other adversarial inputs from being passed to AI tool calls.

Sanitization includes:

• Input length limits
• Pattern detection for known injection techniques
• Escaping of shell metacharacters in tool arguments
• Validation against Zod schemas defined in aiToolSchemas.ts

All rejected inputs are logged in the security event trail accessible via the Risk Engine dashboard.

---

AI data & privacy

What the AI may read from a customer’s devices, and how long the outputs of its tool calls are kept, is set by an AI data & privacy policy (v0.124.0+). The partner default lives under Partner Settings → AI Features; each organization can override it on its own AI tab. An override can only tighten the partner default, never loosen it — the stricter choices are simply not offered. A blank value inherits, and each card says where the value in force comes from: this organization, the partner default, or the Breeze default.

AI device file reads

Level	What the AI can do
Off	Cannot read file contents or browse folders on devices, and diagnostic access requests are refused. Disk-usage summaries and your own library scripts stay available.
Excludes user profile folders (default)	System and application paths, with approval. Documents, Desktop and home folders — C:\Users\*, /home/*, /Users/* and /root — are refused unless an administrator approves a time-boxed diagnostic grant.
Any path, with approval	Every read still needs a technician’s approval and is audited; credential stores stay blocked.

The level is enforced wherever the AI reads device files: the chat assistant, AI agent runs, the MCP server, the Helper and the script builder. A partner that has never saved a policy gets Excludes user profile folders.

Keep AI tool outputs for (days)

Tool outputs — the text a tool returned to the model — are kept for 30 days by default. A partner can choose Keep forever instead of a number of days; an organization can shorten the partner’s window but not lengthen it. A nightly job replaces outputs older than the window with an Output expired marker. A chat whose outputs have expired keeps its visible transcript but loses its resumable model context, so continuing it starts from what is still on screen.

First nightly run after upgrading to v0.124.0

The setting ships together with the retention job, so a partner that has never saved an AI data policy gets the 30-day default at the first nightly run, which expires older outputs in existing chats. To keep history, set Keep AI tool outputs for (days) to Keep forever before that run. Self-hosters can also move the run time — see Environment Variables.

Device-originated text is untrusted

Device file contents, command output and registry values reach the model as fenced, untrusted text. Instructions found inside them are treated as data the model is reading, not as directions to the assistant.

---

Backup AI Tools

The AI assistant can query, manage, and operate backups, disaster recovery plans and Hyper-V VMs across your fleet. These tools are available in any AI chat session and to AI agents.

Tool	Tier	Description
query_backups	1	List backup configurations, jobs, and policies
get_backup_status	1	Health summary for a device or organization (active configs, job counts, storage totals)
browse_snapshots	1	List available snapshots for a device with timestamps, sizes, and expiration
query_hyperv_vms	1	List Hyper-V VMs on a device
get_hyperv_vm_details	1	Details for one Hyper-V VM, including checkpoints
query_mssql_instances	1	List SQL Server instances and databases on a device
get_mssql_backup_status	1	SQL Server backup chain status for a device
get_vault_status	1	Sync status and contents of a backup vault
query_backup_sla	1	List backup SLA definitions and their current breach counts
get_sla_breaches	1	List backup SLA breach events
get_sla_compliance_report	1	Aggregate backup SLA compliance across the fleet
get_vm_restore_estimate	1	Estimated restore time for a VM snapshot
query_c2c_jobs	1	List cloud-to-cloud backup jobs for a connection
search_c2c_items	1	Search backed-up mailbox and drive items
query_vaults	1	List local backup vault configurations and sync status
query_c2c_connections	1	List cloud-to-cloud (Microsoft 365 / Google) backup connections, credentials masked
query_dr_plans	1	List disaster recovery plans
get_dr_plan_details	1	Details for one disaster recovery plan, including its groups
get_dr_execution_status	1	Status of a disaster recovery plan execution
manage_backup_profiles (list/get)	1	List backup profiles and see what each one backs up
manage_backup_profiles (create)	2	Create an organization backup profile. A partner-wide profile (ownerScope: partner, “all orgs”) needs approval (Tier 3)
manage_backup_profiles (update/delete)	3	Change or delete a backup profile. It may be partner-wide, and narrowing one stops protecting data in every organization, so the requester approves
configure_backup_sla (create/update)	2	Create or change a backup SLA: RPO/RTO targets and breach alerts
manage_dr_plan (create_plan/update_plan/add_group/update_group)	2	Create or edit a disaster recovery plan and its device groups. Refused while one of the plan’s executions is running
manage_dr_plan (delete_group)	3	Delete a group from a disaster recovery plan
trigger_backup	3	Initiate an on-demand backup for a device
trigger_hyperv_backup	3	Back up a Hyper-V VM now
trigger_mssql_backup	3	Back up a SQL Server database now
verify_mssql_backup	3	Verify a SQL Server backup on the device that took it (RESTORE VERIFYONLY)
trigger_vault_sync	3	Copy a snapshot to a device’s local vault
trigger_c2c_sync	3	Start a cloud-to-cloud backup sync for a configuration
configure_vault (create/update)	3	Create or repoint a device’s local vault (path, local/SMB/USB type, retention). The device is reconfigured, and the approval names the path
manage_hyperv_vm (start/stop/force_stop/pause/resume/save)	3	Change a Hyper-V VM’s power state
manage_hyperv_checkpoints (create/delete/apply)	3	Create a checkpoint. Deleting or applying one needs a second approver
restore_snapshot	3	Restore files from a snapshot to a device. Needs a second approver
restore_as_vm	3	Restore a snapshot as a new Hyper-V VM or bare-metal disk image. Needs a second approver
instant_boot_vm	3	Boot a snapshot as a VM. Needs a second approver
restore_hyperv_vm	3	Restore a Hyper-V VM from backup. Needs a second approver
restore_mssql_database	3	Restore a SQL Server database. Needs a second approver
restore_c2c_items	3	Restore cloud-to-cloud backup items by id. Needs a second approver
execute_dr_plan	3	Run a DR rehearsal, failover or failback. Every executionType needs a second approver, because a rehearsal of a non-bare-metal group runs the same restore as a failover

Tier 3 actions in this table are approved by the requesting user unless the row says they need a second approver. A headless AI agent can call any of these tools, but every Tier 3 call becomes a proposal that a person approves. None of these actions can be pre-authorized for an in-product AI agent.

See Backup & Recovery for configuration details.

---

Incident Response AI Tools

The AI can create and manage security incidents, execute containment actions, and collect forensic evidence. These tools are available in AI chat and to AI agents.

Tool	Tier	Description
create_incident	2	Create a new security incident with classification and severity (needs alerts.write)
execute_containment	3	Run a containment action on a device (process kill, network isolation, account disable, USB block). Needs both devices.execute and alerts.write, because it also records the action on the incident
collect_evidence	3	Collect forensic evidence from a device (logs, processes, connections). Evidence without a screenshot runs at Tier 2; a request that includes a screenshot needs approval
get_incident_timeline	1	View the full timeline of an incident
generate_incident_report	1	Generate a structured report with action and evidence summaries

See Incident Response for the full workflow.

---

Security, Compliance & Operations AI Tools

Read-only tools wired into chat and headless AI agents in #6755 (W01), covering security posture, PAM, monitoring, integrations, and script library reads.

Tool	Tier	Description
get_software_compliance	1	Software policy violations for a device or organization
query_compliance_policies	1	List configuration compliance policies
get_elevation_history	1	Admin elevation (PAM) request history for a device
get_peripheral_activity	1	USB and peripheral device connect/disconnect activity
get_user_risk_scores	1	Security risk scores for users in an organization or site
get_user_risk_detail	1	One user’s risk history and contributing events
get_compliance_status	1	Compliance status of devices against one compliance policy
get_browser_security	1	Browser extension inventory and browser policy compliance
get_sensitive_data_overview	1	Sensitive data scan findings (chat only, never agents)
get_executive_summary	1	Latest executive summary: device health, alert trends, patch compliance, SLA statistics
query_custom_fields	1	Custom field definitions and a device’s custom field values
query_psa_status	1	PSA connection status
query_analytics	1	SLA compliance and device capacity predictions
list_monitors	1	List monitor definitions visible to the caller
get_monitor	1	Get a monitor definition with its policy attachments
get_ip_history	1	IP address history for a device
get_network_changes	1	Detected network changes for a device or site
list_remote_sessions	1	List remote-access sessions
query_agent_versions	1	Agent versions in use, and devices eligible to upgrade
query_webhooks	1	List configured webhooks and recent delivery status
search_script_library	1	Search the script library by name, tag, or content
list_scripts	1	List scripts in the library
get_script_details	1	Script content, versions, and execution stats
list_script_templates	1	List built-in script templates
get_script_execution_history	1	Past script runs for one script, one device (deviceId, every script run there), or both; optional since
list_device_restore_point_attempts	1	A device’s Windows System Restore checkpoint attempts — taken, skipped or failed before each patch run, script or install (v0.124.0+)
get_trust_page_status	1	Whether an organization’s public trust page exists and is published, its public path and freshness, controls met, current and expiring declarations, and pending document access requests; never edits the page (v0.124.0+)

Security & device operations (writes)

These tools change security settings or act on devices. They are available in AI chat and to AI agents. Approval follows the tier shown; see Tool tiers for what each tier means.

Tool	Tier	Description
request_elevation	3	Request a temporary admin elevation on a device. Needs a second approver (four-eyes)
revoke_elevation	2	Revoke an active elevation and request cleanup on the device
create_remote_session	3	Open a remote terminal or file session. Needs a second approver (four-eyes), and respects the remote-access policy and the concurrent-session limits
manage_processes (list)	2	List running processes
manage_processes (kill)	3	Terminate a process
manage_scheduled_tasks (list)	2	List scheduled tasks
manage_scheduled_tasks (run/disable/enable)	3	Run, disable or enable a scheduled task
registry_operations (read_key/get_value)	2	Read Windows registry keys and values
registry_operations (set_value/create_key/delete_key)	3	Change the Windows registry
trigger_agent_restart	3	Restart a silent agent through the watchdog (needs devices.recover_agent)
trigger_agent_upgrade	3	Bring an agent to the version it is meant to run. It never overrides an agent version pin, never re-pushes a version the agent already has, and never downgrades
manage_software_policy (list/get)	1	Read software policies. No approval needed
manage_software_policy (create/update/delete)	3	Change software policies
manage_browser_policy (list)	1	List browser policies. No approval needed
manage_browser_policy (create/update/apply)	3	Change browser policies or roll one out to devices
manage_peripheral_policy (create/update/disable/add_exception/remove_exception)	3	Create or change peripheral (USB) policies and exceptions
remediate_sensitive_data (encrypt/quarantine/secure_delete/accept_risk/false_positive/mark_remediated)	3	Encrypt, quarantine, delete or close out a sensitive-data finding
remediate_software_violation	3	Uninstall software that violates a policy
assign_security_training	2	Assign security training to a user
configure_network_baseline	3	Configure a network baseline. Needs approval because it schedules recurring discovery scans
acknowledge_network_device	2	Acknowledge a newly discovered network device

sync_edr_data (Tier 2, v0.124.0+) queues an immediate EDR sync — endpoints and detections — for one connection, the connections serving one organization, or every connection of the partner. Results arrive over the following minutes. It is limited to three calls per ten minutes.

Three of these (user risk scores and detail, plus C2C item search from the backup table above) are available in chat but never to autonomous AI agents — see AGENT_DENIED_READ_TOOLS in the codebase for the current denylist, which also covers query_c2c_jobs, get_sensitive_data_overview and two M365 identity reads.

Security policy tools

These tools read security status and compliance, and manage security recommendations, access reviews, audit-policy baselines, security and compliance policies, disk-encryption recovery keys and PAM elevation rules. They are available in AI chat and over MCP. Text they return that came from a device or a person (hostnames, local admin account names, audit deviations, policy and rule names, review notes) is shown to the model as untrusted data, never as instructions.

Tool	Tier	Description
get_security_compliance	1	Security dashboard, score breakdown, 7/30/90-day trend, and AV, firewall, encryption, password-policy and local-admin status by device (view). Only what agents reported: no estimated firewall rules or encryption volumes
manage_security_recommendations (list)	1	List security recommendations with their status per organization
manage_security_recommendations (complete/dismiss)	2	Mark a recommendation completed or dismissed for one organization. Nothing changes on devices; reopen it in the web app
manage_access_reviews (list/get)	1	View access reviews: each member’s role, permissions and recorded decision
manage_access_reviews (decide_item)	2	Record keep (approved) or remove (revoked) on one member. Nothing changes until a person completes the review in the web app; you cannot decide on your own access
manage_access_reviews (create)	3	Start an access review of every member of the partner or organization. A review cannot be deleted
manage_audit_baselines (list/compliance/device_results)	1	View audit-policy baselines, compliance across the devices you can see, and one device’s deviations
manage_audit_baselines (request_apply)	2	Ask for a Windows audit baseline to be applied to devices. A different person approves the request in the web app, and applying it is also done there
manage_audit_baselines (create)	3	Create a baseline. An active baseline replaces the current one for that OS and starts daily audit-policy collection on those devices
manage_compliance_policies (deactivate)	3	Turn off a compliance policy and close its alerts. Permanent: nothing re-enables it. A partner-wide policy needs a second approver (four-eyes)
manage_security_policies (list)	1	List antivirus/EDR security policy templates
manage_security_policies (create/update)	3	Create or change a security policy template. There is no delete; a partner-wide create needs a second approver (four-eyes)
manage_recovery_keys (list)	1	BitLocker or FileVault key escrow status for a device. Never the key itself, and never who revealed it
manage_recovery_keys (rotate/collect)	3	Rotate a Windows BitLocker recovery key (the old key stops working), or re-collect a device’s keys into escrow
manage_pam_rules (list_rules/get_config/list_signer_groups)	1	View PAM elevation rules, the default verdict for unmatched requests, and signer groups
manage_pam_rules (create_rule/update_rule/delete_rule/set_config/create_signer_group/update_signer_group/delete_signer_group)	3	Change PAM rules, the default verdict or signer groups. The assistant can never create an auto-approve rule, and in an organization that has one it can only add rules or rename them

Three actions are never available to the assistant or to MCP, by design: completing an access review (it removes members and ends their sessions), approving an audit-baseline apply request, and revealing a recovery key. Do these in the web app. Writes to access reviews, compliance policies and PAM rules need a session that has completed MFA.

Access reviews and PAM rules are available in chat and over MCP only; AI agents are never offered them. AI agents can read the rest. Their recommendation, security-policy, compliance-policy and recovery-key writes become proposals that a person approves, and they cannot create audit baselines or apply requests. A session limited to some sites or devices cannot change organization-wide records (security policies, recommendation status, compliance policies, audit baselines) or use access reviews.

Software tools

These tools manage the software catalog, search winget and Homebrew, deploy catalog packages, read and change the software installed on a device, review the software inventory, and handle fleet findings and custom fields. They are available in AI chat and over MCP. Package, vendor and version names, finding titles and custom-field values are shown to the model as untrusted data, never as instructions.

Tool	Tier	Description
manage_software_catalog (list/get)	1	View catalog packages with their versions and winget/Homebrew install methods. Download links show the host only
manage_software_catalog (create/update/import_package)	2	Add a package (or import one with its install methods) or edit its name, vendor and description. A partner-wide package (ownerScope: partner) needs approval
manage_software_catalog (add_version/update_version/promote_version/add_install_method/update_install_method/delete_install_method/archive)	3	Change which installer a package uses, or archive it. Armed auto-install policies and automations pick up the new installer without another approval, so each change is approved. Versions with install scripts, and partner-wide packages, are changed in the web app
search_packages	1	Search winget (Windows) or Homebrew (macOS) for a package id to add as an install method
manage_software_deployments (list/get/summary/results)	1	View software deployments and each device’s result
manage_software_deployments (cancel)	2	Cancel a deployment’s pending installs
manage_software_deployments (create/retry)	3	Install a catalog package on up to 100 named devices, or retry failed installs. If the package’s installer changes after you approve, the deployment is refused
get_device_software	1	Installed software on one device
manage_device_software (update/uninstall)	3	Update or uninstall an application on one device
bootstrap_homebrew	3	Install Homebrew on one Mac (needs a signed-in admin user)
manage_software_inventory (list/names/devices)	1	Software seen across the fleet, its allow/block status, and the devices that have it
manage_software_inventory (approve/deny/clear)	3	Add software to the organization’s default allowlist or blocklist, or remove it. If that policy removes unapproved software automatically, this changes what is uninstalled
manage_fleet_findings (acknowledge/dismiss/reopen)	2	Acknowledge, dismiss or reopen a fleet finding (read them with get_fleet_findings)
manage_custom_fields (create_definition/update_definition)	2	Create or edit a custom field definition. A partner-wide definition needs approval to create and is edited in the web app
manage_custom_fields (delete_definition/set_values)	3	Delete a definition (every device’s value for it is removed), or set values on one device (the previous values are returned)

Not available to the assistant or over MCP: uploading an installer, the installer download link, pre- and post-install scripts, deploying to groups or a whole organization, fleet-finding remediation, and the managed-software download-origin policy. Every software, fleet-finding and custom-field write needs a session that has completed MFA.

AI agents can read the software tools. Their catalog, deployment, inventory, fleet-finding and update writes become proposals that a person approves. They are never offered uninstall, bootstrap_homebrew or manage_custom_fields (custom-field values decide dynamic-group membership, which can widen what an agent may act on). A session limited to some sites or devices cannot change the catalog or the inventory allow/blocklists.

Device inventory and ops tools

These tools read a device’s activity timeline, agent health and recorded process snapshots, report which other management products are on the fleet, and manage per-device records: a device’s function, linked device profiles, hand-entered (manual) assets and warranties. They are available in AI chat and over MCP. Event messages, process names, product names, asset notes and warranty text are shown to the model as untrusted data, never as instructions.

Tool	Tier	Description
get_device_events	1	Activity timeline for one device: what ran, changed or failed, and who or what did it. Actor emails, IP addresses and raw event details are not returned
get_device_health	1	The Breeze agent’s latest health report for one device: overall state and each component’s state and reason
get_process_samples	1	The recorded top-process snapshot for one device at or before a time (default now). History, not a live process list
get_management_posture	1	Other management products (RMM, endpoint security, backup, MDM, …) detected across the fleet, per organization; pass product for the devices running one
search_agent_logs	1	source: watchdog returns only the Breeze watchdog’s health journal; source: agent leaves it out. Without source both are returned, as before
manage_device_function (get)	1	One device’s function (domain controller, file server, …)
manage_device_function (set)	3	Set or clear a device’s function. Dynamic groups can target devices by function, so the change is approved
manage_device_links (list/get/for_device)	1	Linked device profiles: multi-boot records of one machine, or a VM host and its guests
manage_device_links (create/update/dissolve)	2	Link 2-10 device records, add or remove members, rename, or unlink them all. Each device keeps its own data
manage_manual_assets (list)	1	Hand-entered inventory without an agent (spare laptops, phones, printers)
manage_manual_assets (create/update/link/unlink)	2	Add or edit a hand-entered asset, retire it (retiredAt), or link it to an agent device or discovered asset
manage_manual_assets (delete)	3	Permanently delete a hand-entered asset. Retire it instead to keep the record
manage_device_warranty (get/expiring)	1	One device’s warranty, or devices whose warranty ends within a number of days
manage_device_warranty (refresh)	3	Re-check one device’s warranty with its manufacturer now. The device’s serial number is sent to the manufacturer, so the refresh is approved. Devices whose warranty the agent collects (HP) are refused
browse_device_event_log (list_logs)	2	List a Windows device’s event logs, read live from its agent (runs without a prompt, with an audit row)
browse_device_event_log (query/get_event)	3	Read event text from a device’s live event logs. Security and Application logs can hold credentials and personal data, so every read is approved. search_logs reads the ingested copy without reaching the device
manage_tenant_variables (list)	1	Tenant variables that scripts receive as {{var.key}}. Secret values are never shown
manage_tenant_variables (create/update/delete)	3	Change a value that every script on the organization’s devices receives. Secret variables and partner-wide variables are changed in the web app; a partner-wide variable can be created here
manage_support_sessions (list/get)	1	Quick Support sessions and whether their temporary client is online
manage_support_sessions (end)	3	End a Quick Support session: the temporary client removes itself from the person’s machine. Sessions are started in the web app

Every write, and every live event-log read, needs a session that has completed MFA. A session limited to some sites or devices cannot change tenant variables or use Quick Support sessions.

AI agents can read these tools. Their link-group and manual-asset writes need an allowlist entry; a manual-asset delete and a warranty refresh become proposals that a person approves. Agents are never offered manage_tenant_variables writes (an agent that runs scripts must not also choose their inputs) or manage_device_function (set): a device’s function decides dynamic-group membership, which can widen what an agent may act on. A session bound to specific devices cannot change link groups or use manual assets, and its reads only show the devices it may see.

---

Context-Aware Help Panel

The dashboard includes a slide-out documentation panel that opens the correct docs page based on your current location in the app. Open it with Cmd+Shift+H (macOS) or Ctrl+Shift+H (Windows/Linux).

Page you’re on	Docs page that opens
Scripts	Scripting docs
Patches	Patch management docs
Devices	Device management docs
Configuration Policies	Policy docs

The help panel coordinates with the AI chat sidebar — opening one closes the other. When the AI assistant references documentation in a chat response, the links open directly in the help panel instead of a new browser tab.

AI Documentation Search

The AI assistant can search all documentation pages using the search_documentation tool (Tier 1, auto-execute). The search index is built at compile time and covers all pages in the docs site.

Tool	Tier	Description
search_documentation	1	Search documentation pages by keyword and return relevant sections with direct links

---

Playbook AI Tools

The AI can list and execute remediation playbooks as part of automated incident response.

Tool	Tier	Description
list_playbooks	1	List available playbooks, optionally filtered by category
execute_playbook	3	Execute a playbook on a device with runtime variables (requires approval)
get_playbook_history	1	View execution history for a playbook or device

See Playbooks for playbook definitions and step types.

---

Ticketing & Billing AI Tools

Breeze also provides AI tools for the PSA side of the platform — tickets, invoices, the billing catalog, contracts, and quotes:

Tool	Description
list_invoices / get_invoice / manage_invoices	Browse invoices and manage the invoice lifecycle — drafts, lines, assembling a draft from an organization’s billable period or a ticket, issuing, voiding, payments, and Stripe pay links
search_catalog / get_catalog_item	Search the partner billing catalog, including per-organization price overrides and bundles
lookup_distributor_product	Look up live TD SYNNEX price and availability for a distributor SKU that isn’t in your catalog yet — handy when pricing a quote line for a product you don’t stock. Reseller cost is hidden for organization-scoped callers
list_contracts / get_contract / manage_contracts	Browse recurring contracts and manage drafts, lines, and lifecycle (activate, pause, resume, cancel)

The ticket, quote, billing-catalog, and PSA admin write tools are tiered per action:

Tool	Tier	Description
manage_tickets (list/get/list_work_types/list_links/merge_preview)	1	Search and read tickets, work types, and ticket links
manage_tickets (create/assign/link_alert/unlink_alert/create_from_alert/link_device/draft/link_ticket/unlink_ticket)	2	Open and assign tickets, link alerts, devices, and related tickets, and store a draft reply for human review
manage_tickets (log_time_entry/start_timer/stop_timer/update_time_entry)	2	Track time against tickets
manage_tickets (bulk_update)	2	Assign, change the status of (not resolve), or set the priority of up to 50 tickets that all belong to one organization. A batch spanning organizations is refused whole, and there is no bulk delete
manage_tickets (comment/update_status/update_fields)	2	Internal notes and ticket updates. A public comment (isPublic: true), resolving a ticket or setting a custom status, and changing the requester need approval (Tier 3)
manage_tickets (edit_comment/delete_comment)	3	Edit or delete a comment — customer-visible text with no restore
manage_tickets (merge)	3	Merge two tickets of one organization — irreversible, one approver
manage_tickets (move_org)	3	Move a ticket to a different organization (four-eyes)
manage_quotes (create_draft/update/delete_draft/add_block/update_block/delete_block/reorder_blocks/add_manual_line/add_catalog_line/update_line/remove_line/move_line/reorder_lines)	2	Draft a quote: header, content blocks, and lines on a quote that has not been sent
manage_quotes (decline/create_pay_link)	3	Record a customer’s decline, or create a payment link
manage_quotes (send)	3	Send a quote to the customer (four-eyes)
manage_billing_catalog (create_item)	2	Add a billing catalog item (inert until a quote, invoice, or contract uses it)
manage_billing_catalog (update_item/archive_item/set_price/remove_price/set_org_price/remove_org_price/set_bundle_components)	3	Change items, price-book prices, organization price overrides, and bundles — contract renewals bill the live price
manage_saved_filters (list/get)	1	List and view saved device filters
manage_saved_filters (create/delete)	2	Create or delete a saved device filter
manage_tags (list)	1	List device tags
manage_tags (add/remove)	2	Add or remove device tags. AI agents can never change tags, because tags can change which devices an agent is scoped to
manage_notification_channels (list)	1	List notification channels
manage_notification_channels (test)	2	Check a channel’s configuration (sends nothing)
manage_notification_channels (create/update/delete)	3	Create, repoint, or delete a channel; the approver sees the destination host. Delete is four-eyes
test_webhook	3	Send a real test delivery to a webhook

Billing lifecycle tools

These tools read and change how your organizations are billed: rate cards and work types, invoice defaults and each organization’s tax, terms and billing contact, the agreement templates customers sign, signed agreements, and which contract lines bill a device. They are available in AI chat and over MCP. Rate-card, settings and device-billing tools need a partner-scoped session, as the matching pages do. Template text, rate-card names and notes, invoice footers and signer names are shown to the model as untrusted data, never as instructions.

Tool	Tier	Description
get_pax8_status	1	Pax8 integration health and company readiness. Full partner access required
search_pax8_products (search/provision_details/dependencies/pricing)	1	Mapped products, provisioning requirements, commitments and live vendor cost
manage_pax8_subscriptions (list/drift)	1	Subscription seat counts and differences from billed quantities. Full partner access required
manage_pax8_subscriptions (sync/link/unlink)	3	Supervised: sync every organization’s snapshots or link/unlink a subscription’s billing contract line. A link decides which contract line later Pax8 orders bill; unlink means staged changes on the subscription will be refused
manage_pax8_orders (list/get/preview)	1	Orders and read-only previews with live cost evidence, customer price and active commitment rules
manage_pax8_orders (create_draft/add_line/update_line/remove_line)	2	Stage and edit order drafts; nothing is purchased
manage_pax8_orders (preflight)	3	Supervised: send staged content to Pax8 for an isMock dry run. Nothing is purchased
manage_pax8_orders (submit)	3	Four-eyes: two people approve a billable order estimated at Pax8’s current rate. Changed inputs, prices or commitments refuse submission. Every CANCEL is terminal; its commitment term appears on the approval card. Not offered to AI agents
manage_pax8_orders (reconcile)	3	Supervised: record an approved attempt from vendor evidence without sending another write. Ambiguous outcomes stay unknown; a concurrent billing edit is preserved and flagged as billing_conflict
manage_billing_profiles (list/get/list_work_types/get_org_profile)	1	Rate cards with their hourly rates per work type, work types, and the card an organization is billed by
manage_billing_profiles (create/update/archive/set_rows/clone/create_work_type/update_work_type)	3	Change rate cards or work types. They price every organization of the partner, so every change is approved and needs full partner access. The previous values come back with the result. Archiving a work type, and AI price-list edits after a card is created, are done in the web app
manage_billing_profiles (set_org_profile/clear_org_profile)	3	Choose, or clear, the rate card one organization is billed by
manage_billing_settings (get_partner/get_org/currency_impact/reporting_totals)	1	Invoice defaults, one organization’s tax, terms, billing contact and address, a preview of what an organization currency change would leave behind, and approximate totals across currencies
manage_billing_settings (update_partner)	3	Change invoice defaults for every organization: currency, tax, invoice prefix and terms, footer, terms and conditions, automatic emails and the seller contact. Needs full partner access. Agreement reminder defaults are set on Billing → Agreements
manage_billing_settings (update_org)	3	Change one organization’s tax, payment terms, billing contact (who receives its quotes and invoices) or billing address. A currency change and the rate-card assignment are made elsewhere
manage_contract_templates (list/get/get_version/usage)	1	Agreement templates, their versions and where each is used. Version bodies are read one at a time with get_version
manage_contract_templates (create/update)	2	Create or rename an organization’s agreement template. For a partner-wide template, pass ownerScope: partner; the change is then approved and needs full partner access
manage_contract_templates (create_version/publish/archive)	3	Add a draft version, publish it so quotes and signature requests can use it, or archive the template. None of these can be undone. Partner-wide templates are versioned, published and archived in the web app
manage_contract_documents (list)	1	Signed agreements and whether each is filed under a contract. Signer email addresses are not returned
manage_contract_documents (link)	3	File a signed agreement under a contract of the same organization. It cannot be undone
get_device_billing	1	Which active contract lines bill a device, or why it is not billable
manage_contracts (preview_invoice)	2	What a contract’s next billing run would invoice: the period, each line’s quantity and price, subtotal, tax and total, whether it is issued and emailed automatically, and to whom. Nothing is created
manage_contracts (generate_invoice)	3	Generate the contract’s due invoice. It needs a second approver (four-eyes). The call repeats the preview’s period, total, auto-issue setting and recipients, and the approval card shows them. If anything changed before release (a device added, a price, tax rate or billing contact edited, the period already billed) the release is refused and nothing is generated. When the contract issues automatically, the invoice is issued and emailed only if its total is still the approved one, and only to the approved recipients. Contracts with a block-of-hours line are generated in the web app
manage_accounting_sync (status/owed_operations/customers/mappings/income_accounts/remote_candidates)	1	QuickBooks or Xero: connection status, payments waiting to sync, customers, customer and item mappings, income accounts, and records to link to. A remote_candidates search term is applied in Breeze and never sent to the provider
manage_accounting_sync (link_mapping/unlink_mapping/sync_mapping)	3	Link a Breeze organization or catalog item to a QuickBooks or Xero record, unlink it, or re-send a linked one. Linking and syncing overwrite the provider’s record with Breeze’s details. Creating a new record in the provider is done in the web app
manage_accounting_sync (push/push_bulk)	3	Push one invoice, or up to 10, into QuickBooks or Xero. It needs a second approver (four-eyes); the push also syncs the invoice’s customer and items if they are not synced yet. If the invoice, its customer or items, or the connection change before release, the release is refused

Pax8 submission refusal codes (the PAX8_SUBMIT_REFUSAL_CODES contract): PREVIEW_MISMATCH, PRICE_CHANGED, COMMITMENT_CHANGED, COST_UNKNOWN, COMMITMENT_AMBIGUOUS, TOO_MANY_LINES, NOT_PENDING, COMPANY_UNRESOLVED, TERM_UNKNOWN, QUANTITY_UNKNOWN, SUBSCRIPTION_NOT_FOUND, PRODUCT_UNKNOWN, CONTRACT_LINE_MISSING, CLAIM_LOST, INTEGRATION_UNAVAILABLE, BASELINE_NOT_CAPTURED, INTEGRATION_CHANGED, PREFLIGHT_FAILED, CONFLICT. Claim refusals mean nothing was sent by that attempt; preview and approve again. Post-send persistence conflicts require inspection and reconciliation of unknown writes. A successful vendor write with billingConflicts requires a person to resolve billing without resubmitting it.

The existing contract and invoice reads gained one view each: get_contract with periodId returns that billing period’s outcome (devices billed, uncovered and flagged, overages), list_contracts with view: currency_mismatches lists contracts whose currency differs from their organization’s, and get_invoice with lineId pages the devices one invoice line billed.

Rate-card, work-type and settings writes need a session that has completed MFA. A session limited to some sites or devices cannot change an organization’s rate card, billing settings or agreement templates, or file a signed agreement.

AI agents can read these tools. Rate-card and settings writes become proposals that a person approves. Agents are never offered template writes or manage_contract_documents (link): agreement templates and signed agreements are the legal documents customers sign. Agents are never offered generate_invoice or any accounting write.

The accounting tool needs a partner-scoped session with access to every organization, as the Integrations page does, and every write needs a session that has completed MFA. Connecting, disconnecting and configuring the accounting connection, importing customers as organizations and starting a payment reconcile stay in the web app.

PSA configuration and ticket operations

These tools configure the ticketing side of the platform. They are available in AI chat, and AI agents get the read actions. Partner-wide configuration is changed for every organization at once, so every write needs approval; deleting configuration needs a second approver (four-eyes).

Tool	Tier	Description
manage_ticket_config (get_config/get_org_settings/list_categories/list_domains)	1	Read ticket statuses, priorities, an organization’s SLA overrides, categories, and customer email domain mappings
manage_ticket_config (update_org_settings/create_category/update_category/delete_category/reorder_categories/create_status/update_status/reorder_statuses/set_priorities/create_domain/update_domain)	3	Change categories, statuses, priority and SLA settings, an organization’s SLA overrides, and which organization a sender’s domain routes to. Needs full partner access; statuses, priorities and domains also need an admin role
manage_ticket_config (delete_domain)	3	Remove a customer email domain mapping (four-eyes)
manage_ticket_checklist_templates (list/get)	1	Read checklist templates and their steps
manage_ticket_checklist_templates (create)	2	Create an organization checklist template. A partner-wide template needs approval (Tier 3)
manage_ticket_checklist_templates (update/add_item/update_item/remove_item/reorder_items)	3	Edit a template or its steps
manage_ticket_checklist_templates (delete)	3	Delete a template (four-eyes). A template still used by a deliverable is refused
manage_ticket_inbox (list)	2	Review inbound email the router could not place. The sender, subject and error text come from outside and are treated as untrusted
manage_ticket_inbox (convert/dismiss)	3	Turn one email into a ticket in an organization you choose (the sender becomes the requester), or dismiss it. Neither can be undone
manage_ticket_attachments (list)	1	List the files on a ticket
manage_ticket_attachments (read_content/attach_from_artifact)	2	Read the text of an attachment (images, PDFs and other binary files return their details only), or attach an AI run artifact to a ticket. The attachment stays pending until a person posts a comment with it
manage_ticket_attachments (delete)	3	Permanently delete an attachment
manage_ticket_forms (list/available)	1	Read ticket intake forms, and the forms an organization can use
manage_ticket_forms (create/update)	3	Create or change a customer-visible intake form
manage_ticket_forms (delete)	3	Delete an intake form (four-eyes)
manage_ticket_response_templates (list)	1	Read the partner’s canned ticket replies
manage_ticket_response_templates (create/update)	3	Create or change a canned reply
manage_ticket_response_templates (delete)	3	Delete a canned reply (four-eyes)
manage_time_suggestions (list)	1	See your own time-entry suggestions from remote sessions for a day
manage_time_suggestions (confirm/dismiss/undo)	2	Log a suggestion as a time entry, dismiss it, or restore a dismissed one. Your own suggestions only

AI agents can use the read actions. A write an agent attempts becomes a proposal that waits for a person to approve it. Most of these write actions refuse to run under an agent identity, because the record they create or change needs a signed-in person as its author; creating a ticket form and converting an inbound email are the two that run as the approver once approved. Make the other changes in chat or in the web app. Writing the same settings from the web app is unchanged.

Alert correlation and signal triage

These tools read how alerts group together and what is behind a device’s unusual behaviour, and record the outcome. They are available in AI chat; AI agents get the read actions and can propose the device-level writes.

Tool	Tier	Description
get_alert_correlations (groups/get/by_alert/links/analyze/evaluation/explain)	1	See groups of correlated alerts, the correlations around one alert, how well grouping is working, and root-cause evidence for a group (built from the group’s alerts and logs, with no AI model call). Log text comes from the device and is treated as untrusted. Not available to a run that is limited to specific devices
manage_alert_correlations (acknowledge_group/resolve_group/acknowledge_related)	2	Acknowledge or resolve every alert in a correlation group you can see, or an alert and its related alerts. Chat and MCP only: an AI agent cannot act on a whole group
manage_alert_correlations (feedback/rca_feedback)	2	Tell Breeze a correlation was split, merged or dismissed, or that a root-cause analysis was helpful, not helpful, edited or used in a ticket
manage_device_anomalies (list)	1	List unusual metric behaviour detected on a device
manage_device_anomalies (dismiss/resolve)	2	Set an anomaly’s status. There is no way back to open
manage_device_anomalies (promote)	3	Raise a real alert from an anomaly. The alert notifies your alert channels, so it needs approval
get_fleet_health (history/offenders/evaluation/org_summary)	1	A device’s reliability score over time, the services and components behind its score, how well the scores predict real failures, and an organization rollup with its worst devices
reliability_feedback	2	Label a device’s reliability score as a confirmed failure, a replaced device, or a false alarm. Changes nothing on the device

A dry run of an alert rule is not available: the old per-rule test was retired with the previous alerting model.

Network topology

These tools read a site’s network map and manage its manual entries, recurring checks and monitoring templates. They are available in AI chat and over MCP for people with the topology permissions; AI agents do not get them (an agent keeps the read-only topology investigation tools). Every call names a site and is limited to the sites you can already see.

Tool	Tier	Description
get_topology_graph (graph/nodes/node/relationship/evidence/group_members/expansion/health)	1	Read a site’s network map: devices and links, one device or link in detail, the evidence behind a link, the members of a group, and health. Addresses and raw collector data are not returned, and names collected from the network are treated as untrusted text
run_topology_diagnostic (collectors/get)	1	See which devices can run a connectivity check, and read a check’s result
run_topology_diagnostic (start/cancel)	2	Start a fixed gateway, DNS, internet or trace-route check from a device at the site, or stop one. Runs in your own signed-in session and is rate limited per user, site and organization
manage_topology_manual	2	Add, change or remove a hand-drawn switch, router, access point or link. A stale revision is refused. Nothing here binds a device or moves one between sites
manage_topology_monitoring (list_policies/list_targets/get_settings)	1	View a site’s recurring checks, probe targets and effective topology settings
manage_topology_monitoring (upsert_policy/delete_policy/upsert_target/delete_target/patch_settings)	2	Change a site’s recurring checks, probe targets or settings. Arming a recurring check stays a person’s action in the topology page, and changing a check that is already armed disarms it
manage_topology_templates (list_templates/list_versions/site_options)	1	View monitoring templates (partner-wide or one organization’s), their versions, and the published versions a site can apply
manage_topology_templates (create_template/update_template/create_version)	2	Draft a template or a new version. Nothing takes effect until a version is published. Partner-wide templates need full partner access
manage_topology_templates (publish_version/revoke_template)	3	Publish a version so sites can apply it, or revoke a template permanently (this disables every check that uses it). Needs approval
apply_topology_template (preview)	2	Preview what applying a template would change on named sites. Changes nothing
apply_topology_template (apply)	3	Apply a previewed template to its sites, replacing their monitoring configuration. Needs approval. Sites outside the approving session’s organization report their own outcome
apply_topology_template (status)	1	See how an application is progressing, site by site

SNMP and network monitoring

These tools read and manage SNMP monitoring templates, read SNMP metric history, check a discovered asset on demand, keep the shared known-guest list, and read or sync the partner’s UniFi integration. Template, metric and asset-check tools follow your organization and site access and are also available to AI agents. The known-guest and UniFi tools act on partner-wide state, so they need full partner access and are available in AI chat and over MCP only. Every write needs a signed-in session that has satisfied MFA, the same as the matching page.

Tool	Tier	Description
manage_snmp_templates (list/get/browse_oids/validate_oids)	1	View SNMP templates (the OIDs polled per device class), search known OIDs, and check an OID list. Names and descriptions are treated as untrusted text
manage_snmp_templates (create/update/delete)	2	Create, change or delete a custom template. Built-in templates are read-only, a template still used by a device cannot be deleted, and the delete result keeps the old row so it can be recreated. A session limited to some sites or devices cannot change a template, because every site in the organization reads it
get_snmp_metrics (history/dashboard)	1	Bucketed SNMP history (interface traffic, uptime and other OIDs) for one discovered asset, with a capped number of series, or the SNMP dashboard
probe_network_asset	2	Check now: ping a discovered asset from an online agent in the same site and report reachable or not. One probe per asset at a time; waits a few seconds, otherwise reports pending
manage_known_guests (list)	1	View the partner-wide list of known guest MAC addresses that discovery does not flag
manage_known_guests (add/delete)	2	Add or remove a known guest MAC address for every organization of the partner
get_unifi_status (status/hosts/collectors/mappings/telemetry/sync_runs/controller_sites)	1	Read the partner’s UniFi integration: connection, consoles and sites (a read-only call to the vendor), collectors, site mappings, device and client telemetry for one site, and the last 20 sync runs. Vendor payloads, keys and error bodies are not returned
trigger_unifi_sync	2	Queue a manual sync of the UniFi integration, then read the outcome with get_unifi_status sync_runs

Connecting or disconnecting UniFi, editing site mappings and collectors, and the retired per-device SNMP polling, test and threshold pages are not available as tools. The old SNMP device and threshold endpoints are deprecated; per-asset SNMP settings and network-monitor alert rules replace them.

AI agent read tools

These tools let you ask the assistant what the AI has done and is planning. They only read: starting, changing or cancelling a schedule, an operator task or a Fleet Design is a separate, approval-gated action. Text they return (task objectives, hand-off notes, step and timeline text, Fleet Design markdown) is shown to the model as untrusted data, never as instructions.

Tool	Tier	Description
get_device_ai_activity	1	Count the scripts and commands the AI dispatched to one device in the last 7 to 30 days. Add source (execution or command) and sourceId to see who started that one action (AI assistant, AI agent or flow). A device you cannot see is reported as not found
list_operator_tasks	1	List the multi-step tasks the AI operator is running or has finished, newest first, with state, objective and what happens next
get_operator_task	1	One operator task: targets, steps, the newest 500 timeline events, the plan it proposed and the agent runs behind it. Credential hand-over details are never shown; an account the task created shows only its credential state
list_ai_agent_schedules	1	When AI agents run on a schedule, including the effective schedule after an organization override of a partner baseline. A partner baseline’s fleet-wide run summary is shown only to callers with access to every organization of the partner
list_fleet_designs	1	List completed Fleet Design reports (up to 100) with function, watch and rule counts
get_fleet_design	1	One Fleet Design report as markdown (capped at 60,000 characters), with counts and when it was generated

The operator task and Fleet Design tools describe a whole organization, so a session limited to some sites or devices cannot use them. The operator task tools are available in AI chat and over MCP only: AI agents are never offered them, because task text is written by people and by other agent runs. The device, schedule and Fleet Design tools are also available to AI agents; a device-bound agent can read only its own device.

All seven tools are now available in the assistant chat, not just over MCP. AI agents get the read actions by default and the write actions only when the agent’s tool allowlist names them; tag changes are never available to agents. Public ticket comments, resolving a ticket, and changing a ticket’s requester need approval, while internal notes do not. The billing price book tool is manage_billing_catalog (renamed from manage_catalog; the old name keeps working over MCP for one release).

Financially binding or high-impact actions — issuing or voiding an invoice, recording or voiding a payment, contract lifecycle changes, sending a quote, changing a catalog price, and moving a ticket to another organization — are classified Tier 3, so they wait for a human approval rather than auto-executing. Drafting and editing (create_draft, adding lines, updating a draft) stays Tier 2 no matter how large the draft’s total is — the tier boundary here is reversibility, not financial size: a draft is an internal, editable record until the commit action (send/issue/activate) exposes it beyond Breeze. See the MCP Server documentation for per-tool tiers, scopes, and required role permissions, including the note on why this differs from the tenant-structure gating on tools like create_org.

---

Model refusals

Some Claude models decline requests that resemble harmful work. The category is reported with the refusal, for example cyber for malware analysis or exploit-like scripts. Security triage in an RMM can trigger this even when the work is legitimate.

When a model declines, Breeze:

• records the refusal and its category against the model in AI usage;
• shows the technician “The model declined this request (category: …)”, lists the other models they are allowed to switch to, and links here;
• ends an AI agent run as Blocked — model refused, with the category in the run outcome.

Configuring a refusal fallback

An administrator can give a model a refusal fallback under Partner Settings → AI Providers & Models. The fallback must be another enabled model on the same connection, so it never changes who pays for the request. On the Claude API, Breeze asks Anthropic to retry the turn on the fallback model in the same request. On a catalog provider, Breeze retries once itself. The turn is billed at the rate of the model that served it.

Choosing a model in chat

When your partner allows it, the chat composer has a model menu. It lists the models you may use, with each model’s context size and price per million tokens. A model your role can’t use is shown greyed out with the role that grants it. Next to the menu, set the options the chosen model supports:

• Effort — how much the model reasons before answering (adaptive-thinking models).
• Fast — a faster, more expensive mode, shown where your administrator enables it and the model supports it; its rate is shown next to the switch.
• Thinking — an on/off switch for models that think with a fixed budget.

Your choice applies from your next message. While the model reasons, the chat shows Thinking…. Under each answer, the chat shows the model and options that actually answered. A model can decline a request and hand it to another, and Fast can be unavailable for a moment, so this can differ from what you picked.

Administrators can lock a feature to one model under Partner Settings → AI Providers & Models → Defaults by feature (turn off Users may choose). The menu is then hidden for that feature.

From v0.124.0 a partner can hold more than one Anthropic connection under AI Providers & Models. Only the first takes over the features that used the platform key, and models found on a later connection arrive disabled until an administrator enables them. See Bring your own LLM key.

Switching models mid-conversation

Switching to another model keeps the conversation when the new model is on the same AI connection and the conversation fits its context window. Breeze counts the conversation with the new model before switching. Otherwise Breeze offers Continue with the new model in a new chat: the newly chosen model summarises the conversation and a linked chat starts from that summary. Your message is kept either way, and you can choose Keep the current model instead.

The model an AI agent uses

An agent’s settings include a Model field: use the AI agents default, or pick one of the models allowed for AI agents. Picking a model that needs a permission requires you to hold that permission.

Failover and escalation roles

Backup models

Each feature’s default model can have an ordered list of up to five backup models (Partner Settings → AI Providers & Models → Defaults by feature). Breeze moves to the next usable backup when the model:

• is disabled or retired, or its connection stops working;
• is rate-limited, overloaded or returns a server error;
• rejects its API key, or the provider account is out of quota.

Backups follow the same rules as the default: the feature’s allowed models, plan, data residency and tool support. A backup that was just tried, or that is cooling down after a recent failure, is skipped. A model cools down for about a minute after a rate limit, overload or server error, and for up to 15 minutes after a key or quota failure. Replacing the connection’s API key clears that wait at once. If every backup is unusable, Breeze still uses the default rather than failing the feature.

A timeout is never a reason to fail over, because the provider may still have run the request. A model you picked yourself in the chat model menu is never swapped for a backup.

Billing

Each attempt is billed to the source that served it: Breeze AI credits for a Breeze-provided model, or your provider account for a model on your own API key. An attempt the provider rejected costs nothing. Failover moves between Breeze credits and your own API key only when Allow failover between Breeze credits and your own API key is on for that feature. Before a backup on Breeze credits is used, Breeze checks your credit balance and AI budget again.

Chat

A chat message is never re-sent to another model partway through a reply. If a message fails before the model writes anything, the model cools down and your next message uses a backup. A conversation that already has history only moves to a backup on the same AI connection, and only when the conversation fits that model; otherwise it stays on its model. Your own model choice is kept, and Breeze goes back to it once it recovers. If the model you were using was disabled or retired, the conversation moves to the backup for good.

Escalation roles for AI agents

The AI agents feature has three roles, each with its own default and backups:

Role	Runs
Triage	Alert verdicts, ticket triage, and sweeps in shadow mode
Analysis	Investigations, narratives, designs, patch planning, and full runs in shadow mode
Remediation	Full runs and sweeps in act mode, which can change devices

A role you leave unset uses the AI agents default. An agent pinned to a specific model in its own settings keeps that model; the role’s allowed models and backups still apply to it. An agent run fails over only before the model has written anything or run a tool, so no action is ever run twice.

Organization overrides

Organization Settings → AI → Model defaults can narrow a feature’s backup list (or set it to no backups) and can turn cross-funding failover off. An organization cannot add backups the partner did not allow, and cannot turn cross-funding failover on. An organization that overrides the AI agents default keeps the partner’s triage, analysis and remediation defaults, within the models it allows.

Usage

The Failovers column on the AI usage page counts calls that a backup model served.

Troubleshooting

Tier 3 action pending but never executing

Tier 3 actions require manual approval. Open Security → AI Risk → Approval History and approve or reject the pending request.

AI Risk Engine dashboard shows no data

The dashboard requires at least one AI tool execution to have occurred. Ask the AI assistant a question about your fleet to generate initial data.

Context entries not appearing for a device

The AI loads context only for the specific device you ask about. Try: “What do you know about [hostname]?” to trigger explicit context loading.

set_device_context not working

set_device_context is Tier 2 (auto-execute + audit logged) and requires devices:write permission. Confirm your role includes write access to devices.