Agent Life

• Outcome: Review
• Latest audit: Sep 12, 2026 · 1:37 AM UTC
• Version: 1.8.0

Overview

The skill is a coherent cloud backup tool, but it asks users to run a mutable remote installer and syncs an encrypted credential vault by default when present.

Review carefully before installing. Prefer direct binary download from a pinned release or an installer pinned to an immutable commit, do not use ALF_ALLOW_UNVERIFIED, run alf export --dry-run before syncing, and check whether you are comfortable uploading the encrypted ~/.alf/vault/credentials.json vault to agent-life.ai.

A.I.G

Vulnerability Patterns

• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review
• 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
• Embedded Malicious Code: Ships malicious scripts inside the skill and executes them locally

Findings (2)

T03 · Remote Payload Retrieval and Execution

Error

• Location: SKILL.md:47

Finding

Mutable Remote Installer Is Downloaded and Executed

Content

View full analysis

Vulnerability Details

File Location: SKILL.md, lines 47-49
Vulnerability Type: Remote payload retrieval and execution
Risk Level: High

Vulnerable Code

sh

curl -sSL https://raw.githubusercontent.com/agent-life/agent-life-adapters/main/scripts/install.sh -o install-alf.sh
cat install-alf.sh    # inspect the script
sh install-alf.sh     # run it

Technical Analysis

The Skill instructs users to retrieve an installer from the mutable main branch of an external GitHub repository and execute it with sh. The effective installer payload can therefore change after this Skill has been reviewed or published.

Displaying the script with cat does not provide cryptographic authentication and does not ensure that a user or agent will identify malicious changes. Although ALF_VERSION can reportedly pin the binary release selected by the installer, it does not pin or authenticate the installer itself.

Neither the installer nor the executable implementation is included in the audited project. Consequently, the audit cannot independently verify the installer's filesystem operations, downloaded artifact selection, checksum implementation, or the CLI's stated data-handling guarantees.

Attack Path

1. An attacker compromises the upstream repository, maintainer account, release process, or another component capable of changing content served from the referenced main branch.
2. The attacker modifies scripts/install.sh to execute additional commands or install a substituted executable.
3. A user or agent follows the Skill instructions and downloads the current mutable script.
4. The user executes it using sh install-alf.sh.
5. The modified installer executes with the invoking user's permissions and can access data or modify files available to that user.

Impact Assessment

Successful exploitation provides arbitrary command execution with the privileges of the account running the installer. ...[truncated 529 chars]

Remediation

View remediation

Remediation Suggestions

• Do not retrieve an executable installer from a mutable branch.
• Vendor the reviewed installer in the Skill package, or fetch it using an immutable commit identifier.
• Publish an installer digest through a separately trusted channel and verify it before execution.
• Require cryptographic signatures for release binaries rather than relying solely on checksums hosted alongside those binaries.
• Pin a specific release by default instead of using latest or a mutable branch.
• Avoid privileged or system-wide installation by default; install into a dedicated user-controlled directory with minimal permissions.
• Include the installer and relevant CLI source in the review scope so their filesystem, network, encryption, and credential-handling behavior can be audited.

T09 · Insecure Skill Coding Practices

Warning

• Location: SKILL.md:62

Finding

Executable Integrity Verification Can Be Disabled

Content

View full analysis

Vulnerability Details

File Location: SKILL.md, lines 62-69
Vulnerability Type: Insecure integrity-verification fallback
Risk Level: Medium

Vulnerable Code

text

The install script detects your platform, downloads the binary from GitHub Releases, **requires a successful SHA256 checksum verification**, and installs to `/usr/local/bin/alf` (or `~/.local/bin/alf` without root).

**Checksum verification is mandatory by default.** A hash mismatch always aborts the install (exit 4) and cannot be overridden. If verification cannot be performed at all — the `.sha256` file is missing or empty, or no `sha256sum`/`shasum` tool is available — the script also exits 4 by default; set `ALF_ALLOW_UNVERIFIED=1` to opt out of *that* case only (not recommended), in which case `checksum_verified` is `false` and a `warnings` array in the output JSON records the reason.

