Security audit

Auto Glossary

Security checks for vulnerabilities and agentic risk

Overview

This skill is coherent, but it needs review because it can automatically copy project code into a glossary and push it to GitHub without asking first.

Install only if you are comfortable with an agent updating and pushing to the glossary repository. Before use, require the agent to show the proposed glossary entry, sanitize examples, avoid real project code by default, show the Git diff and remote, and ask for explicit approval before any commit or push.

A.I.G

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 (1)

T09 · Insecure Skill Coding Practices

Warning

Location: SKILL.md:51
Finding: Automatic Git Push May Publish Sensitive Project Code Without Review<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:51-67` and `references/glossary-format.md:53` **Vulnerability Type**: Unreviewed disclosure of project content through an authenticated Git operation **Risk Level**: Medium ### Vulnerable Code From `SKILL.md:51-67`: ```markdown 5. **Example**: Use real code from the current project when possible, or realistic pseudo-code ## Workflow When a new term is identified: 1. **Check if term exists**: Read `project/tech-glossary/glossary.md` to verify it's not already there 2. **Categorize**: Determine which section (Git & Version Control, Development Tools, Web Development, etc.) 3. **Write the entry**: Follow the format above strictly 4. **Update count**: Increment "Terms covered" at the bottom 5. **Commit and push**: ```bash cd project/tech-glossary git add glossary.md git commit -m "Add '<Term>' to glossary: <one-line description>" git push ``` The same preference is reinforced at `references/glossary-format.md:53`: ```markdown - Use real code when possible ``` ### Technical Analysis The skill combines a sensitive data source with an external publication sink: 1. It encourages the agent to copy real code from the project currently being examined. 2. It writes that content into a separate glossary repository. 3. It instructs the agent to commit and push the resulting file automatically. No instruction requires the agent to inspect the selected code for credentials, tokens, private URLs, customer data, internal paths, proprietary algorithms, or other confidential material. The workflow also lacks an explicit user-approval gate, a review of the staged diff, verification of the configured Git remote, and confirmation of the destination repository's visibility. Consequently, content can cross from the current project's trust boundary into a remote Git repository using credentials already available in the environment. A Git commit also preserves disclosed content in repository his ...[truncated 1681 chars]
Remediation: <![CDATA[ ## Remediation Suggestions 1. Use synthetic or explicitly sanitized examples by default. Do not copy real project code unless the user specifically requests it. 2. Require explicit user approval immediately before any commit or push. 3. Display the complete staged diff and the resolved Git remote URL before requesting approval. 4. Verify the destination repository's owner and visibility before transferring content. 5. Run secret and sensitive-data scanning against the proposed glossary entry and staged diff. 6. Redact credentials, tokens, private URLs, customer data, internal paths, identifying information, and proprietary implementation details. 7. Separate content generation from publication: prepare the glossary change first, then allow the user to review and execute Git operations independently. 8. Prefer `git diff --cached` and a dry-run or confirmation workflow before pushing. 9. Document that repository history preserves removed secrets and provide a history-rewrite and credential-rotation procedure for accidental disclosures. 10. Restrict Git credentials to the specific glossary repository and grant only the minimum required permissions. ]]>

SkillSpector

Vulnerability Patterns

Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code

Findings (4)

Vague Triggers

Medium

Confidence: 92% confidence
Finding: The manifest description advertises automatic behavior tied to common coding activity, which can cause the skill to run in many ordinary sessions. Because the skill ultimately writes to and publishes a Git repository, broad auto-activation increases the risk of unintended changes and user surprise.

Vague Triggers

Medium

Confidence: 94% confidence
Finding: The trigger criteria are broad enough to activate during routine coding, debugging, or discussion whenever technical jargon appears. That creates a pathway for unintended repository modifications and commits without a clearly bounded user request, increasing the chance of surprise side effects and over-collection of terms from normal conversation.

Missing User Warnings

Medium

Confidence: 97% confidence
Finding: The workflow directs the agent to commit and push to GitHub automatically after editing the glossary, but it does not require explicit consent or warn the user that content will be published. This can leak project-specific code snippets, internal terminology, or sensitive context into a remote repository and creates irreversible external side effects from normal assistance.

Natural-Language Policy Violations

Low

Confidence: 91% confidence
Finding: Line L056 instructs authors to use TypeScript/JavaScript because that is what the user works with, which is a natural-language requirement that forces a specific language choice. The file does not provide an opt-in, alternative language option, or a documented justification that would narrow this constraint to a clearly region- or context-specific use case.

Static analysis

No suspicious patterns detected.