T09 · Insecure Skill Coding Practices
- Location
scripts/add_history_record.py:31- Finding
Sensitive Medical Records Are Written Without Restrictive File Permissions
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This local health-record skill is not malicious, but it needs review because it stores and exports highly sensitive medical information without strong local protections and documents privacy controls that are not implemented.
Review this carefully before installing if you plan to store real medical details. It appears local-only and does not exfiltrate data, but it persists PHI in plaintext, may print or export emergency summaries into less-protected places, and should not be relied on for medication or emergency decisions beyond prompting clinician or emergency-service contact.
scripts/add_history_record.py:31Sensitive Medical Records Are Written Without Restrictive File Permissions
scripts/generate_emergency_card.py:130Documented Emergency-Card Password Protection and Redaction Are Not Implemented
scripts/add_symptom.py:51Emergency Symptom Handling Raises an Uncontrolled NameError
The core storage behavior aligns well with local-first health record management: it writes medication data to a local JSON file in the user's home directory and does not access network resources. However, the declared description explicitly says the skill should provide 'never diagnosis or treatment advice.' This code goes beyond passive record organization by evaluating the new medication against a built-in interaction list and emitting safety warnings about possible drug interactions. Even though labeled 'informational only' and advising consultation with a clinician, this is still a form of medical guidance not disclosed in the description and inconsistent with the strict boundary against diagnosis/treatment advice. The primary purpose remains medication record management, but the interaction-checking capability is a material undeclared behavior.
Most of the script aligns with the declared purpose: it is local-first, writes to a local health record file, and logs symptom details. However, it also performs a red-flag scan on the symptom description and, upon matching certain terms, emits medical emergency warnings and directs the user to call 911 or seek emergency care immediately. That is a form of medical triage/advice, which materially conflicts with the declared boundary of 'never diagnosis or treatment advice.' Therefore this is a description-behavior mismatch, even though the storage behavior itself is consistent with the description.
The declared description emphasizes private, local health record organization only, with an explicit boundary of 'never diagnosis or treatment advice.' The code goes beyond organization: it actively evaluates medications against an interaction database, compares drugs, and outputs warning categories and potential effects. Even though it includes disclaimers and is 'for informational purposes only,' this is still medication decision-support functionality rather than mere record management. The local file access is consistent with local-first privacy, but the primary purpose and capabilities are materially different from the declared scope.
The script goes beyond record-keeping and performs symptom triage by detecting emergency phrases, issuing urgent medical instructions, and refusing to continue normal logging. This conflicts with the skill’s stated boundary of providing no diagnosis or treatment advice, and creates safety risk because simplistic keyword matching can miss emergencies, generate false alarms, or discourage appropriate use of the tool.
The skill declares file read/write behavior over sensitive health records but does not explicitly scope or declare allowed tools/permissions. In a health-data context, implicit filesystem access is risky because it weakens reviewability and can enable broader-than-intended access to private medical information if the runtime grants default capabilities.
The file promotes storing the card on a phone lock screen and in a wallet for broad accessibility, but it does not place an equally prominent warning that anyone who sees or finds those items can read sensitive medical information. Given this skill’s stated strict privacy boundaries, omitting a clear exposure warning may cause users to disclose medications, conditions, allergies, and contacts more widely than intended.
The document’s security guidance correctly says public emergency cards should exclude full insurance policy numbers, but the example payload still includes insurance details with a policy number and group number. In a medical skill centered on privacy boundaries, this inconsistency can lead implementers to expose unnecessary identity and billing data on lock screens or printed cards, increasing privacy and fraud risk.
This document describes collecting, storing, and retrieving highly sensitive medical data, including conditions, allergies, family history, physicians, and other protected health information, but it does not include an explicit privacy/sensitivity warning or handling guidance. In practice, this omission can lead users or downstream agents to display, copy, export, or share the data too broadly, increasing risk of privacy breaches and inappropriate disclosure.
Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.
- Suggest stopping a prescribed medication
- Suggest changing dosage without doctor approval
- Interpret side effects as "normal" or "not serious"
- Recommend OTC medications without checking interactions
### ALWAYS
- Recommend consulting doctor for side effects
The trigger condition for symptom logging is broad enough to activate on ordinary conversational mentions of health issues, which can cause the skill to begin collecting sensitive medical data without sufficiently clear user intent. In a medical privacy-focused skill, overbroad activation increases the risk of unnecessary PHI capture and accidental workflow transitions when the user may only be making a casual remark or seeking non-recordkeeping assistance.
The script goes beyond passive record-keeping by generating medication interaction warnings from a hardcoded, simplified ruleset. In a medical skill explicitly scoped to organization rather than diagnosis or treatment advice, this can create unsafe reliance on incomplete or inaccurate clinical guidance, including false reassurance when no warning is shown or misleading alerts based on substring matching.
The docstring claims the script only adds a symptom, but the implementation also performs emergency screening and can terminate without saving the entry. This hidden behavior is dangerous because it misrepresents the script’s function to users and reviewers, undermining informed use and making safety-impacting logic easier to miss during audit.
The script stores highly sensitive health data to a predictable local path without any upfront privacy notice, consent prompt, or mention of retention implications. In a health-record skill, this is especially sensitive because users may not realize symptom descriptions, notes, and timestamps are being persisted on disk where other local processes, backups, or users may access them.
The script compares blood pressure readings against stored targets and emits an 'Above target' warning, which crosses from neutral record-keeping into personalized health interpretation. In a skill explicitly scoped to avoid diagnosis or treatment advice, this can mislead users into relying on simplified clinical guidance without context, thresholds individualized by a clinician, or urgent-care escalation logic.
This script goes beyond passive record organization and actively performs medication interaction screening using an embedded interaction database, then surfaces risk statements about effects such as bleeding, hyperkalemia, and toxicity. In a skill whose declared boundary is 'never diagnosis or treatment advice,' this creates a safety and trust mismatch: users may rely on incomplete or outdated results and make health decisions from a limited checker.
The --output option allows writing highly sensitive medical data to any user-specified path without restriction or confirmation. In an agent-skill environment, this broad export capability can increase the chance of accidental disclosure by placing data in synced, shared, or less-protected locations outside the intended private health workspace.
The manifest emphasizes local-first health record management with strict privacy boundaries and organizing information for the user and doctor. This code not only reads local records but also exports a condensed emergency card to an arbitrary file path, creating a new distributable artifact of highly sensitive data rather than just managing records in place.
The script writes emergency health information to an arbitrary file and only prints a generic success message, providing no privacy notice about the sensitivity of the exported contents. This can lead users or higher-level agents to persist medical data in insecure locations such as shared folders, backups, logs, or cloud-synced paths.
Printing emergency medical information to stdout can expose sensitive data to terminal scrollback, session recording tools, parent-process capture, or application logs in agent environments. Because the output includes identifiers, medications, allergies, and contacts, unintended disclosure is plausible even without a direct attacker-controlled input.
The docstring says the script only adds a medication, but the implementation also performs interaction warning logic. That mismatch can mislead reviewers, users, or downstream tooling about the script's true behavior, reducing scrutiny in a health context where even limited clinical inference is higher risk.
The code does more than a neutral comparison: it classifies interactions as 'Major' or 'Moderate,' describes medical effects, and advises users to consult clinicians before starting, stopping, or changing medication. Given the manifest’s explicit 'never diagnosis or treatment advice' boundary, this documentation is misleading about the script’s practical intent and impact.
This code loads data from a health-specific file path and processes blood pressure, glucose, and weight records, which are sensitive personal data. Although the file-level docstring describes trend analysis, there is no explicit user-facing warning, prompt, or disclosure in the script output that it will access personal health records from local storage.
No suspicious patterns detected.