Keldron — GPU & Hardware Monitor Agent

• Outcome: Review
• Latest audit: Sep 15, 2026 · 1:35 AM UTC
• Version: 1.0.2

Overview

This GPU monitoring skill is purpose-aligned, but its setup can run mutable remote binaries or containers, expose monitoring services broadly, and persist credentials or processes without enough safeguards.

Review before installing. Prefer pinned releases or verified checksums, bind Docker ports to 127.0.0.1, avoid the Docker restart policy unless you want a persistent service, use the CLI login or an environment variable instead of plaintext YAML when possible, and confirm any custom cloud endpoint before sending an API key.

A.I.G

Vulnerability Patterns

• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review
• System Persistence: Installs backdoors, hooks, services, or scheduled tasks that survive the run
• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions

Findings (5)

T03 · Remote Payload Retrieval and Execution

Error

• Location: SKILL.md:91
• Finding: Unverified Remote Binaries Are Downloaded and Executed<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:91-106`, `SKILL.md:165-194` **Vulnerability Type**: Remote payload retrieval and execution without integrity verification **Risk Level**: High ### Complete Code Snippet ```bash ### Mac (Apple Silicon) curl -sfL https://github.com/keldron-ai/keldron-agent/releases/latest/download/keldron-agent-darwin-arm64 -o keldron-agent chmod +x keldron-agent ``` ```bash ### Linux (AMD64) curl -sfL https://github.com/keldron-ai/keldron-agent/releases/latest/download/keldron-agent-linux-amd64 -o keldron-agent chmod +x keldron-agent ``` ```bash ### Linux (ARM64) curl -sfL https://github.com/keldron-ai/keldron-agent/releases/latest/download/keldron-agent-linux-arm64 -o keldron-agent chmod +x keldron-agent ``` The automatic setup flow subsequently executes the downloaded file: ```bash if [ "$OS" = "Darwin" ]; then curl -sfL "https://github.com/keldron-ai/keldron-agent/releases/latest/download/${BINARY}" -o keldron-agent chmod +x keldron-agent ./keldron-agent --local & sleep 3 fi if [ "$OS" = "Linux" ]; then if command -v docker &>/dev/null; then docker rm -f keldron-agent 2>/dev/null || true if ! docker run -d --name keldron-agent --restart unless-stopped \ -p 9100:9100 -p 9200:9200 -p 8081:8081 \ -e KELDRON_OUTPUT_PROMETHEUS_HOST=0.0.0.0 \ -e KELDRON_API_HOST=0.0.0.0 \ -e KELDRON_HEALTH_BIND=0.0.0.0:8081 \ ghcr.io/keldron-ai/keldron-agent:latest; then echo "Error: Failed to start keldron-agent container. Check Docker permissions and network." exit 1 fi else curl -sfL "https://github.com/keldron-ai/keldron-agent/releases/latest/download/${BINARY}" -o keldron-agent chmod +x keldron-agent ./keldron-agent --local & fi sleep 3 fi ``` ### Technical Analysis The Skill downloads executable content from a mutable `releases/latest` URL, marks it executable, and runs it without checking a cryptographic digest or signature. Although Git ...[truncated 1861 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Pin downloads to an explicit, reviewed release version rather than `releases/latest`. 2. Publish SHA-256 checksums through an independently protected release manifest and verify the selected artifact before `chmod` or execution. 3. Prefer signed releases and verify signatures with a pinned, documented publisher key. 4. Pin the container image by immutable digest, for example: ```bash docker run ghcr.io/keldron-ai/keldron-agent@sha256:<reviewed-digest> ``` 5. Abort installation if verification fails; never downgrade silently to unverified execution. 6. Display the selected version, source URL, checksum, and requested runtime behavior before obtaining user consent. 7. Run the native process with a dedicated low-privilege account and constrain it with applicable sandboxing controls. ]]>

T06 · System Persistence

Warning

