Security audit
Security checks for vulnerabilities and agentic risk
This endpoint-management skill is mostly transparent and purpose-aligned, but it can reboot or reconfigure managed devices without a built-in read-only mode or approval gate.
Install only for a managed-endpoint environment where you are comfortable giving an agent access to fleet operations. Start with a read-only management-console account or API token, verify doctor and read-only workflows first, and grant write permissions only when you have an external approval process for profile changes and reboots. Treat the audit log as after-the-fact accountability, not as an authorization control.
Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).
endpoint-aiops init # interactive onboarding wizard
endpoint-aiops doctor [--skip-auth] # config + secret store + connectivity (/version)
endpoint-aiops mcp # start the MCP server (stdio transport)
Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).
endpoint-aiops init # interactive onboarding wizard
endpoint-aiops doctor [--skip-auth] # config + secret store + connectivity (/version)
endpoint-aiops mcp # start the MCP server (stdio transport)
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
endpoint-aiops secret set [--value ] # store API key (hidden prompt if no --value) endpoint-aiops secret list # names only — values never shown endpoint-aiops secret rm endpoint-aiops secret migrate # import legacy plaintext .env (ENDPOINT__APIKEY) endpoint-aiops secret rotate-password # re-encrypt under a new master password
The skill documents persistent local storage of sensitive operational state, including encrypted API secrets on disk and session-bearing authentication for some dialects, plus an optional legacy plaintext environment-variable credential path. Even if credentials are encrypted at rest, disk persistence expands the attack surface on multi-user or compromised hosts, and the fallback plaintext env var weakens the overall secret-handling model.
metadata: {"openclaw":{"requires":{"anyBins":["endpoint-aiops","uvx"]},"optional":{"env":["ENDPOINT_AIOPS_CONFIG","ENDPOINT_AIOPS_MASTER_PASSWORD"]},"homepage":"https://github.com/AIops-tools/Endpoint-AIops","emoji":"💻","os":["macos","linux"]}}
compatibility: >
Standalone, self-governed managed-endpoint operations. The governance harness (audit, policy, token/runaway budget, undo, risk-tiers) is bundled in the package — no external skill-family dependency.
All write operations are audited to a local SQLite DB under ~/.endpoint-aiops/ (relocatable via ENDPOINT_AIOPS_HOME).
Credentials: the endpoint-management server's API key is stored ENCRYPTED in ~/.endpoint-aiops/secrets.enc (Fernet/AES-128 + scrypt-derived key) — never plaintext on disk. Run 'endpoint-aiops init' to onboard, or 'endpoint-aiops secret set <target>' to add one. The store is unlocked by a master password from ENDPOINT_AIOPS_MASTER_PASSWORD (non-interactive/MCP/CI) or an interactive prompt (CLI on a TTY). A legacy plaintext env var ENDPOINT_<TARGET_NAME_UPPER>_APIKEY is still honoured as a fallback with a deprecation warning (migrate with 'endpoint-aiops secret migrate'). The credential is presented using the scheme the target's dialect declares — a static Authorization: Bearer header for the generic dialect, or an HTTP Basic login yielding a session cookie for igel-ums (which also needs a 'username' on the target). It is held only in memory; credentials are never logged or echoed.
State-changing operations (assign-profile, reboot) require double confirmation at the CLI layer and support --dry-run. All write tools pass through the @governed_tool decorator (pre-check + budget guard + audit + risk-tier label). endpoint_assign_profile is high-risk and reversible (captures the prior profile, records an inverse reassign undo descriptor); endpoint_reboot is medium-risk with no undo (a reboot has no safe inverse).
Webhooks: none — no outbound network calls beyond the configured endpoint-managemen
...[truncated 24 chars]
The skill metadata repeatedly advertises a bundled governance harness with policy, guarded writes, and risk-tier controls, but the Governance & Safety section says there is no read-only switch, policy file, or approval gate and that write authorization is left to the agent or server-side account permissions. That mismatch can cause operators and downstream agents to overtrust the skill's built-in safety properties and invoke destructive actions under the false assumption that local policy enforcement exists.
Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.
## Governance & Safety
The skill delivers reads and writes and records them; it does **not** decide
whether a write is permitted. That is your agent's judgement, or the permission
of the account you connect it with (a management-console account or API token
scoped to a read-only role — writes then fail at the server). There is no
read-only switch, policy file, or approval gate.
The file claims some guardrails are guaranteed by the harness, but later carves write authorization out of the harness entirely and pushes it to account permissions or prompting. That contradiction can cause unsafe deployment assumptions: operators may trust the tool to enforce governance when in fact write safety depends on external configuration, increasing the chance of accidental fleet-wide changes.
The documentation explicitly states that the tool does not gate writes and provides no read-only switch or approval control, despite the skill metadata advertising a built-in governance harness. In an endpoint-management context with reboot and profile-assignment write actions, relying only on external account scoping or prompt discipline creates a real path for unintended or over-broad destructive actions if the agent is misprompted, compromised, or connected with excessive privileges.
The documentation confirms there is 'no approval prompt to configure' for write actions, enabling an autonomous agent to perform endpoint reboot or profile changes without an in-tool human confirmation barrier. In a managed-endpoint fleet, a mistaken or adversarially induced write can disrupt many devices quickly, and reboot specifically has no safe inverse, magnifying operational impact.
## Authorization is not this tool's job — decide it where it belongs
Whether a write should happen is your decision, or the account's. The tool does
not gate it — there is no read-only switch and no approval prompt to configure.
The two right places to control read vs write:
- **The account you connect with.** Give it a management-console account or API
Tool defaults are unsafe or overly permissive (e.g. disabled TLS verification, no authentication, world-writable permissions). Unsafe defaults widen the attack surface.
endpoint-aiops init # interactive onboarding wizard
endpoint-aiops doctor [--skip-auth] # config + secret store + connectivity (/version)
endpoint-aiops mcp # start the MCP server (stdio transport)
Tool defaults are unsafe or overly permissive (e.g. disabled TLS verification, no authentication, world-writable permissions). Unsafe defaults widen the attack surface.
endpoint-aiops init # interactive onboarding wizard
endpoint-aiops doctor [--skip-auth] # config + secret store + connectivity (/version)
endpoint-aiops mcp # start the MCP server (stdio transport)
Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.
uv tool install endpoint-aiops
## 2. Create credentials — the shape depends on the dialect
The target's **dialect** decides the port, the API base path *and* how to
authenticate, so create the credential the dialect expects:
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
- The API key is **never** written to disk in plaintext. It lives only in
`~/.endpoint-aiops/secrets.enc`, encrypted with Fernet (AES-128-CBC + HMAC),
the key derived from your master password via scrypt. Only a per-store random
salt and the ciphertext are on disk (chmod 600); the master password itself is
never stored.
- A legacy plaintext env var `ENDPOINT_<TARGET_NAME_UPPER>_APIKEY` is still
honoured as a fallback with a deprecation warning — migrate with
The text says audit is 'the guarantee, and it is not bypassable,' presenting the governance harness as mandatory. Immediately after, it documents that the runaway guard can be disabled with ENDPOINT_RUNAWAY_MAX=0, which weakens the earlier absolute safety framing and creates conflicting expectations about what parts of governance are enforced versus optional.
The text explicitly says these variables 'gate nothing' and are 'never required', while also framing them as capturing approval context for destructive operations. That is a mild intent/documentation contradiction because readers could infer governance enforcement from the surrounding 'governance harness' language even though the guide states the skill itself does not decide write permission.
No suspicious patterns detected.