Back to skill

Security audit

inference-aiops

Security checks for vulnerabilities and agentic risk

Overview

This is a disclosed inference-operations skill, but it exposes high-impact cluster write actions without built-in MCP read-only or approval controls, so it needs review before production use.

Use this only with explicit operational controls: prefer read-only network paths for observation sessions, require authentication or an authenticating proxy for Ray/vLLM endpoints, keep write-capable credentials out of general agent sessions, require human approval outside the tool before high-risk MCP writes, and protect ~/.inference-aiops/ plus INFERENCE_AIOPS_MASTER_PASSWORD. Dry-run, audit, and undo help with review and recovery, but they do not prevent an unwanted production change.

Vulnerability Patterns
  • Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
  • Embedded Malicious CodeShips malicious scripts inside the skill and executes them locally
Findings (1)

T09 · Insecure Skill Coding Practices

Error
Location
references/agent-guardrails.md:11
Finding

High-risk MCP operations lack enforced authorization and confirmation

Content
View full analysis

Vulnerability Details

File Location: references/agent-guardrails.md:11-25, 38-44; corroborated by SKILL.md:144-147 and references/setup-guide.md:91-96
Vulnerability Type: Missing authorization enforcement for destructive operations
Risk Level: High

Evidence

markdown
## Authorization is not this tool's job — decide it where it belongs

Whether a write should happen is your decision, or the environment's. The tool
does not gate it — there is no read-only switch and no approval prompt to
configure.
markdown
| "Confirm before anything disruptive" | Every traffic-affecting operation (`model_undeploy`, `deployment_redeploy`, `scale_to_zero`, `scale_replicas_down`, `drain_replica`, `replica_restart`, `lora_unload`, `model_sleep`) takes `dry_run=True` for a preview and is `risk=high`. ⚠️ **The double confirmation is a CLI feature, and only `scale_to_zero` has a CLI command** — every other one is reachable only over MCP, where nothing prompts. Keep your own confirmation for those. |

The project further states in SKILL.md:144-147 that there is “no read-only switch, policy file, or approval gate,” and in references/setup-guide.md:91-96 that an approver is not required.

Technical Analysis

The Skill exposes traffic-affecting MCP operations that can scale deployments down, undeploy models, restart or drain replicas, unload adapters, and suspend models. Although these operations are labeled high risk and accept a dry-run option, the MCP execution path does not require a dry run, explicit operator approval, an approval token, or interactive confirmation.

The documented CLI double-confirmation does not protect most of these operations because only scale_to_zero has a corresponding CLI command. The remaining high-risk operations are reachable through MCP, where confirmation is delegated entirely to agent behavior. Audit logging, risk labels, and undo descriptors are detective or recovery controls; they do not authorize or pr ...[truncated 2281 chars]

Remediation
View remediation

Remediation Suggestions

  1. Default every MCP session to read-only and require an explicit policy grant before exposing write tools.
  2. Require a short-lived approval token for each high-risk operation. Bind the token cryptographically or server-side to:
    • The target environment.
    • The exact tool name.
    • All material parameters.
    • The approving operator.
    • An expiration time.
  3. Enforce a mandatory dry-run for high-risk operations and reject execution unless the exact preview was subsequently approved.
  4. Add an MCP-layer confirmation state machine rather than relying on prompt instructions or agent compliance.
  5. Support policy controls that can independently disable undeploy, scale-down, drain, restart, unload, and sleep operations.
  6. Apply least-privilege credentials and network segmentation so observation sessions cannot reach control-plane write endpoints.
  7. Preserve auditing and undo records as secondary controls, but do not treat either mechanism as authorization.
  8. For operations without reliable undo, require stronger confirmation and clearly display the expected service impact before accepting approval.
Vulnerability Patterns
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
  • Tool MisuseTool Parameter Abuse, Chaining Abuse, Unsafe Defaults
  • Rogue AgentSelf-Modification, Session Persistence
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
Findings (11)

Tool Parameter Abuse

High
Category
Tool Misuse
Confidence
70% confidence
Finding

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).

Content

Scanner excerpt · references/cli-reference.md (reported line 17)May include surrounding context.

bash
inference-aiops init                      # interactive wizard: engine (vllm/sglang/tgi) + host + port
inference-aiops doctor [--skip-auth]      # config + secret store + connectivity — vLLM: Ray + vLLM; SGLang/TGI: engine health + inventory
inference-aiops mcp                       # start the MCP server (stdio transport)

Tool Parameter Abuse

High
Category
Tool Misuse
Confidence
70% confidence
Finding

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).

