Back to skill

Security audit

Tinker ORCA

Security checks for vulnerabilities and agentic risk

Overview

This is a real parallel coding workflow, but its strongest write-safety claim depends on spawned agents following instructions rather than trusted enforcement.

Install only if you are comfortable letting this skill spawn coding agents with shell and repo write/delete access. Use minimal units[].writes allowlists, avoid raw command and external-program options unless you trust them, keep committing off until you inspect changes, and run it in an OS/container sandbox if you need hard protection against symlink or out-of-repo writes.

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
scripts/parallel-implement.workflow.js:423
Finding
Filesystem Write Containment Is Delegated to an AI Agent Instead of Enforced by Trusted Code<![CDATA[ ## Vulnerability Details **File Location**: `scripts/parallel-implement.workflow.js:423-448`, with related enforcement logic at `scripts/parallel-implement.workflow.js:970-984`, `scripts/parallel-implement.workflow.js:986-1024`, and `scripts/parallel-implement.workflow.js:1154-1190` **Vulnerability Type**: Agent-enforced filesystem boundary and trusted self-reporting **Risk Level**: High ### Vulnerable Code The realpath containment control is generated as text and placed into the apply agent's prompt: ```js /** * This orchestrator has no filesystem access of its own - it composes prompts and reads back * structured results - so the resolution has to happen where the write happens. This emits the * exact check the writing agent runs against every target before touching it, as a shell function * rather than a description, so there is nothing to paraphrase. A target that resolves outside the * root, or that IS a symlink, is refused and the unit reports the refusal instead of writing. * * `root` is the directory writes must stay inside: the repo in in-place mode, the group's worktree * in worktree mode, the staging directory while a UI-watched unit is staged off-tree. */ const containmentGuard = (root, what) => [ `REALPATH CONTAINMENT - run this FIRST, before you edit, copy or create anything, and keep it for the whole unit:`, '```sh', `orca_root=$(cd -P -- ${shq(root)} && pwd -P) || exit 1`, `orca_contain() {`, ` t=$1`, ` if [ -L "$t" ]; then echo "ORCA REFUSED: $t is a symlink"; return 1; fi`, ` d=$(dirname -- "$t")`, ` while [ ! -d "$d" ]; do d=$(dirname -- "$d"); done`, ` rd=$(cd -P -- "$d" && pwd -P) || return 1`, ` case "$rd/" in "$orca_root"/*) return 0 ;; esac`, ` echo "ORCA REFUSED: $t resolves to $rd, outside $orca_root"; return 1`, `}`, '```', `Then, for EVERY ${what} - each file you edit, each file you create, each destination you copy to - run \`orca_contain "<that path>"\` and proceed ONLY if it ...[truncated 4320 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. **Move writes into a trusted executor** - Keep drafting agents read-only. - Parse and validate their structured patches in trusted code. - Apply patches through a deterministic local component rather than asking another AI agent to perform unrestricted writes. 2. **Enforce containment immediately before opening each destination** - Resolve the repository root and nearest existing parent using trusted filesystem APIs. - Reject destinations whose resolved parent is outside the approved root. - Reject targets that are symbolic links. - Use directory-relative, race-resistant operations such as `openat`-style APIs with no-follow semantics where the platform permits. 3. **Reduce agent privileges** - Do not grant apply agents general shell and unrestricted file-write capabilities. - If an agent must write, run it in an operating-system sandbox or container where only the intended worktree is writable. - Mount all unrelated filesystem locations read-only or make them inaccessible. 4. **Audit actual changes independently** - Derive changed paths from Git and filesystem state instead of trusting `filesChanged`. - Compare the independently observed changes against each unit's allowlist. - Fail the run and preserve forensic details if any unapproved path changes. 5. **Prevent time-of-check/time-of-use races** - Avoid separately checking a path and later opening it by pathname. - Hold trusted directory handles and create or update files relative to those handles. - Revalidate containment at the actual write operation. 6. **Correct the documentation until enforcement is implemented** - Clearly state that current realpath containment depends on agent compliance. - Do not describe the on-disk boundary as “enforced in code” while the trusted orchestrator cannot verify or enforce the actual write. ]]>
Vulnerability Patterns
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep

Static analysis

Detected: suspicious.dangerous_exec, suspicious.dynamic_code_execution

Shell command execution detected (child_process).

Critical
Code
suspicious.dangerous_exec
Location
scripts/parallel-implement.workflow.js:687

Dynamic code execution detected.

Critical
Code
suspicious.dynamic_code_execution
Location
scripts/selftest.mjs:41