The bypass is also declared in the Skill metadata:

yaml

- name: ALF_ALLOW_UNVERIFIED
  required: false
  description: Set to 1 to allow install.sh to proceed when the SHA256 checksum cannot be verified. Default is to fail.

Technical Analysis

The default fail-closed behavior is appropriate, and a detected checksum mismatch reportedly cannot be overridden. However, the documented ALF_ALLOW_UNVERIFIED=1 option permits installation when the checksum file is unavailable, empty, or cannot be processed.

In those cases, the installer has no verified integrity value for the executable. A warning in JSON output records the condition but does not prevent execution of an unauthenticated artifact. Moreover, a checksum distributed from the same release infrastructure as the binary does not independently protect against compromise of that infrastructure.

Attack Path

1. An attacker substitutes or corrupts the binary available through the release-download channel.
2. Checksum availability or local verification is disrupted, such as through a mi ...[truncated 1172 chars]

Remediation

View remediation

Remediation Suggestions

• Remove ALF_ALLOW_UNVERIFIED and fail closed whenever integrity verification cannot complete.
• Require a supported verification utility before installation.
• Authenticate releases with a cryptographic signature or provenance mechanism whose trust root is separate from the artifact-hosting channel.
• Pin the expected release version and trusted signing identity.
• Do not suggest unverified installation as a troubleshooting fallback.
• If emergency installation is operationally unavoidable, require an explicit interactive confirmation, display the exact artifact URL and digest status, prohibit automated use, and isolate execution in a restricted environment.

SkillSpector

Vulnerability Patterns

• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep
• Tool Misuse: Tool Parameter Abuse, Chaining Abuse, Unsafe Defaults
• Rogue Agent: Self-Modification, Session Persistence
• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger

Findings (8)

Credential Access

High

• Category: Privilege Escalation
• Confidence: 94% confidence

Finding

The skill states that ~/.alf/vault/credentials.json is included outside the workspace and cannot be excluded via .alfignore. Even if secrets are encrypted client-side, automatically packaging credential material for cloud sync increases the sensitivity of the operation and creates a meaningful exfiltration path for authentication-related data and metadata.

Content

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

md

- Lines starting with `#` are comments; blank lines are ignored.
- Negation (`!pattern`) re-includes a previously-excluded path.
- `.alfignore` itself is never uploaded.
- The agent's vault file at `~/.alf/vault/credentials.json` is outside the workspace and is **not** affected by `.alfignore`. Use `alf vault` to control vault contents.

Inspect the effect with `alf export --dry-run` — the `excluded_by_alfignore` count and the `files[]` list reflect the filtered set.

Credential Access

High

• Category: Privilege Escalation
• Confidence: 95% confidence

Finding

This section confirms that the agent's encrypted credential vault is uploaded to the cloud when present. In the context of an agent skill whose purpose is remote backup/sync, automatic transfer of credential stores is especially dangerous because users may not realize authentication artifacts are part of the payload, and future cryptographic or key-management failures would increase blast radius.

Content

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

md

Plus the workspace's `memory/` directory, recursively. Symlinks inside `memory/` are not followed, so files outside the workspace cannot be pulled in through a link.

Plus the agent's ALF vault at `~/.alf/vault/credentials.json` (when present). Vault records are encrypted client-side; only ciphertext leaves the machine.

A `.alfignore` file at the workspace root, if present, removes paths from this set. Run `alf export --dry-run` to confirm the final list.

Credential Access

High

• Category: Privilege Escalation
• Confidence: 90% confidence

Finding

The file documents that export reads ~/.alf/vault/credentials.json, meaning the skill is designed to access locally stored credential material during normal operation. Access to credential repositories is inherently high risk, and in this skill context it directly supports transmission to a remote service, making the behavior more dangerous than a passive local-only read.

