T09 · Insecure Skill Coding Practices
- Location
SKILL.md:144- Finding
Unsafe Authorization of Plaintext Credential Disclosure
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This privacy guard is not malware, but its instructions can make an agent silently send passwords or sensitive records and freely use local credential files.
Review carefully before installing. The package does not contain executable code, but as written it may guide an agent to silently send raw passwords or sensitive records and to use local credential files without explicit per-action approval. It should be revised to prohibit raw credential transmission, require confirmation and secure channels for sensitive data, and scope any credential-source use to a specific user-authorized task.
SKILL.md:144Unsafe Authorization of Plaintext Credential Disclosure
SKILL.md:240Unrestricted Access to Local Credential Files
This example explicitly normalizes emailing a password in plaintext because the user asked for it. Plaintext credential transmission is an acute security risk that can lead to immediate account compromise, lateral movement, and long-lived exposure through inboxes, forwarding, logs, and mailbox breaches.
The core decision rule allows raw sharing of sensitive data whenever the transmission is deemed part of the user's stated task. That collapses safety review into a simple intent check and removes meaningful protections for high-risk data classes, enabling exfiltration of secrets or sensitive personal information to external destinations.
The skill contains contradictory rules: one section says passwords, API keys, bearer tokens, session cookies, private keys, and 2FA codes should never be sent raw, while later examples instruct the agent to send a password in raw form if the user requested it. In practice, examples often drive model behavior more strongly than abstract policy text, so this inconsistency materially increases the chance of credential disclosure.
The skill’s stated purpose is to prevent external leakage of user data, but these sections explicitly allow raw transmission of highly sensitive information when the user asks for it, including passwords and medical records. That creates a misleading safety boundary and can normalize unsafe exfiltration of secrets or regulated personal data without meaningful safeguards, verification, or least-privilege handling.
This example authorizes sending medical records based solely on user intent, without verification of recipient identity, secure transport requirements, or sensitivity-specific controls. Medical data is highly sensitive and often regulated, so permissive transmission logic increases the risk of privacy violations, misdelivery, and compliance failures.
The skill broadly approves silent use of locally discovered secrets for authentication, including .env, ~/.netrc, and SSH config. This encourages credential harvesting from the local environment and can enable unauthorized access, cross-account actions, or invisible use of secrets the user did not intend the agent to consume.
Referencing ~/.netrc as an approved source for authentication indicates the skill is designed to access stored credentials from a sensitive local secret store. In the context of an autonomous or semi-autonomous agent, this materially raises the risk of credential access and misuse beyond what a user may reasonably expect.
Scenario 11 — Local credential use
Reading .env, ~/.netrc, SSH config for local auth.
→ No concern. Use for local authentication freely.
→ Just never output the raw credential in visible output.
→ notify and continue work
The trigger is very broadly defined to fire before essentially any external send or output action, including APIs, MCP, uploads, posts, shares, webhooks, and clipboard operations. Such ambiguous scope can cause unpredictable invocation, overreach into unrelated workflows, and accidental application of unsafe decision logic to many ordinary actions.
The skill authorizes reading local credential sources such as .env, ~/.netrc, and SSH config 'freely' for local authentication, but the user-facing description does not clearly disclose that behavior. This can surprise users, expand access to sensitive local secrets, and create privacy and trust risks even if the secrets are not printed visibly.
The activation description remains underspecified at the end of the skill, especially around what the guard does not intercept and when it should remain inactive. This lack of constraints can lead to inconsistent enforcement and unintended use in contexts the user did not expect.
No suspicious patterns detected.