• Location: SKILL.md:112
• Finding: Docker Restart Policy Creates Cross-Session Persistence<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:112-118`, `SKILL.md:181-187` **Vulnerability Type**: Persistent service execution through Docker restart policy **Risk Level**: Medium ### Complete Code Snippet ```bash docker rm -f keldron-agent 2>/dev/null || true docker run -d --name keldron-agent --restart unless-stopped \ -p 9100:9100 -p 9200:9200 -p 8081:8081 \ -e KELDRON_OUTPUT_PROMETHEUS_HOST=0.0.0.0 \ -e KELDRON_API_HOST=0.0.0.0 \ -e KELDRON_HEALTH_BIND=0.0.0.0:8081 \ ghcr.io/keldron-ai/keldron-agent:latest ``` The same behavior is included in the automatic installation path: ```bash docker rm -f keldron-agent 2>/dev/null || true if ! docker run -d --name keldron-agent --restart unless-stopped \ -p 9100:9100 -p 9200:9200 -p 8081:8081 \ -e KELDRON_OUTPUT_PROMETHEUS_HOST=0.0.0.0 \ -e KELDRON_API_HOST=0.0.0.0 \ -e KELDRON_HEALTH_BIND=0.0.0.0:8081 \ ghcr.io/keldron-ai/keldron-agent:latest; then echo "Error: Failed to start keldron-agent container. Check Docker permissions and network." exit 1 fi ``` ### Technical Analysis The `--restart unless-stopped` policy causes Docker to restart the agent after Docker daemon restarts and host reboots. The process therefore survives the Skill interaction and user logout. Long-running monitoring can legitimately require persistence, but the automatic setup uses it by default rather than treating it as an explicit deployment choice. This exceeds the minimum privilege and lifetime required for an ad hoc monitoring query. The risk is amplified because the image is referenced using the mutable `latest` tag. ### Attack Path 1. A user asks the Skill to install or configure GPU monitoring. 2. The automatic Linux path detects Docker and launches the container with `--restart unless-stopped`. 3. The initiating interaction ends, but Docker retains the restart configuration. 4. On a later Docker daemon restart or host reboot, the agent starts again without a new Skill invocation. 5. If ...[truncated 629 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Omit `--restart unless-stopped` from the default and automatic setup commands. 2. Run the initial container with `--rm` or `--restart no` for temporary monitoring. 3. Offer persistent monitoring as a separate, clearly explained option requiring explicit user consent. 4. Pin persistent deployments to a verified image digest. 5. Document how to disable and remove persistence: ```bash docker update --restart=no keldron-agent docker stop keldron-agent docker rm keldron-agent ``` 6. Report the resulting restart policy after installation so users can verify the deployment state. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: SKILL.md:45
• Finding: Cloud API Key Can Be Sent to a Configuration-Controlled Endpoint<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:45-63`, with authenticated sinks at `SKILL.md:490-491`, `517-518`, `546-547`, `568-569`, and `603-604` **Vulnerability Type**: Credential disclosure through insufficient destination validation **Risk Level**: High ### Complete Code Snippet The mode-detection logic reads both the API key and endpoint from user-writable credential or YAML files: ```bash # Check 2: Is cloud configured? (env → ~/.keldron/credentials from login → YAML) CLOUD_KEY="${KELDRON_CLOUD_API_KEY:-}" CLOUD_ENDPOINT="" if [ -z "$CLOUD_KEY" ] && [ -f ~/.keldron/credentials ] && command -v jq &>/dev/null; then CLOUD_KEY=$(jq -r '.api_key // ""' ~/.keldron/credentials 2>/dev/null) CLOUD_ENDPOINT=$(jq -r '.endpoint // ""' ~/.keldron/credentials 2>/dev/null) fi if [ -z "$CLOUD_KEY" ]; then if command -v yq &>/dev/null; then CLOUD_KEY=$(yq '.cloud.api_key // ""' ~/.config/keldron/keldron-agent.yaml 2>/dev/null) CLOUD_ENDPOINT=$(yq '.cloud.endpoint // ""' ~/.config/keldron/keldron-agent.yaml 2>/dev/null) else CLOUD_KEY=$(grep -A3 'cloud:' ~/.config/keldron/keldron-agent.yaml 2>/dev/null \ | grep 'api_key:' | awk '{print $2}' | tr -d "\"'" | xargs 2>/dev/null) CLOUD_ENDPOINT=$(grep -A3 'cloud:' ~/.config/keldron/keldron-agent.yaml 2>/dev/null \ | grep 'endpoint:' | awk '{print $2}' | tr -d "\"'" | xargs 2>/dev/null) fi fi CLOUD_ENDPOINT="${CLOUD_ENDPOINT:-https://api.keldron.ai}" ``` The resulting endpoint receives the API key in an HTTP header: ```bash FLEET=$(curl -s "${CLOUD_ENDPOINT}/v1/fleet/overview" \ -H "X-API-Key: $CLOUD_KEY") ``` The same pattern is used for history, analytics, health, and fleet-polling requests. ### Technical Analysis Reading `~/.keldron/credentials` is directly related to authenticated fleet monitoring and is not, by itself, unrelated credential reconnaissance. The vulnerability arises because the endpoint read from local configuration is trusted without validatin ...[truncated 1826 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Use `https://api.keldron.ai` as a fixed destination unless custom endpoints are an explicit, necessary product requirement. 2. Before attaching the key, parse and validate the URL: - Require the `https` scheme. - Require an exact allowlisted hostname. - Reject embedded user information, unexpected ports, fragments, and malformed URLs. 3. If custom endpoints are supported, present the resolved origin and require explicit user approval before transmitting credentials. 4. Use separate credentials scoped to each custom endpoint; never reuse a production-cloud key across arbitrary origins. 5. Reject configuration files that are not owned by the current user or that are writable by group or other users. 6. Use strict request options such as `curl --fail --show-error --silent` and avoid forwarding credentials across redirects. 7. Prefer invoking a trusted client that internally binds credentials to an expected service origin instead of manually constructing authenticated requests in shell. ]]>