Content

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

md

- `~/.alf/config.toml` — the CLI's own config (API key, API URL, defaults).
- `~/.alf/state/{agent_id}.toml` — local sync cursor. Read on every sync, never uploaded.
- `~/.alf/state/{agent_id}-snapshot.alf` — last snapshot, used to compute deltas. Read on every sync, never uploaded.
- `~/.alf/vault/credentials.json` — the encrypted credential vault. Read during export; only ciphertext leaves the machine (see *Credential encryption* above).
- `~/.openclaw/openclaw.json` — read to auto-discover the workspace path for OpenClaw runtimes.

**Inside the workspace**:

Tool Parameter Abuse

High

• Category: Tool Misuse
• Confidence: 80% 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 · SKILL.md (reported line 340)May include surrounding context.

md

### Retention and deletion

Data is retained until **you** delete it. There is no automatic expiry. Delete individual agents via the web dashboard at agent-life.ai or via `DELETE /v1/agents/:id`. Account deletion removes all data associated with the account. Local data (the `.alf` archive, `~/.alf/state/`, and the vault key) is your responsibility — back up the vault key and any local archives the same way you would back up SSH keys.

### API key scope

Credential Access

High

• Category: Privilege Escalation
• Confidence: 88% confidence

Finding

Listing ~/.alf/vault/credentials.json as a standard file location reinforces that the skill operationally depends on handling encrypted credential vault data. While the content may be ciphertext, backup and retention of credential containers still materially increases exposure, especially if cloud account compromise or offline cryptanalysis becomes possible.

Content

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

md

| `~/.alf/config.toml` | API key, API URL, default runtime and workspace |
| `~/.alf/state/{agent_id}.toml` | Sync cursor (last sequence, timestamp) |
| `~/.alf/state/{agent_id}-snapshot.alf` | Last snapshot for delta computation |
| `~/.alf/vault/credentials.json` | Encrypted credential vault (ciphertext only; key stays offline) |
| `<workspace>/.alfignore` | Optional gitignore-style patterns to exclude workspace paths from export |

Autonomous Decision Making

Medium

• Category: Excessive Agency
• Confidence: 76% confidence

Finding

The skill explicitly documents an opt-out path, ALF_ALLOW_UNVERIFIED=1, that permits installation when checksum verification cannot be completed. Even though hash mismatches still abort, allowing installation without successful verification weakens supply-chain protections and could lead an agent or user to install an unverified binary in degraded environments.

Content

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

md

### Install integrity

The `alf` binary is downloaded from GitHub Releases and SHA256-verified during install. A hash mismatch always aborts the install (exit 4) and is never bypassable. If verification cannot complete — missing `.sha256` file, empty checksum, or no `sha256sum`/`shasum` available — the script also exits 4 by default; the user must explicitly opt out with `ALF_ALLOW_UNVERIFIED=1` to install without verification, in which case the JSON output reports `"checksum_verified":false` and a `warnings` array. Inspect the install script before running it (see *Install* above).

### Review before uploading

Session Persistence

Medium

• Category: Rogue Agent
• Confidence: 60% confidence

Finding

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.

Content

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

md

You can inspect exactly what will be uploaded before any data leaves your machine:

    alf export -r openclaw -w <workspace> --dry-run   # list files without writing
    alf export -r openclaw -w <workspace>             # write local .alf archive
    alf validate agent-export.alf                     # check the archive structure

Nothing is uploaded until you explicitly run `alf sync`.

Vague Triggers

Low

• Category: Not specified by scanner
• Confidence: 77% confidence

Finding

The description says to use the skill when asked to back up agent data, sync memory to the cloud, restore from cloud, or migrate agent state, but it does not define tighter boundaries or exclusions. In a manifest/markdown context, this can create ambiguity about when ordinary requests about backups or migration should invoke this specific cloud-sync skill versus another local-only backup tool.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.