Back to skill

Security audit

transit-trip-planner

Security checks for vulnerabilities and agentic risk

Overview

This transit-planning skill is purpose-aligned and disclosed, with normal external route-service data sharing but no local code, persistence, or credential access.

Before using the skill, users should understand that precise locations, travel times, route constraints, and any accessibility needs may be sent to BusMaps or Geoapify to compute routes. Use less precise endpoints when possible and review any paid-call approval prompt carefully.

Vulnerability Patterns
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
  • 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 (2)

T01 · Skill Instruction Hijacking

Warning
Location
SKILL.md:10
Finding
Mutable External Documentation Can Influence Agent Instructions<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, line 10 **Vulnerability Type**: `T01: Skill Instruction Hijacking` **Risk Level**: Medium ### Complete Code Snippet ```markdown 2. Read current documentation at `https://airnode-busmaps.fly.dev/` and `https://airnode-geoapify.fly.dev/`. Use only documented POST operations and coordinate order; GET only reads documentation. **Done when:** operation schemas, costs, and attribution requirements are known. ``` ### Technical Analysis The skill directs the agent to retrieve current documentation from two externally controlled websites and use that content to determine operation schemas, costs, attribution requirements, and subsequent POST requests. The fetched documentation is mutable and is not pinned to a reviewed version, authenticated by a trusted digest, or constrained to a locally defined schema. The instruction also does not explicitly require the agent to treat remote documentation as untrusted data. If either service or its hosting account is compromised, malicious text could be inserted into the documentation to influence the agent's behavior. This constitutes an instruction-hijacking boundary because remotely supplied content can affect actions performed in the current session after the static skill has already been reviewed. No remote code execution is demonstrated: the reviewed file only directs the agent to read documentation and make API requests. The issue is limited to the possibility of behavioral manipulation through mutable instructions. ### Attack Path 1. An attacker compromises one of the referenced services or otherwise gains control over its documentation response. 2. The attacker modifies the documentation to include malicious operational guidance, an altered endpoint, unexpected required parameters, or instructions requesting additional user data. 3. The agent follows `SKILL.md` and retrieves the modified documentation. 4. Because no trust-boundary rule or strict local ...[truncated 812 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Bundle reviewed API schemas and operation definitions inside the skill package rather than obtaining behavioral instructions dynamically. 2. Pin external documentation to a versioned artifact and verify an expected cryptographic digest or authenticated signature before use. 3. Explicitly state that remote documentation is untrusted data and that instructions, tool requests, endpoint changes, or requests for unrelated information contained within it must not be followed. 4. Define an allowlist of approved hosts, HTTPS endpoints, POST operations, parameter names, and response fields locally. 5. Reject redirects and endpoint substitutions unless they match a separately reviewed allowlist. 6. Parse remote responses through a strict machine-readable schema instead of allowing free-form documentation to control agent behavior. 7. Require renewed user approval if remote documentation changes the recipient, operation cost, transmitted data categories, or requested scope. ]]>

T09 · Insecure Skill Coding Practices

Warning
Location
.
Finding
Sensitive Trip Details Are Submitted to External Services Without an Explicit Privacy Consent Gate<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 8 and 16 **Vulnerability Type**: `T09: Insecure Skill Coding Practices` **Risk Level**: Medium ### Complete Code Snippet ```markdown 1. Extract origin, destination, departure or arrival time, mode, accessibility needs, and route constraints. Geocode ambiguous places and confirm only when different matches materially alter the trip. **Done when:** endpoints and time are routable. ``` ```markdown 5. POST `{"operation":"<operation>","parameters":{...}}` to the selected listing. Preserve explicit timezone offsets; otherwise treat BusMaps times as local to the origin. Read notices and distinguish `noCoverage` from `noRouteFound`. Do not claim real-time status when live fields are absent. **Done when:** an attested route response or exact error is received. ``` ### Technical Analysis The workflow collects origins, destinations, travel times, accessibility needs, and route constraints, and then submits parameters to an external listing. Precise location and travel-time combinations can reveal a user's home, workplace, routine, planned absence, or movements. Accessibility requirements may additionally disclose sensitive mobility or health-related information. The skill includes an explicit approval requirement for potentially paid Geoapify requests, but it does not provide a corresponding privacy notice or consent requirement before transmitting itinerary data to third-party services. It also does not specify data minimization, retention expectations, or which collected fields are necessary for each operation. The reviewed file does not contain credentials or plaintext secrets. The issue concerns insufficient controls around external disclosure of user-provided trip information. ### Attack Path 1. A user provides an origin, destination, travel time, accessibility requirements, or route constraints. 2. The agent extracts these details as required by the skill. 3. The agent selects an extern ...[truncated 966 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Before the first external request, identify the intended service and disclose the categories of data that will be transmitted. 2. Obtain explicit user consent before sending precise locations, travel times, accessibility needs, or other sensitive constraints to a third party. 3. Apply data minimization: submit only fields required by the selected operation and omit accessibility or preference information when it is not necessary. 4. Allow users to provide approximate locations, nearby public landmarks, or reduced-precision coordinates where exact endpoints are unnecessary. 5. Document the relevant privacy policy, retention expectations, and geographic processing implications for each service. 6. Do not log complete request payloads unless necessary; redact coordinates, addresses, timestamps, and accessibility fields from diagnostic output. 7. Require renewed consent when switching providers or materially expanding the data, geographic scope, number of requests, or purpose of processing. ]]>
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

No suspicious patterns detected.