T09 · Insecure Skill Coding Practices

Warning

• Location: SKILL.md:238
• Finding: Plaintext API Key Is Written Without Enforced Restrictive Permissions<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:238-270` **Vulnerability Type**: Insecure storage of sensitive configuration **Risk Level**: Medium ### Complete Code Snippet ```bash # Store the user-provided key in a variable (do not inline the raw key) export CLOUD_KEY="<paste key here or pass programmatically>" mkdir -p ~/.config/keldron # Add or update cloud config in agent YAML if [ -f ~/.config/keldron/keldron-agent.yaml ]; then if ! grep -q 'cloud:' ~/.config/keldron/keldron-agent.yaml; then cat >> ~/.config/keldron/keldron-agent.yaml << EOF cloud: enabled: true api_key: $CLOUD_KEY EOF else # cloud: section exists — update or insert api_key under the cloud: block awk -v key="$CLOUD_KEY" ' /^cloud:/ { in_cloud=1; found=0; print; next } in_cloud && /^[^ ]/ { if (!found) { print " api_key: " key; found=1 } in_cloud=0 } in_cloud && /^[[:space:]]+api_key:/ { $0=" api_key: " key; found=1 } { print } END { if (in_cloud && !found) print " api_key: " key } ' ~/.config/keldron/keldron-agent.yaml > ~/.config/keldron/keldron-agent.yaml.tmp \ && mv ~/.config/keldron/keldron-agent.yaml.tmp ~/.config/keldron/keldron-agent.yaml fi else cat > ~/.config/keldron/keldron-agent.yaml << EOF cloud: enabled: true api_key: $CLOUD_KEY EOF fi ``` ### Technical Analysis The Skill stores the cloud API key as plaintext in `~/.config/keldron/keldron-agent.yaml`. Unlike the `README.md` claim that the CLI-created `~/.keldron/credentials` file uses mode `0600`, this alternative setup does not establish a restrictive `umask`, set directory permissions, or apply `chmod 600`. The effective permissions therefore depend on the user's environment and existing file state. The temporary file produced by `awk` is also created without explicit permission hardening and then moved over the final configuration. Exporting `CLOUD_KEY` additionally places the key in the environment inherit ...[truncated 1102 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Prefer the documented `keldron-agent login` flow if it reliably creates a credential file with mode `0600`. 2. Before creating secret-bearing files, set a restrictive umask: ```bash umask 077 ``` 3. Create the directory and enforce ownership-only access: ```bash mkdir -p ~/.config/keldron chmod 700 ~/.config/keldron ``` 4. Create temporary files securely in the destination directory with `mktemp`, apply mode `0600`, and replace the target atomically. 5. After every create or update operation, run: ```bash chmod 600 ~/.config/keldron/keldron-agent.yaml ``` 6. Verify that the file is owned by the current user and is not a symbolic link before writing. 7. Avoid globally exporting the key. Scope it to only the command that requires it, unset it promptly afterward, and avoid exposing it in command history or transcripts. 8. Where available, use an operating-system credential store rather than plaintext YAML. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: SKILL.md:112
• Finding: Docker Setup Exposes Monitoring Services on All Host Interfaces<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:112-118`, `SKILL.md:181-187` **Vulnerability Type**: Unauthenticated network service exposure **Risk Level**: High ### Complete Code Snippet ```bash docker rm -f keldron-agent 2>/dev/null || true docker run -d --name keldron-agent --restart unless-stopped \ -p 9100:9100 -p 9200:9200 -p 8081:8081 \ -e KELDRON_OUTPUT_PROMETHEUS_HOST=0.0.0.0 \ -e KELDRON_API_HOST=0.0.0.0 \ -e KELDRON_HEALTH_BIND=0.0.0.0:8081 \ ghcr.io/keldron-ai/keldron-agent:latest ``` The automatic setup repeats the same exposure: ```bash if ! docker run -d --name keldron-agent --restart unless-stopped \ -p 9100:9100 -p 9200:9200 -p 8081:8081 \ -e KELDRON_OUTPUT_PROMETHEUS_HOST=0.0.0.0 \ -e KELDRON_API_HOST=0.0.0.0 \ -e KELDRON_HEALTH_BIND=0.0.0.0:8081 \ ghcr.io/keldron-ai/keldron-agent:latest; then ``` ### Technical Analysis Docker's `-p 9100:9100`, `-p 9200:9200`, and `-p 8081:8081` syntax publishes the container ports on all host interfaces unless an explicit host address is supplied. The environment variables also direct the services to listen on `0.0.0.0` inside the container. This behavior conflicts with the security posture described in `README.md:235-237`, which states that local HTTP servers bind to `127.0.0.1` by default and are not exposed publicly unless explicitly reconfigured. The recommended Docker command explicitly reconfigures and publishes the services without a separate warning or consent step. The reviewed documentation does not describe authentication for the Prometheus metrics, local dashboard, health endpoint, or status API. Therefore, network exposure may allow unauthenticated access to telemetry and identifying metadata. ### Attack Path 1. A user runs the recommended Docker installation on a workstation or server reachable from a LAN, cloud network, or public interface. 2. Docker publishes ports 9100, 9200, and 8081 on every host address. 3. A remote attacker scans the host and ...[truncated 997 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Bind published ports to loopback by default: ```bash docker run -d --name keldron-agent \ -p 127.0.0.1:9100:9100 \ -p 127.0.0.1:9200:9200 \ -p 127.0.0.1:8081:8081 \ ... ``` 2. Preserve localhost binding inside the container when technically possible rather than setting every listener to `0.0.0.0`. 3. Require explicit user confirmation before enabling LAN or public-interface access. 4. Add authentication and authorization to any dashboard or API exposed beyond loopback. 5. Protect remote access with TLS and a reverse proxy rather than directly publishing unauthenticated application ports. 6. Document firewall requirements and limit access to specific trusted source networks. 7. After installation, display the effective bound addresses and verify them with an appropriate socket-inspection command. 8. Align the Docker instructions with the localhost-default security claims in `README.md`. ]]>

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep
• Rogue Agent: Self-Modification, Session Persistence
• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger

Findings (13)

Rp1

Medium

• Category: MCP Rug Pull
• Confidence: 75% confidence
• Finding: Docker image references without a specific tag (:latest is implicit) or digest (@sha256:...) can be silently replaced by a malicious image.

Rp1

Medium

• Category: MCP Rug Pull
• Confidence: 75% confidence
• Finding: Docker image references without a specific tag (:latest is implicit) or digest (@sha256:...) can be silently replaced by a malicious image.

Unrestricted Tool Access

Medium

• Category: Excessive Agency

Content

## Security

The agent is **read-only** — it reads hardware sensors and computes scores. It does not execute arbitrary commands or alter system state beyond writing its own credential file (`~/.keldron/credentials`, created with 0600 permissions). Local HTTP servers (web UI on port 9200, Prometheus metrics on port 9100, health endpoint on port 8081) bind to `127.0.0.1` by default and are not exposed on public interfaces unless explicitly reconfigured.

- All HTTP servers bind to `127.0.0.1` (localhost) by default. Override via config for LAN access.
- Cloud telemetry is transmitted over HTTPS with TLS 1.2+.

• Confidence: 80% confidence
• Finding: Skill grants unrestricted tool access without appropriate constraints. An agent with unfettered tool access can perform arbitrary actions including file modification, network requests, and code execution.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

**Dual mode:** Use the **local agent** on `localhost:9100` for fast, real-time, single-device queries (works offline). Use **Keldron Cloud** (`https://api.keldron.ai`) for fleet overview, historical telemetry, analytics, and proactive fleet monitoring when an API key is configured.

