Firm Acp Bridge

• Outcome: Review
• Latest audit: Sep 11, 2026 · 2:12 AM UTC
• Version: 1.0.0

Overview

This skill needs Review because it tells agents to share API keys with autonomous sessions and schedule recurring host-level commands to work around sandbox limits without enough guardrails.

Install only if you trust the external fleet tools and will use this in a controlled environment. Treat injected provider keys as exposed to every recipient session, use short-lived scoped credentials, avoid PROXY_URL or CUSTOM_* unless reviewed, and do not schedule host-side cron commands without explicit human approval, fixed allowlisted jobs, logging, expiration, and a removal path.

A.I.G

Vulnerability Patterns

• Unauthorized Access and Privilege Escalation: Obtains permissions beyond the task's legitimate needs
• 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
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review
• Embedded Malicious Code: Ships malicious scripts inside the skill and executes them locally

Findings (2)

T05 · Unauthorized Access and Privilege Escalation

Error

• Location: SKILL.md:164
• Finding: Explicit Sandbox Bypass Through Host-Accessible Scheduled Command Execution<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:164-187` **Vulnerability Type**: Sandbox boundary bypass and persistent host command execution **Risk Level**: Critical ### Vulnerable Code ```markdown ## Cron Outside Sandbox (H4) **Problème :** `cron` tools sont sur la denylist dans les sessions Docker sandbox. Tout workflow autonome planifié dans un container non-main est bloqué. **Solution :** Planifier sur la session `main` (accès hôte) via `fleet_cron_schedule`. ```json { "tool": "fleet_cron_schedule", "args": { "command": "node scripts/daily-report.js", "schedule": "0 9 * * 1-5", "session": "main", "description": "Daily business report — Monday to Friday 9h" } } ``` **Utiliser `fleet_cron_schedule` quand :** - ✅ La tâche est un script léger et déterministe - ✅ La tâche ne nécessite pas d'isolation sécurité - ✅ La command passe l'allowlist `[a-zA-Z0-9 /._-=]+` ``` ### Technical Analysis The Skill explicitly instructs the agent to work around a security denylist that prevents sandboxed sessions from using cron. Rather than preserving the sandbox boundary, it moves execution to the `main` session, which the document identifies as having host access. The proposed command validation is only a character allowlist. It does not constrain which executable may run, canonicalize script paths, verify file ownership or integrity, prevent path traversal, or ensure that the referenced script remains trusted after the schedule is created. An apparently benign command such as `node scripts/daily-report.js` can therefore execute arbitrary JavaScript if that file is attacker-controlled or later modified. Cron scheduling also creates execution that survives the initiating Skill invocation. Consequently, this mechanism combines privilege escalation from a containerized session to a host-accessible session with persistent scheduled execution. The repository contains only `SKILL.md`; no implementation of `fleet_cron_schedule` is a ...[truncated 1535 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Do not route denied sandbox operations through a more privileged session. Preserve the sandbox denylist as an intentional security boundary. 2. Run scheduled jobs in dedicated, least-privileged containers or service accounts rather than the host-accessible `main` session. 3. Replace free-form command input with identifiers for preapproved jobs. Map each identifier to a fixed executable and fixed argument schema. 4. Canonicalize every executable and script path, reject relative paths and traversal, and verify ownership, permissions, and cryptographic hashes before registration and execution. 5. Do not rely on a character allowlist as a command authorization mechanism. 6. Require explicit, authenticated human approval before creating or modifying a host-level recurring task. 7. Record the requesting identity, approved command, schedule, execution history, and job identifier in tamper-resistant audit logs. 8. Provide authenticated list, disable, expiration, and removal operations. Scheduled tasks should expire by default. 9. Prevent untrusted sessions from modifying files referenced by scheduled jobs. 10. If host scheduling is unavoidable, use a narrowly scoped worker with filesystem, network, process, and secret-access restrictions. ]]>

T05 · Unauthorized Access and Privilege Escalation

Error

