Security audit
Security checks for vulnerabilities and agentic risk
This is a straightforward OpenWeatherMap helper that shares weather lookup locations and an API key with OpenWeatherMap as part of its stated purpose.
Before installing, understand that weather lookups will send the queried city or coordinates and your OpenWeatherMap API key to OpenWeatherMap. Prefer the environment variable for the API key, avoid entering precise coordinates unless needed, and do not paste real keys into shared logs or prompts.
The skill description is broadly worded to activate on virtually any weather-related query for any location, which can cause over-invocation and unnecessary routing of user requests to this skill. In context, that increases the chance that user-provided location data and associated API-backed requests are sent to an external service without sufficiently specific user intent or clear disclosure.
The skill documentation does not warn users that their city name, coordinates, and API credential will be transmitted to OpenWeatherMap. This is a genuine transparency and privacy issue because the skill’s core behavior is to send user-supplied location data to a third-party service.
This endpoint performs an external network transmission of user-provided location data together with the API key to a third-party service. In a weather skill this is expected functionality, but it still creates a real privacy and secret-handling risk if users are not informed and if requests are not minimized or protected.
GET https://api.openweathermap.org/data/2.5/weather?q={city},{country_code}&appid={API_KEY}&units={units}
This coordinates-based endpoint sends precise latitude and longitude to an external provider along with the API key. Because coordinates can be highly sensitive compared to city-level queries, this transmission has elevated privacy significance even though it is functionally necessary for the skill.
GET https://api.openweathermap.org/data/2.5/weather?lat={lat}&lon={lon}&appid={API_KEY}&units={units}
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
curl "https://api.openweathermap.org/data/2.5/weather?q=London,UK&appid=YOUR_API_KEY&units=metric"
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
curl "https://api.openweathermap.org/data/2.5/weather?q=London,UK&appid=YOUR_API_KEY&units=metric"
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
curl "https://api.openweathermap.org/data/2.5/weather?q=London,UK&appid=YOUR_API_KEY&units=metric"
The forecast endpoint also transmits user-provided location queries and the API key to a third-party service. This is expected for a weather integration, but it remains a real data-sharing boundary that should be disclosed and handled carefully, especially if invocation happens broadly.
GET https://api.openweathermap.org/data/2.5/forecast?q={city}&appid={API_KEY}&units=imperial
Returns forecast data in 3-hour intervals for 5 days.
The instruction 'Convert Unix timestamps to 24-hour format' forces a specific time-format locale convention for all users. This is a natural-language locale policy issue because it does not offer user preference or explain a region-specific justification.