**No sudo required on any platform** for the agent binary. On Linux, Docker may require `sudo` or membership in the `docker` group — see [Docker post-install](https://docs.docker.com/engine/install/linux-postinstall/) or rootless Docker if you hit permission errors.

Use this skill when the user wants to:

• Confidence: 70% confidence
• Finding: Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

**Dual mode:** Use the **local agent** on `localhost:9100` for fast, real-time, single-device queries (works offline). Use **Keldron Cloud** (`https://api.keldron.ai`) for fleet overview, historical telemetry, analytics, and proactive fleet monitoring when an API key is configured.

**No sudo required on any platform** for the agent binary. On Linux, Docker may require `sudo` or membership in the `docker` group — see [Docker post-install](https://docs.docker.com/engine/install/linux-postinstall/) or rootless Docker if you hit permission errors.

Use this skill when the user wants to:

• Confidence: 70% confidence
• Finding: Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.

Rp1

Medium

• Category: MCP Rug Pull
• Confidence: 75% confidence
• Finding: Docker image references without a specific tag (:latest is implicit) or digest (@sha256:...) can be silently replaced by a malicious image.

Rp1

Medium

• Category: MCP Rug Pull
• Confidence: 75% confidence
• Finding: Docker image references without a specific tag (:latest is implicit) or digest (@sha256:...) can be silently replaced by a malicious image.

Vague Triggers

Medium

• Confidence: 95% confidence
• Finding: The trigger phrases for auto-setup are broad enough that a normal request like 'monitor my hardware' or 'help me set up' could cause the agent to start downloading binaries, launching containers, or modifying the local environment without sufficiently explicit user confirmation. In an agentic context, overly permissive activation can turn benign user intent into unreviewed system-changing actions.

Missing User Warnings

Medium

• Confidence: 92% confidence
• Finding: The skill provides step-by-step instructions to write an API key into a local YAML file but does not prominently warn that this stores credentials on disk in plaintext. That increases the chance of accidental exposure through backups, shared accounts, file sync, shell history-adjacent workflows, or later host compromise.

Session Persistence

Medium

• Category: Rogue Agent

Content

# Store the user-provided key in a variable (do not inline the raw key)
export CLOUD_KEY="<paste key here or pass programmatically>"

mkdir -p ~/.config/keldron

# Add or update cloud config in agent YAML
if [ -f ~/.config/keldron/keldron-agent.yaml ]; then

• Confidence: 90% confidence
• Finding: Persisting the cloud API key under `~/.config/keldron/keldron-agent.yaml` creates session/credential persistence beyond the current interaction. Long-lived plaintext persistence increases the blast radius of local compromise and can silently keep cloud access active after the user expected a local-only session.

Intent-Code Divergence

Medium

• Confidence: 92% confidence
• Finding: The skill instructs users to persist a cloud API key into `~/.config/keldron/keldron-agent.yaml`, which creates a local plaintext secret at rest. If the host is multi-user, backed up insecurely, or later compromised, the stored key can be recovered and used to access cloud telemetry and fleet data.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

- **API key security.** Never echo the full API key. Show only the first 8 characters: *Configured with key kldn_liv…*
- **Fallback gracefully.** Cloud unreachable → fall back to local. Local unreachable → guide setup. Never show raw errors to the user.
- **On Apple Silicon, high swap = model too large.** If swap is high, suggest a smaller or quantized model.
- **The agent never requires sudo.** Runs unprivileged on all platforms. Docker on Linux may need sudo or docker-group.
- **Use metric labels.** Extract `device_model` and `device_name` from Prometheus labels for personalized responses.
- **When the user says "alert me" or "watch" (fleet),** set up the cloud polling loop and execute it.
- **When the user says "dashboard",** link to the real dashboard. Do not render ASCII art.

• Confidence: 50% confidence
• Finding: Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.

Intent-Code Divergence

Low

• Confidence: 89% confidence
• Finding: L732 makes an absolute statement that the agent never requires sudo, but the installation and overview sections acknowledge Docker on Linux may require `sudo` or docker-group membership. Since the documented setup path includes Docker-based execution, the absolute claim contradicts the actual operational instructions.

Static analysis

Detected: suspicious.exposed_secret_literal

File appears to expose a hardcoded API secret or token.

Critical

• Code: suspicious.exposed_secret_literal
• Location: SKILL.md:722