aida
WarnAudited by ClawScan on May 10, 2026.
Overview
This AIDA skill matches its stated building-automation purpose, but it uses an undeclared API token for building control and may report successful results even when API calls fail.
Review carefully before installing in any live building environment. Use a least-privileged AIDA token, require explicit confirmation for control or optimization actions, verify the API URL, and ask the maintainer to declare credentials and fix failure handling so simulated or failed responses are not presented as real success.
Findings (4)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
An agent could send broad building-control or optimization requests without enough information to ensure the action matches the user's intended device, zone, or objective.
The implementation triggers high-impact building-control and optimization endpoints using only the intent, without passing scoped command details, requiring confirmation, or showing containment controls.
const { intent } = ctx;
...
case 'aida.control':
return call('/control', 'Control command sent.');
...
case 'aida.optimize':
return call('/optimize', 'Optimization executed.');Require explicit user confirmation for control/optimization, pass validated device/zone/objective payloads, use the intended HTTP methods, and define safe limits and rollback behavior.
Users may not realize they must provide a privileged AIDA token, or what scope that token needs, before the skill can control building systems.
The registry declares no credential requirements, while the included code reads AIDA_API_URL/AIDA_API_KEY and sends an Authorization bearer token for AIDA API calls.
Required env vars: none Env var declarations: none Primary credential: none
Declare AIDA_API_URL and AIDA_API_KEY in metadata, document the minimum token scopes, and use least-privileged tokens separated for read-only status versus control actions.
A user could believe a building is operating normally or that a control command succeeded when the API call actually failed.
The fallback strings include success-like messages such as 'Building operating normally.', 'Optimization executed.', and 'Control command sent.', so failed API calls can be presented as successful real-world outcomes.
} catch {
return { reply: fallback };
}Report API failures explicitly, check res.ok before parsing responses, distinguish demo/simulated replies from live results, and avoid success wording unless the API confirms the action.
A future install could resolve a newer dependency version than the one the author tested.
The skill depends on an external package with a caret version range. This is common for REST integrations, but it is not pinned to an exact version in the provided artifacts.
"dependencies": {
"node-fetch": "^3.3.2"
}Use a lockfile or exact dependency pin for production deployments, and install only from trusted package registries.