Content

Scanner excerpt · references/setup-guide.md (reported line 125)May include surrounding context.

bash
inference-aiops init                      # interactive wizard: engine (vllm/sglang/tgi) + host + port
inference-aiops doctor [--skip-auth]      # config + secret store + connectivity — vLLM: Ray + vLLM; SGLang/TGI: engine health + inventory
inference-aiops mcp                       # start the MCP server (stdio transport)

Session Persistence

Medium
Category
Rogue Agent
Confidence
88% confidence
Finding

The skill explicitly persists operational state locally, including an audit database and an encrypted secret store, and also documents a legacy plaintext environment-variable token fallback. Persistent local storage of sensitive operational metadata and credentials increases exposure to local compromise, accidental disclosure, and long-lived secret retention, especially in shared agent or CI environments.

Content

Scanner excerpt · SKILL.md (reported line 23)May include surrounding context.

md
metadata: {"openclaw":{"requires":{"anyBins":["inference-aiops","uvx"]},"optional":{"env":["INFERENCE_AIOPS_CONFIG","INFERENCE_AIOPS_MASTER_PASSWORD"]},"homepage":"https://github.com/AIops-tools/Inference-AIops","emoji":"🚀","os":["macos","linux"]}}
compatibility: >
  Standalone, self-governed GPU-inference 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 ~/.inference-aiops/ (relocatable via INFERENCE_AIOPS_HOME).
  Auth: a bearer token is OPTIONAL — many vLLM / Ray stacks run open. When the API requires one it is stored ENCRYPTED in ~/.inference-aiops/secrets.enc (Fernet/AES-128 + scrypt-derived key) — never plaintext on disk. Run 'inference-aiops init' to onboard, or 'inference-aiops secret set <target>' to add one. The store is unlocked by a master password from INFERENCE_AIOPS_MASTER_PASSWORD (non-interactive/MCP/CI) or an interactive prompt (CLI on a TTY). A legacy plaintext env var INFERENCE_<TARGET_NAME_UPPER>_TOKEN is still honoured as a fallback (migrate with 'inference-aiops secret migrate'). The token is sent as an Authorization: Bearer header at request time and held only in memory; it is never logged or echoed.
  State-changing operations require double confirmation at the CLI layer and support --dry-run. All write tools pass through the @governed_tool decorator (budget/runaway guard + audit + risk-tier label — it records, not authorizes). The fragile prod ops — scale_replicas_down, scale_to_zero, drain_replica, lora_unload, model_sleep, replica_restart, model_undeploy, deployment_redeploy — are high-risk with a dry_run preview; reversible writes (scale, autoscale-config, routing, sleep, LoRA load) record an undo descriptor.
  Engines: vLLM (with its Ray Serve control plane), SGLang, and TGI. SGLang/TGI are single-process servers with engine-agnostic observability (health, running-model 
...[truncated 25 chars]

Session Persistence

Medium
Category
Rogue Agent
Confidence
91% confidence
Finding

The skill states that it delivers both read and write operations and does not itself enforce authorization, approval gates, or a read-only mode; audit only records actions after the fact. In an agent setting, this means a misrouted prompt, prompt injection, or over-permissive environment can trigger destructive cluster changes such as scale-to-zero, drain, undeploy, or restart without an embedded technical control to stop them.

Content

Scanner excerpt · SKILL.md (reported line 142)May include surrounding context.

md
## 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 environment you connect it with (a network path that only reaches the
read/metrics endpoints, a Ray dashboard without its job-submission API — writes
then fail at the server). There is no read-only switch, policy file, or approval

Autonomous Decision Making

Medium
Category
Excessive Agency
Confidence
96% confidence
Finding

This guidance explicitly states that the tool does not enforce read-only mode or approval for write actions, shifting all protection to external environment controls or the model prompt. In an agentic setting, prompt-level restrictions are not security boundaries, so a misconfigured deployment or prompt-injected model could invoke disruptive write operations without an in-tool authorization check.

Content

Scanner excerpt · references/agent-guardrails.md (reported line 15)May include surrounding context.

md
## Authorization is not this tool's job — decide it where it belongs

Whether a write should happen is your decision, or the environment'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 environment you connect it to.** Restrict the network path so the tool

Unsafe Defaults

Medium
Category
Tool Misuse
Confidence
60% confidence
Finding

Tool defaults are unsafe or overly permissive (e.g. disabled TLS verification, no authentication, world-writable permissions). Unsafe defaults widen the attack surface.

Content

