A practical control model for AI-assisted endpoint work.

Separate advice from authority

An AI explanation, a drafted action plan, a read-only diagnostic, and an endpoint mutation are different classes of work. Dayrook models them as explicit autonomy levels so a customer can understand what is allowed before any model is asked to act.

Operational AI uses a customer-owned provider connection and selected model. The provider key is stored only as a Vault or KMS reference and is verified before use. Migration planning is a separate use case with a separate token decision; it does not silently become the provider for day-to-day endpoint actions.

Choose the narrowest useful autonomy level

The default level is 0, or off. Level 1 explains state; level 2 drafts; level 3 can run approved read-only diagnostics; level 4 can execute pre-approved low-risk actions; and level 5 can run a defined policy-bound remediation chain with stop conditions and post-action evidence.

Assignment can be narrowed by tenant, customer, site, device group, module, alert rule, workflow, or policy. Raising autonomy to levels 4 or 5 requires authorized roles and MFA or owner approval as defined by policy. High-risk actions remain blocked outside that approved envelope.

Preserve the endpoint command chain

AI does not get a side door to an endpoint. The server still checks tenant and region, RBAC or ABAC, entitlement, billing state, approval, and maintenance policy. The command service then issues a signed envelope bound to the tenant, agent, action, parameter hash, expiry, nonce, issuer, and policy version.

The enrolled agent verifies identity, signature, expiry, replay state, and local allowed actions before dispatch. A model cannot create arbitrary shell access outside approved command envelopes. Revoked agents stop accepting commands except for approved decommission behavior.

Design bounded workflows before prompts

A useful automation begins with a deterministic trigger, allowed evidence, exact action class, approval rule, timeout, retry ceiling, stop condition, and verification test. The prompt helps interpret evidence or draft the plan inside that structure; it is not the structure itself.

Dayrook’s target scope includes patterns such as an approved customer script first, a condition check second, and AI diagnostics or low-risk remediation only if the alert remains active. Each transition should produce a visible reason and an audit event.

• Define the alert or workflow state that starts the run.
• Limit the devices, customers, action classes, tools, and data the run may use.
• Require a risk summary, affected objects, rollback or explicit no-rollback reason, and approval state.
• Set timeout, retry ceiling, repeated-failure stop, and customer-cancel behavior.
• Re-check the original condition and endpoint health after the action.

Protect secrets while preserving evidence

Prompts must not contain raw API keys, passwords, private keys, Vault secrets, or unrestricted tokens. Tenant policy also governs whether customer payloads may be summarized at all. Raw provider keys never return to the browser after save and do not belong in logs, exports, screenshots, or support tooling.

The reviewable record can preserve provider and model, policy version, masked input summary, output hash, decision, approvals, commands, stop reason, and result. That is enough to audit the chain without recreating the sensitive prompt payload.

Sources reviewed

Vendor pages can change after the review date above. Open the current source and confirm plan, contract, regional, and product details before purchasing.

• NIST AI Risk Management Framework
• NIST Generative AI Profile

Continue through this topic

Use the product and operator guides that carry this decision into setup, daily work, control, and verification.

• Assist and AI automation
• Workflow automation
• RMM and endpoint management
• Governance
• Agent trust guide