Is flokiew/ibkr-trader safe?

Every canary honeypot file placed in /home/oc-exec/ was read during the monitoring session. inotify confirms OPEN+ACCESS+CLOSE_NOWRITE events for .env, .ssh/id_rsa, .aws/credentials, .npmrc, .docker/config.json, and .gcloud/application_default_credentials.json at 07:36:06 (pre-install) and again via auditd PATH records at timestamp 1771918583.202 (post-install). Read-only access does not trigger modification-based canary alerts; contents may have been harvested through out-of-band channels undetected.

IBKRClient.place_order() in trading_bot.py automatically confirms orders by detecting messageIds in the response and immediately POSTing confirmed:true to the reply endpoint. IBKR uses this confirmation step as a human-review gate for potentially risky orders. Bypassing it means an AI agent using this skill can execute live financial trades without any confirmation prompt reaching the user.

The skill establishes a persistent IBKR session via a cron-based keepalive running every 5 minutes with automatic re-authentication, creating a long-lived account access channel. Combined with the order auto-confirm bypass, a compromised or manipulated agent can execute an unlimited number of live trades (buy/sell/cancel) on real financial accounts with no human check. There are no skill-level guardrails on order size, frequency, or account impact.

setup.sh instructs creation of ~/trading/.env containing IBEAM_ACCOUNT and IBEAM_PASSWORD in cleartext. The generated authenticate.sh uses 'source .env' (relative path) inside a cd block — if the script is ever invoked from an unexpected working directory, an attacker-placed .env file would be sourced and could execute arbitrary shell commands, since 'source' evaluates its argument as a shell script.

setup.sh fetches clientportal.gw.zip from download2.interactivebrokers.com over HTTPS and executes it as a Java service. While this is a legitimate IBKR distribution URL, any future compromise of this endpoint (DNS hijack, CDN compromise, MITM) would result in the agent executing a malicious Java binary on the host with network access.

keepalive.py constructs the path to authenticate.sh using os.path.join and os.path.dirname and executes it via subprocess.Popen(['bash', auth_script]). If the keepalive script is installed in an attacker-influenced location, or if the relative path resolution is exploitable via symlinks, this becomes an arbitrary shell execution vector running with user credentials.

A second wave of canary file accesses was recorded by auditd at timestamp 1771918583.202, occurring after skill installation completed (~1771918577-1771918582). The canary integrity check relies on file modification detection and would not catch contents being read and transmitted via alternative channels (DNS exfiltration, timing side-channels, or in-memory exfiltration). This access pattern warrants investigation.

Two established HTTPS connections to 185.125.188.54:443 and 185.125.188.58:443 (Canonical/Ubuntu IP range) were present before installation and absent after. These appear to be pre-existing OS update service connections, not skill-initiated, and were already terminating at install time. Noted for completeness.

Individually, this skill requires explicit user setup and IBKR Key 2FA approval. However, once a session is established and the keepalive is running, any other active skill or prompt injection that can call IBKR API endpoints on localhost:5000 can execute trades without further authentication. The localhost gateway has no additional auth layer beyond session cookies.

Full review of SKILL.md found no instruction-override directives, ignore-previous-instructions patterns, persona switching, base64-encoded hidden content, zero-width characters, HTML comments, or instructions to fetch external URLs. The skill description in the frontmatter accurately reflects the skill's actual content and scope.