Scanner excerpt · SKILL.md (reported line 135)May include surrounding context.

md
| `model_sleep` | write (**high**) | vLLM | `POST /sleep?level=N` | dev-mode only; dry-run; level 1 offloads weights to CPU RAM, 2 discards them; captures `wasSleeping` → undo wakes only what it suspended |
| `model_wake` | write (med) | vLLM | `POST /wake_up` | dev-mode only; dry-run; records **no** undo — vLLM never reports the prior sleep *level*, so re-sleeping would be a guess |

> **Sleep Mode needs `VLLM_SERVER_DEV_MODE=1`.** vLLM registers `/sleep`, `/wake_up`
> and `/is_sleeping` only under that flag, so on a normal production server these
> three tools report that the route does not exist and why — a 404 here means the
> server was not started in dev mode, not that an id was stale. Sleep Mode suspends

Unsafe Defaults

Medium
Category
Tool Misuse
Confidence
60% confidence
Finding

Tool defaults are unsafe or overly permissive (e.g. disabled TLS verification, no authentication, world-writable permissions). Unsafe defaults widen the attack surface.

Content

Scanner excerpt · references/capabilities.md (reported line 66)May include surrounding context.

md
| `model_sleep` | write (**high**) | vLLM | `POST /sleep?level=N` | dev-mode only; dry-run; level 1 offloads weights to CPU RAM, 2 discards them; captures `wasSleeping` → undo wakes only what it suspended |
| `model_wake` | write (med) | vLLM | `POST /wake_up` | dev-mode only; dry-run; records **no** undo — vLLM never reports the prior sleep *level*, so re-sleeping would be a guess |

> **Sleep Mode needs `VLLM_SERVER_DEV_MODE=1`.** vLLM registers `/sleep`, `/wake_up`
> and `/is_sleeping` only under that flag, so on a normal production server these
> three tools report that the route does not exist and why — a 404 here means the
> server was not started in dev mode, not that an id was stale. Sleep Mode suspends

Unsafe Defaults

Medium
Category
Tool Misuse
Confidence
80% confidence
Finding

Tool defaults are unsafe or overly permissive (e.g. disabled TLS verification, no authentication, world-writable permissions). Unsafe defaults widen the attack surface.

Content

Scanner excerpt · references/cli-reference.md (reported line 17)May include surrounding context.

bash
inference-aiops init                      # interactive wizard: engine (vllm/sglang/tgi) + host + port
inference-aiops doctor [--skip-auth]      # config + secret store + connectivity — vLLM: Ray + vLLM; SGLang/TGI: engine health + inventory
inference-aiops mcp                       # start the MCP server (stdio transport)

Unsafe Defaults

Medium
Category
Tool Misuse
Confidence
80% confidence
Finding

Tool defaults are unsafe or overly permissive (e.g. disabled TLS verification, no authentication, world-writable permissions). Unsafe defaults widen the attack surface.

Content

Scanner excerpt · references/setup-guide.md (reported line 125)May include surrounding context.

bash
inference-aiops init                      # interactive wizard: engine (vllm/sglang/tgi) + host + port
inference-aiops doctor [--skip-auth]      # config + secret store + connectivity — vLLM: Ray + vLLM; SGLang/TGI: engine health + inventory
inference-aiops mcp                       # start the MCP server (stdio transport)

Session Persistence

Medium
Category
Rogue Agent
Confidence
88% confidence
Finding

The guide normalizes running vLLM/Ray endpoints without authentication by stating bearer tokens are optional because many stacks 'run open.' For an inference control plane, unauthenticated access can expose model APIs, metrics, inventory, and potentially scaling or deployment operations, substantially increasing the risk of unauthorized use or cluster manipulation.

Content

Scanner excerpt · references/setup-guide.md (reported line 11)May include surrounding context.

uv tool install inference-aiops

text

## 2. (Optional) create a bearer token

A bearer token is **optional** — many vLLM / Ray stacks run open. Only create
one if your API requires it (e.g. vLLM started with `--api-key`, or an

Sudo/Root Execution

Medium
Category
Privilege Escalation
Confidence
80% confidence
Finding

Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.

Content

Scanner excerpt · references/setup-guide.md (reported line 85)May include surrounding context.

md
- The token is **never** written to disk in plaintext. It lives only in
  `~/.inference-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 is never
  stored.
- A legacy plaintext env var `INFERENCE_<TARGET_NAME_UPPER>_TOKEN` is still
  honoured as a fallback with a deprecation warning — migrate with

Static analysis

No suspicious patterns detected.