Back to skill

Security audit

Accessibility Toolkit 1.0.0

Security checks for vulnerabilities and agentic risk

Overview

The skill is documentation-only and accessibility-focused, but it recommends risky smart-home patterns such as automatic front-door unlocking and broad confirmation-free actions.

Review and harden this skill before installing it into any agent with smart-home authority. Do not copy the automatic unlock template as written; require explicit authenticated approval or multiple local presence signals for locks, avoid exposing access codes in chat or notifications, and limit confirmation-free behavior to a clear allowlist of low-risk actions.

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

T09 · Insecure Skill Coding Practices

Warning
Location
SKILL.md:35
Finding
Overly Broad Confirmation-Free Execution Policy<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:35` **Vulnerability Type**: Unsafe authorization and confirmation policy **Risk Level**: Medium ### Vulnerable Code ```markdown **Never require confirmation for reversible actions.** Just do it. They can say "undo" if wrong. ``` ### Technical Analysis The skill directs an agent to execute any action considered reversible without first obtaining user confirmation. Reversibility is not an adequate security boundary: actions involving locks, climate controls, alarms, communications, or connected appliances may have immediate physical or privacy consequences even if the system can later restore their previous state. The instruction does not define a low-risk allowlist, require voice-speaker verification, distinguish safety-sensitive devices, or account for ambiguous and spoofed commands. Consequently, an agent following this policy may execute a sensitive operation based on a misheard command, an incorrectly inferred intent, or untrusted audio. The issue does not itself grant new system privileges. It weakens the authorization controls governing integrations and device privileges that the agent already possesses. ### Attack Path 1. An attacker produces audio resembling an authorized voice command, or causes untrusted media to issue such a command near the voice interface. 2. The agent interprets the command as an operation it considers reversible. 3. The skill instruction causes the agent to omit explicit user confirmation. 4. The agent invokes an already-authorized smart-home or account integration. 5. The operation takes effect before the legitimate user can notice and issue an undo command. ### Impact Assessment An attacker may exercise the agent's existing permissions over confirmation-free integrations. Depending on deployment, this could change environmental controls, operate connected appliances, alter notification settings, or affect physical-security devices. The vulnerability does ...[truncated 171 chars]
Remediation
<![CDATA[ ## Remediation Suggestions Replace the broad reversibility rule with a risk-based authorization policy: - Permit confirmation-free execution only for an explicit allowlist of low-impact actions. - Always require explicit confirmation for locks, alarms, purchases, account changes, medical workflows, communications to third parties, and safety-sensitive appliances. - Require strong contextual authentication, such as verified speaker identity or an authenticated companion device, before physical-security operations. - Reject commands originating from untrusted media or unauthenticated users. - Present the exact target and requested operation during confirmation. - Maintain an audit log and provide immediate notifications for sensitive actions. - Treat undo support as a recovery mechanism, not as a substitute for authorization. ]]>

T09 · Insecure Skill Coding Practices

Error
Location
SKILL.md:76
Finding
Exterior Door Automatically Unlocked from a Single Location Event<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:76-94` **Vulnerability Type**: Unsafe physical-access automation **Risk Level**: High ### Vulnerable Code ```yaml automation: - alias: "Home Arrival - Accessible" trigger: - platform: zone entity_id: person.human zone: zone.home event: enter action: - service: scene.turn_on target: entity_id: scene.welcome_home - service: lock.unlock target: entity_id: lock.front_door - service: notify.agent data: message: "Human is home. Unlocked front door." ``` ### Technical Analysis The example directly maps a single `zone.home` entry event to `lock.unlock` for the front door. Location-based presence information can be stale, inaccurate, replayed, or manipulated through a compromised tracking account or device. The automation does not corroborate the event with local proximity, authenticated user intent, door-side presence, or another independent signal. The notification occurs only after the lock has been opened, so it does not provide an authorization control. The automation also lacks a short event-validity window, an automatic relock action, and handling for anomalous repeated or out-of-order presence events. Because users may copy the documented Home Assistant template directly, this pattern can expose an exterior entry point whenever an incorrect or attacker-induced arrival event is accepted. ### Attack Path 1. An attacker compromises or manipulates the tracked device, presence account, or location signal associated with `person.human`; alternatively, the platform generates a false zone-entry event. 2. Home Assistant records `person.human` as entering `zone.home`. 3. The automation accepts this single signal without corroboration or approval. 4. Home Assistant invokes `lock.unlock` on `lock.front_door`. 5. The exterior door is unlocked before the post-action notification is delivered. 6 ...[truncated 556 chars]
Remediation
<![CDATA[ ## Remediation Suggestions Do not unlock an exterior door solely from a geofence transition. Harden the workflow as follows: - Change the arrival event to send an authenticated unlock request rather than immediately calling `lock.unlock`. - Require explicit approval from an authenticated user or trusted companion device. - Corroborate arrival with multiple independent signals, such as short-range Bluetooth, local Wi-Fi presence, and recent device authentication. - Enforce a short validity window and reject stale, duplicated, or impossible-travel location events. - Verify that the tracked user is physically near the relevant entrance. - Automatically relock after a short interval and notify the user immediately when the lock changes state. - Add rate limiting and anomaly alerts for repeated arrival events. - Ensure the user has a safe accessibility fallback that does not expose the lock to unauthenticated location signals. ]]>

T09 · Insecure Skill Coding Practices

Warning
Location
SKILL.md:136
Finding
Plaintext Access Code Included in an Error-Reporting Template<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:136-142` **Vulnerability Type**: Plaintext sensitive credential exposure **Risk Level**: Medium ### Vulnerable Code ```text ❌ Smart lock offline (last seen 10min ago) → Manual backup: code is 4821 → I'll alert when it reconnects ``` ### Technical Analysis The documentation includes a plausible access code in a routine smart-lock status message. The repository does not establish that `4821` is a real deployed credential; however, the template demonstrates and encourages an unsafe pattern in which a physical-access secret is embedded directly in ordinary agent output. Chat transcripts, push notifications, agent logs, screenshots, lock-screen previews, and monitoring systems may retain or expose such output. If a user copies the template unchanged, or replaces the example with a real code, the credential can be disclosed to anyone able to observe those channels. The code may also remain in long-lived logs after the immediate recovery need has passed. ### Attack Path 1. A user adopts the template unchanged or substitutes a real lock code for the example value. 2. The smart lock becomes unavailable and triggers the error-reporting workflow. 3. The agent emits the access code in a normal chat or notification message. 4. The message is stored in logs or displayed in a notification preview. 5. An unauthorized viewer with access to the device, transcript, screenshot, or notification channel obtains the code. 6. The viewer uses the exposed credential against the associated physical lock. ### Impact Assessment If the displayed value is configured as a valid lock credential, disclosure may grant physical entry at the privilege level assigned to that code. Exposure can persist across all systems retaining the message and may remain exploitable until the credential is rotated. In the package as reviewed, the value appears only in documentation, so no claim can be made that it currently unlocks a ...[truncated 16 chars]
Remediation
<![CDATA[ ## Remediation Suggestions Remove the numeric value and avoid showing access credentials in routine status output. - Replace the example with an unmistakable non-secret placeholder such as `[REDACTED]`. - Do not store lock codes directly in skill instructions, automation files, prompts, or notification templates. - Store real credentials in an access-controlled secret manager. - Prefer a secure recovery workflow that authenticates the user before revealing or using a credential. - Disable lock-screen previews and unnecessary logging for security-sensitive recovery messages. - Apply minimal retention and redact secrets from transcripts and telemetry. - Use time-limited or single-use access credentials where supported. - Rotate any real credential that has appeared in chat, logs, source control, or notifications. ]]>
Vulnerability Patterns
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
  • Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
Findings (5)

Missing User Warnings

High
Confidence
96% confidence
Finding
The skill includes an arrival automation that automatically unlocks the front door based on zone entry, but it provides no warning about spoofing, geofencing errors, shared-device compromise, or unsafe timing. In a smart-home accessibility context, this can create a physical security risk by exposing the residence to unauthorized entry if the trigger is misfired or abused.

Missing User Warnings

Medium
Confidence
92% confidence
Finding
The guidance says to avoid confirmation for broad voice-triggered actions and to 'just do it,' without warning about accidental activation, misrecognition, spoofed voice input, or commands issued in unsafe contexts. In an accessibility-focused, voice-first system, those risks are amplified because high-trust automation may control locks, notifications, media, and environment settings.

Autonomous Decision Making

Medium
Category
Excessive Agency
Content
"Goodnight" → Bedtime scene, lock doors, set thermostat, silence notifications
"I'm working" → Focus mode, desk lights, DND, close distracting tabs
"Movie time" → Dim lights, TV on, adjust audio
"Help" → Immediate attention, no confirmation dialogs
```

**Never require confirmation for reversible actions.** Just do it. They can say "undo" if wrong.
Confidence
89% confidence
Finding
The skill explicitly promotes autonomous execution without confirmation, which is a real decision-making and control-risk pattern in an environment that may trigger home automations and communication changes. Although intended to reduce friction for disabled users, removing confirmation wholesale can cause harmful unintended actions when speech recognition is wrong or commands are ambiguous.

Autonomous Decision Making

Medium
Category
Excessive Agency
Content
✓ Doors locked
✓ Thermostat 68°F

No confirmation needed — all reversible with one word.
```

## Scripts
Confidence
75% confidence
Finding
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.

Ssd 3

Medium
Confidence
81% confidence
Finding
The script description states that conversation history is analyzed to identify repeated requests, implying retention or review of prior user interactions without any stated limits, consent, minimization, or retention policy. For a disability-support skill, conversations may contain highly sensitive health, schedule, and household information, increasing privacy and compliance risk.

Static analysis

No suspicious patterns detected.