Endpoint-AIops is a community-maintained open-source project, licensed under the MIT License, and is not affiliated with, endorsed by, or sponsored by any endpoint management vendor. It targets managed endpoint device fleets (thin clients, VDI endpoints, and other centrally managed devices), providing governed AI operations capabilities with a built-in governance framework: unified audit logging, token/runaway budget guards, revoked token records, and descriptive risk classification. The tool is vendor-neutral and communicates with the endpoint management server's REST API (Bearer authentication) through configurable dialects, with no dependencies other than httpx and the MCP SDK. The test suite is based on simulated data, and the endpoint management REST paths have not yet been exercised against a real management server; see docs/VERIFICATION.md for details.
Purpose
This tool serves managed endpoint operations, providing read and write operations with full logging. It does not itself decide whether a given write is permitted; that determination is made by the agent or the permissions of the connected account. If it is given a management console account or API token with a read-only role, write operations will fail server-side. Therefore it has no read-only switch, policy file, or approval threshold to configure. The only thing the tool guarantees is that no operation is silent—whether via MCP or CLI, every call leaves an audit record in ~/.endpoint-aiops/audit.db, and reversible writes still capture the pre-change state and record it when a reverse operation exists.
Main Capabilities
Login storm analysis: during a "everyone logs in at 9 a.m. at the same time" event, detect concurrent login bursts within a sliding window and rank the endpoints and users slowing down login and startup times. Each flag comes with concrete numbers, not black-box conclusions.
Patch/configuration drift: discover endpoints that deviate from the endpoint fleet (patch level too old, agent version abnormal, OS build or configuration profile inconsistent). If no baseline is declared, a baseline is derived from the fleet majority, so it works even when there is no golden image yet.
The CLI provides commands such as init, overview, endpoint list/get/assign-profile/reboot, session list/storm, drift report/patch, secret set/list/rm/migrate/rotate-password, doctor, mcp. The MCP server (endpoint-aiops mcp or endpoint-aiops-mcp) includes 13 tools (10 read, 3 write), each wrapped in the bundled @governed_tool governance layer.
Capability matrix (13 MCP tools): analysis-class tools (login_storm_analysis, drift_report, patch_status, patch_compliance, endpoint_health_score) can accept injected records for purely offline analysis; endpoint_health_score and patch_compliance support injection only, while the rest can also pull live from configured targets.
Usage
It can be installed as a Claude Code plugin; a single install provides both the skill and the MCP server. The MCP server is obtained via uv and pinned to the package version declared by the plugin, so audit records can be traced back to the written code. It can also be installed as an OpenClaw plugin; the same bundle is published on ClawHub. After installation, the OpenClaw gateway must be restarted to load the plugin. The MCP server is obtained via uv and pinned to a specific version, so uvx must be in PATH.
It can also run as a CLI or standalone MCP server (stdio). Credential configuration is done via endpoint-aiops init. The management server API key is stored in encrypted storage ~/.endpoint-aiops/secrets.enc (Fernet + scrypt) and is never written to disk in plaintext. Unlock methods: via ENDPOINT_AIOPS_MASTER_PASSWORD (MCP/CI) or an interactive prompt (CLI). Note: exported variables can be read by every process started by that shell and recorded in shell history; on shared or long-lived hosts, use an interactive prompt, or inject from a secrets manager for a single command.
Governance and security
Every operation (MCP and CLI) passes through the bundled @governed_tool governance layer. It records, but does not authorize. Auditing: every call (arguments, result, status, duration, risk tier, and operator-provided approver/reason) is recorded to ~/.endpoint-aiops/audit.db, which can be relocated via ENDPOINT_AIOPS_HOME. CLI writes the same rows as MCP, with no unaudited entry point. The runaway guard is the securityBackstop, not an authorization threshold: repeatedly invoking the same operation in a tight loop trips the circuit breaker, preventing an agent that gets stuck from consuming calls/time without limit; it can be disabled with ENDPOINT_RUNAWAY_MAX=0, and optional hard caps are available via ENDPOINT_MAX_TOOL_CALLS / ENDPOINT_MAX_TOOL_SECONDS. Undo records: reversible writes record a reverse descriptor based on the captured pre-change state. Risk tiers: descriptive labels on audit lines, derived from risk_level, and do not constitute thresholds. Each tool declares risk_level and keeps it consistent with the [READ]/[WRITE] labels in tests and documentation; that tier is carried into the audit line as a descriptive level.
Reversibility: endpoint_assign_profile (high risk) captures the previous profile and records a reverse "reassign previous profile" undo descriptor. endpoint_reboot (medium risk) captures the previous online state for the audit record, but declares no undo (a reboot has no safe inverse operation). Safety: state-changing CLI operations (endpoint assign-profile, endpoint reboot) require double confirmation and support --dry-run.
Data conventions: missing is not the same as empty. Fields not reported by the management server return null, never "", and keys are always present, so a missing patch level is not mistaken for blank. Truncated lists declare themselves: {"items": [...], "returned": N, "limit": L, "truncated": bool}, and truncated is measured, not inferred. Accompanying totals (driftedCount, behindCount, nonCompliantCount, stormCount, and health summaries) are always complete, untruncated numbers.
Dialects
A dialect is the API shape of the management server: resource paths, response field names, transport defaults (port and API base path), and authentication method. It is set per target in config.yaml; endpoint-aiops init asks and prints which one is configured. The generic default is not an IGEL configuration: IGEL serves IMI on port 8443 at /umsapi/v3, and a target that retains the generic shape will get a 404 on the first probe. If the server really does not have a certainresources, the dialect states them explicitly rather than guessing URLs: IMI does not expose login/session-start resources, so calling session_list and login_storm_analysis against an igel-ums target returns a didactic error naming the missing resource rather than calling a fictitious path. The dialect also chooses the authentication scheme: IMI rejects the static Bearer token sent by the generic dialect, so it logs in via HTTP Basic at POST /umsapi/v3/login and carries the returned JSESSIONID cookie (once per connection, cached thereafter). Because the scheme comes from the dialect, credential failures and dialect errors are reported differently: a 401 indicates the scheme presented and, when the server sends a WWW-Authenticate challenge, the scheme actually required. Special note for IGEL: a UMS account with insufficient permissions receives an empty list rather than a 403. endpoint-aiops doctor separates authentication from reachability probing and warns when a successful login returns no endpoints, because "no devices" and "no permission to view devices" are otherwise indistinguishable. The test suite is based on simulated data, and no dialect in this package has been exercised against a real management server, so no claim of support for any specific product (including IGEL) is made. generic is a placeholder shape, not a vendor API. igel-ums is a documented but unverified dialect; its paths and field aliases are modeled on IGEL's published IMI documentation, and the authentication scheme is documented in the IMI manual and consistent with the behavior of three independent real IMI clients, but none have been run against a device, because IGEL UMS has no free edition and cannot be verified on the maintainer's hardware. Both dialects are recorded as UNKNOWN-pending-live in docs/VERIFICATION.md.
Applicable scenarios
Suitable for operations scenarios involving centrally managed device fleets such as thin clients and VDI endpoints, especially for locating performance bottlenecks during login storm events, discovering endpoint patch and configuration drift, and performing governed read and write operations under security governance that requires auditing, reversibility, and risk classification.
Limitations
The tool does not decide whether writes are permitted; there is no read-only switch, policy file, or approval threshold. Testing is based on simulation and has not been verified on a real management server. Support for any specific vendor product is not recommended. Missing fields return null. Truncated lists have an explicit envelope. Community-maintained, MIT licensed. For smaller/local models, see agent-guardrails.md. When capabilities or a server dialect are missing, issues or PRs are welcome.