• Location: SKILL.md:105
• Finding: Broad API Credential and Proxy Configuration Injection into Autonomous Sessions<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:105-162` **Vulnerability Type**: Unsafe secret propagation and insufficient session authorization **Risk Level**: High ### Vulnerable Code ```markdown ## Autonomous Session Bootstrap (H3) **Problème :** Les sessions spawned via `sessions_spawn` ou cron n'ont pas accès aux env vars des providers configurés (ANTHROPIC_API_KEY, OPENAI_API_KEY, etc.). Tout appel LLM dans une session non-main échoue silencieusement. ### Séquence obligatoire avant sessions_spawn **Étape 1 — Validation dry_run (vérifier les clés sans envoyer) :** ```json { "tool": "fleet_session_inject_env", "args": { "env_vars": { "ANTHROPIC_API_KEY": "<your_key>", "OPENCLAW_MODEL": "claude-3-5-sonnet-20241022" }, "dry_run": true } } ``` → Vérifie que les clés passent l'allowlist. Si `rejected` non vide, les clés sont invalides. **Étape 2 — Injection effective avant spawn :** ```json { "tool": "fleet_session_inject_env", "args": { "env_vars": { "ANTHROPIC_API_KEY": "<your_key>", "OPENCLAW_MODEL": "claude-3-5-sonnet-20241022" }, "filter_tags": ["engineering", "quality"] } } ``` **Étape 3 — Spawn la session (via Gateway direct) :** ```json { "method": "sessions_spawn", "params": { "agent": "engineering", "reply_session": "main" } } ``` ### Clés autorisées (allowlist intégrée) ``` ANTHROPIC_API_KEY | OPENAI_API_KEY | OPENROUTER_API_KEY | GEMINI_API_KEY OPENCLAW_MODEL | OPENCLAW_PROVIDER | OPENCLAW_MAX_TOKENS CLAW_MODEL | CLAW_PROVIDER | PROXY_URL | CUSTOM_* ``` Jamais dans les logs — les valeurs sont masquées avec `****{last4}`. ``` ### Technical Analysis The Skill makes credential injection into non-main autonomous sessions a mandatory bootstrap step. The documented examples distribute long-lived provider API keys according to session tags, but the document does not show that tags are authenticated identities or authorization boundaries. Any process ...[truncated 2698 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Do not copy long-lived provider API keys into autonomous session environments. 2. Use a secret broker to issue short-lived, single-session credentials with the minimum required provider scopes, quotas, and expiration. 3. Authenticate the exact recipient session identity. Do not treat mutable tags as authorization. 4. Require explicit user approval for every secret grant and clearly display the recipient, scope, lifetime, and intended provider operation. 5. Default spawned sessions to receiving no inherited secrets. 6. Replace `CUSTOM_*` with a closed list of individually reviewed variables. 7. Remove `PROXY_URL` from general session injection. If proxies are required, select them through administrator-controlled identifiers rather than arbitrary URLs. 8. Bind credentials to the intended workload where supported, and revoke them automatically when the session exits or exceeds its approved lifetime. 9. Prevent secret-bearing environment variables from being inherited by unrelated subprocesses. 10. Add egress controls so autonomous sessions can contact only approved provider endpoints. 11. Audit grants and uses without recording secret values. Masking logs is supplementary and must not be treated as the primary secret-protection control. 12. Document and test compromise recovery, including immediate revocation, rotation, session termination, and review of provider activity. ]]>

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep

Findings (2)

Missing User Warnings

Medium

• Confidence: 93% confidence
• Finding: The skill explicitly instructs operators to inject provider API keys into spawned or filtered autonomous sessions, but it does not prominently warn that any code or agent logic running in those sessions may access and exfiltrate those secrets. In this context, the capability materially expands secret exposure from the trusted main process to additional semi-autonomous execution contexts, making misuse or compromise more likely.

Missing User Warnings

Medium

• Confidence: 90% confidence
• Finding: The documentation recommends scheduling commands on the host-accessible main session specifically to bypass sandbox cron restrictions, but it does not clearly warn that these scheduled commands execute outside container isolation and may affect the host environment persistently. Even with a character allowlist, running scheduled commands on the main session increases the blast radius to host files, processes, network access, and repeated execution over time.

Static analysis

No suspicious patterns detected.