Ae1
- Category
- analysis-evasion
- Confidence
- 100% confidence
- Finding
Referenced artifact was not completely inspected
- Content
md - `references/setup-guide.md` — onboarding, credentials, and connectivity
Security audit
Security checks for vulnerabilities and agentic risk
This skill is coherent for reverse-proxy administration, but it should be reviewed because it can change live routing/configuration and use stored proxy credentials without an enforced read-only or approval boundary.
Install only if you intend the agent to administer Traefik, Caddy, or HAProxy. Start with read-only or narrowly scoped proxy API credentials, avoid putting the master password in plaintext MCP config on shared machines, keep ~/.proxy-aiops protected, and require human review outside the skill before enabling write-capable sessions against production traffic.
Referenced artifact was not completely inspected
- `references/setup-guide.md` — onboarding, credentials, and connectivity
The guardrails document explicitly states the tool does not gate writes and has no read-only switch or approval prompt, which contradicts the skill metadata's claim of a built-in governance harness with policy/approval-style protections. In a proxy administration skill with live config-changing capabilities, this mismatch can cause operators to overtrust safety controls that do not actually prevent destructive or unauthorized writes.
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).
proxy-aiops init # interactive wizard: platform, base_url, TLS verify, encrypted secret
proxy-aiops doctor # config + secrets + connectivity (probe per platform)
proxy-aiops doctor --skip-auth # skip the connectivity probe
proxy-aiops overview # one-shot: version + routes/services + upstream health
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
proxy-aiops secret set # store encrypted (hidden prompt) proxy-aiops secret list # names only, never values proxy-aiops secret rm proxy-aiops secret migrate # import legacy plaintext .env proxy-aiops secret rotate-password # re-encrypt under a new master password
The skill advertises a built-in governance/policy harness near the top-level metadata, but later documentation explicitly says there is no policy file, approval gate, or read-only switch and that writes are never blocked. That mismatch is security-relevant because operators or upstream agents may rely on the earlier claim and permit the skill in contexts where they assume enforcement exists, while the tool can still perform state-changing proxy operations.
The skill stores long-lived proxy API credentials locally and supports non-interactive unlocking via PROXY_AIOPS_MASTER_PASSWORD, which creates session/persistence risk on multi-user hosts, CI runners, or compromised agent environments. The risk is increased by honoring a legacy plaintext secret environment variable fallback, because environment-based secrets are easier to exfiltrate from process state, logs, or misconfigured orchestration.
- Bash
metadata: {"openclaw":{"requires":{"anyBins":["proxy-aiops","uvx"]},"optional":{"env":["PROXY_AIOPS_CONFIG","PROXY_AIOPS_MASTER_PASSWORD"]},"homepage":"https://github.com/AIops-tools/Proxy-AIops","emoji":"🔀","os":["macos","linux"]}}
compatibility: >
Standalone, self-governed reverse-proxy operations across Traefik (API /api/..., metrics-text counters via /metrics), Caddy (admin API, default localhost:2019 — carries the write surface) and HAProxy (Data Plane API v2 /v2/..., HTTP Basic auth). Each target in the config names its own platform, and a name-keyed platform registry selects the API shape; an explicit support matrix raises teaching errors for ops a platform cannot do (traefik writes → its providers; caddy error counters → access logs; haproxy certs → the .pem pipeline), never a silent no-op. 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 ~/.proxy-aiops/ (relocatable via PROXY_AIOPS_HOME).
Credentials: the HAProxy Data Plane API password (required) or an optional Basic-auth credential for Traefik/Caddy is stored ENCRYPTED in ~/.proxy-aiops/secrets.enc (Fernet/AES-128 + scrypt-derived key) — never plaintext on disk. Traefik and Caddy usually run unauthenticated on localhost, so their secret is optional (no store entry = no auth header). Run 'proxy-aiops init' to onboard (it asks for the platform), or 'proxy-aiops secret set <target>'. The store is unlocked by a master password from PROXY_AIOPS_MASTER_PASSWORD (non-interactive/MCP/CI) or an interactive prompt (CLI on a TTY). A legacy plaintext env var PROXY_<TARGET_NAME_UPPER>_SECRET is still honoured as a fallback with a deprecation warning (migrate with 'proxy-aiops secret migrate'). Secrets are never logged or echoed.
State-changing operations pass through the @governed_tool decorator (budget guard + audit + risk-tier labelling). delete_co
...[truncated 25 chars]
The documentation states the skill can perform writes but does not itself decide whether a write is permitted, and that there is no read-only switch, policy file, or approval gate. In a high-impact reverse-proxy administration context, that means any agent invocation with sufficient backend credentials can change routing, weights, or configs without an internal control boundary, making accidental or unauthorized state changes much more dangerous.
## 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 read-only HAProxy Data Plane API role, a
scoped Traefik/Caddy admin API — writes then fail at the server). There is no
read-only switch, policy file, or approval gate.
The document normalizes autonomous write capability by stating there is no approval prompt or read-only switch, leaving prevention of unsafe changes entirely to external account scoping or the model prompt. For a skill that can modify reverse proxy configuration and traffic handling, this materially increases the chance of unintended or unauthorized operational changes if the connected account is overprivileged or the model ignores prompt-only restrictions.
## 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 the HAProxy Data Plane API a read-only
The file presents strong guarantees about audit coverage ('there is no unaudited entry point') while earlier disclaiming internal authorization/gating responsibilities. This creates intent-level tension in the documented security model: the tool is described as lacking internal control over whether writes occur, yet the surrounding language implies comprehensive governance guarantees. That is a contradiction in documented intent about what security properties the harness actually enforces.
This markdown file describes live write operations such as deleting config paths, loading full configs, and changing HAProxy server state/weight, but it does not include an explicit warning that these actions can affect availability or production traffic. Although risk levels are shown, the description lacks a clear user-facing caution about operational impact to user data, privacy, or system integrity.
Persisting undo descriptors in ~/.proxy-aiops/undo.db with replayable parameters can expose sensitive operational data such as backend names, server identifiers, config paths, and potentially embedded config values. If local filesystem permissions are weak or the host is shared, an attacker or lower-privileged user could mine this history for infrastructure intelligence or use retained parameters to assist unauthorized rollback/replay operations.
| `undo_list(limit?)` | recorded undo descriptors, newest first, with their `_undo_id` |
| `undo_apply(undo_id, dry_run?)` | replays the recorded inverse (governed like any other write) |
`undo_apply` is governed like any other write (audited, capturing a before-state
where the inverse is itself reversible). Undo descriptors are recorded to
`~/.proxy-aiops/undo.db`; their params match each tool's own signature
(replayable as-is).
Tool defaults are unsafe or overly permissive (e.g. disabled TLS verification, no authentication, world-writable permissions). Unsafe defaults widen the attack surface.
proxy-aiops init # interactive wizard: platform, base_url, TLS verify, encrypted secret
proxy-aiops doctor # config + secrets + connectivity (probe per platform)
proxy-aiops doctor --skip-auth # skip the connectivity probe
proxy-aiops overview # one-shot: version + routes/services + upstream health
The guide explicitly tells users to place the master password in the MCP client config env block, which can expose a highly sensitive secret in plaintext on disk, in backups, in config sync systems, or through local process/config inspection depending on the client. In this skill's context, that password unlocks stored proxy credentials and enables governed write operations against reverse proxies, so compromise could cascade into administrative access to load balancer and routing infrastructure.
No suspicious patterns detected.