Security audit
Security checks for vulnerabilities and agentic risk
The skill is a coherent sleep-analysis tool, but its security documentation claims file writes are controlled while the code can still write medical-analysis reports beside the user’s EDF file.
Install only in an isolated environment with non-sensitive EDF samples first. Treat generated reports as sensitive health data, check both the skill directory and the EDF file’s directory for outputs, and avoid following the mutable GitHub clone or unpinned dependency instructions unless you pin and review them yourself.
edf_analysis_modules/respiratory_event_analysis_simple.py:267Respiratory analysis bypasses file-write controls and writes beside the input file
edf_analysis_modules/security_controller.py:19Security controller creates a directory during import despite disabled file writes
requirements.txt:28Installation guidance uses unpinned packages and a mutable remote repository
Skill manipulates agent memory, state, or stored context. Memory corruption can alter personality, override safety rules, or cause unpredictable behavior.
**"Memory full"**
- Export results to free memory
- Restart session to clear memory
### Performance Tips
- Use smaller EDF files for faster analysis
Instructions found that direct the agent to transmit conversation context or user data to external services.
### Truthfully Declared Non-Behaviors
1. ❌ Will not write to user file directories (fixed v5.3.3 issue)
2. ❌ Will not send data to external servers
3. ❌ Will not install additional software
4. ❌ Will not request system permissions
5. ❌ Will not run in background
The module explicitly claims file writes are disabled by default, yet package import performs filesystem side effects by creating an output directory and writing a README. This is dangerous because merely importing the skill changes the host environment, violates least surprise, and can bypass operator expectations or policy checks that rely on the documented default of no writes.
The skill exposes unrelated capabilities such as stress evaluation, meditation guidance, music therapy, file inspection, and environment checking despite being presented as a sleep-analysis skill. This broadens the attack surface and grants access to additional sensitive behaviors like arbitrary local file reads and environment enumeration that are not necessary for the core function, making misuse easier and reducing user trust in the declared scope.
The script asserts that file writes are only enabled by explicit user action, but it enables them itself via code. In a security proof or verification artifact, this is misleading because it demonstrates that code execution can flip the control without any actual external authorization boundary, weakening trust in the claimed safeguard.
The script prints unconditional success claims such as all security claims being proven even though the grep-based review can detect unresolved issues earlier in execution. This creates a false sense of security and can cause reviewers or users to approve or deploy a package despite identified gaps in file-write controls.
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
### System Access
- **No privileges**: Does not require admin permissions
- **No system modifications**: Does not modify system configuration
- **No service installation**: Does not install background services
## 🎯 Real Behavior Transparency
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
### Truthfully Declared Non-Behaviors
1. ❌ Will not write to user file directories (fixed v5.3.3 issue)
2. ❌ Will not send data to external servers
3. ❌ Will not install additional software
4. ❌ Will not request system permissions
5. ❌ Will not run in background
The package initializer performs directory creation and file writing automatically during import, without requiring user consent or an explicit runtime action. In multi-skill or restricted environments, import-time writes can create unauthorized persistence artifacts, fail unexpectedly under sandboxing, or undermine trust boundaries even if the written content itself is not malicious.
The module-level security claims are contradicted by the implementation: the code constructs multiple output artifact paths directly and contains no visible security controller, permission check, or user-gated write enablement. Misleading security assertions are dangerous because downstream users or orchestrators may trust the module to avoid writing files when, in fact, it is designed around artifact generation paths.
This code emits user-facing status messages in a fixed non-English locale and continues that pattern throughout the script. There is no indication that the user can choose language or that the locale restriction is documented as a justified regional requirement.
The function loads an EDF sleep-study file, which can contain sensitive medical data, but the code provides only generic progress prints and no explicit disclosure about processing potentially sensitive health information. For code-file warning checks, sensitive data handling should have some user-facing notice, comment, or documented warning if privacy impact is relevant.
The module creates paths for analysis outputs under an analysis_outputs directory and later reports those artifact locations, but there is no concrete user disclosure near the operation that files will be generated in that location. Although the header mentions file writes generally, the code itself does not clearly warn the user what artifacts are produced or where.
The docstrings and status messages present this module as a professional respiratory analysis workflow that produces analysis artifacts, and the code computes output file paths for PNG/JSON/TXT results. However, it never calls functions such as plt.savefig() or writes the JSON/text report, while still printing a success message and advertising an output directory, which contradicts the apparent documented intent of producing saved analysis outputs.
This code prepares filesystem output paths for generated analysis artifacts and reports under an analysis_outputs directory, but there is no confirmation prompt and no clear docstring or comment warning the user that running the function will create files. For a code file, file-writing behavior should have some visible disclosure unless it is clearly communicated as part of the skill's behavior.
This codebase presents its title, console output, generated reports, and clinical recommendations entirely in Chinese, indicating a fixed language/locale behavior. The policy for this category applies to language constraints that are imposed without user opt-in, and there is no mechanism here to select another language or acknowledge the restriction.
The module docstring and class comments emphasize a security controller focused on controlling file writes, yet object initialization immediately creates an analysis_outputs directory as a side effect. This contradicts the stated framing that file writes are disabled by default and that writes are only enabled by explicit user action.
The visualization methods accept an output_path parameter and the main routine constructs a timestamped PNG path, which strongly signals an intent to write result images. However, both plotting methods only build figures and call plt.close() without any save operation, and main never creates the output directory either, so the documented/implied output behavior does not occur.
This code loads an EDF file containing potentially sensitive physiological data and then generates output artifacts, including a plot path under a user-specified output directory. While there is some status printing, there is no clear user-facing warning, comment, or docstring disclosing that medical sleep data will be read and output files will be created, which matters for privacy and data-handling awareness.
The module docstring claims this is a 'Sleep Spindle Analysis Module', which implies a focused spindle-detection purpose. However, the implementation includes full EDF loading, sleep staging, respiratory event detection, SpO2 validation, summary generation, and reporting beyond spindle analysis.
The second docstring frames the module as 'respiration sleep analysis based on AASM standard'. Later code includes a dedicated SpindleDetector, spindle statistics, and spindle visualizations, which materially expand the module beyond what that inline documentation states.
The module configures file-based logging and later writes analysis artifacts to disk, which can include paths, timestamps, and potentially sensitive sleep-study derived results. In a healthcare or research context, silently persisting such data increases the risk of local data exposure, accidental retention, and unauthorized access on shared systems.
The module ingests EDF sleep-study files, which commonly contain sensitive health information, yet provides no privacy notice, retention guidance, or safeguards around downstream persistence and handling. In the context of an agent skill, this is more concerning because users may run it in automated environments without realizing medical data is being processed and later stored.
The report note says the analysis is based on sleep EEG/EOG/EMG, which conveys multimodal physiological analysis. In practice, the code selects only the first EEG channel at L109-L110 and all extracted features/classification are derived from that signal; detected EOG/EMG channels are listed but never used.
The module docstring presents this as a real professional analysis module, and the code flow in steps [8/8] and helper names suggests it produces saved analysis outputs. However, the JSON path is computed but never written, and the plotting/text-report helpers only construct paths and print messages without saving files, contradicting the documented/output intent.
No suspicious patterns detected.