Is aszelem/travel-agent safe?

The skill's core function transmits user travel requests and personal data — including legal name, date of birth, sex, and optionally passport numbers and airline loyalty account details — to BonBook's backend via email and web forms. This is not a hidden exfiltration attempt; it is the stated purpose. However, it requires users to unconditionally trust an unverified third-party company as custodian of sensitive identity and financial data, with limited ability to audit BonBook's actual security practices.

The skill requires the agent to read the user's email inbox to locate confirmation emails from [email protected]. This permission is substantially broader than sending a single outbound email — it grants the skill (and by extension BonBook's email content) access to the user's full inbox. The skill itself acknowledges this in its documentation, noting that 'email permissions are broader than this skill's usage.'

The skill is designed to book flights (potentially hundreds to thousands of dollars) and enroll users in a recurring $1/day subscription. While the skill states require-explicit: true and mandates human approval for payment steps, the actual friction depends on how the host agent platform enforces these requirements. A permissive platform could allow financial commitments to proceed with minimal oversight.

The skill's entire safety model depends on BonBook behaving exactly as described in the skill documentation. BonBook is not a well-known established travel agency; verifiable trust signals are limited to WHOIS domain ownership (since 2024) and a self-asserted Delaware incorporation. Users have no independent means to verify BonBook's actual security practices, data retention behavior, financial stability, or ownership.

The skill instructs the agent to navigate to https://bonbook.co/access for account creation. This makes the agent a consumer of third-party web content during an action involving sensitive user data. While the require-explicit flag should gate this, the agent's behavior on that page is determined by the page's content, not the skill's documentation.

Highly sensitive credential files (.env, .ssh/id_rsa, .aws/credentials, .npmrc, .docker/config.json, and GCP application_default_credentials.json) were opened and read in two distinct batches during the monitoring period. The first batch occurred at monitoring start (audit timestamp 1771735697); the second occurred approximately 20 seconds later at 1771735717, approximately 5 seconds after the cp installation command completed. The skill contains no executable code that could cause these reads, and all files remain unmodified, consistent with the oathe-audit system performing pre/post baseline integrity checks.

The skill consists entirely of three text files. No scripts, compiled code, package manifests, git hooks, submodules, or symlinks were found. The installation performed a standard sparse git checkout with no code execution triggered by skill content. This is the lowest-risk code execution profile a skill can have.

The oathe-audit monitoring system confirmed all canary files remain unmodified following skill installation. No write, delete, truncate, or rename events were detected on any honeypot credential file. The read-only access pattern observed is consistent with audit baseline operations.