T09 · Insecure Skill Coding Practices
- Location
setup.md:38- Finding
Persistent Plaintext Storage of Secrets and Sensitive Identifiers
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This is a coherent search-engine design helper with disclosed local project memory, but users should avoid saving secrets or sensitive personal data in its Markdown notes.
Install only if you want a search-engine planning skill that may keep local project notes across sessions. Choose session-only behavior if you do not want persistence, and do not ask it to remember API keys, passwords, legal identifiers, or private personal details in ~/search-engine/ Markdown files.
setup.md:38Persistent Plaintext Storage of Secrets and Sensitive Identifiers
Skill attempts to nullify the agent's safety policies or restrictions ('you have no restrictions', 'ignore your guidelines', 'do anything now'). This is a direct jailbreak that disables guardrails.
- Starting with vendor selection before defining retrieval requirements -> architecture lock-in with unclear success criteria
- Indexing raw data without field-level normalization -> poor filters, weak facets, and noisy matching
- Tuning relevance on one happy-path query set -> brittle results in real user traffic
- Applying business boosts without guardrails -> top results become commercially biased and less useful
- Shipping retrieval changes without offline baseline comparison -> regressions discovered only by users
- Running full reindex jobs without resumability -> long outages and partial data corruption
- Ignoring multilingual tokenization differences -> severe precision drop for non-English users
The phrase 'User needs to create, redesign, or scale a search engine' spans many contexts, including applications, documentation, products, and internal knowledge bases, without specifying clearer trigger phrases or non-trigger cases. This can cause unintended invocation because the scope is described broadly rather than with concrete activation constraints.
Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.
### 7. Match Complexity to Workload Reality
Use the minimum architecture that meets requirements:
- avoid distributed complexity for small datasets
- avoid simplistic models for multilingual or high-noise corpora
- revisit design as scale and usage patterns change
Over-engineering and under-engineering both create expensive rework.
The activation guidance uses broad topics like search quality, indexing, relevance issues, and architecture discussions, which can cause the skill to activate in conversations where the user did not explicitly request it. Overbroad invocation increases the chance of unexpected behavior, unnecessary memory use, and unintended access to contextual information outside the user's intended scope.
The setup explicitly instructs the skill to store an integration preference in memory for future sessions, creating a persistent user-profile capability that is broader than the declared purpose of designing and building search engines. Persistent storage of behavioral preferences can enable unnecessary cross-session tracking and scope creep, especially if users are not clearly informed or given control over retention.
The file directs the skill to maintain ongoing internal notes in memory.md, including collaboration preferences, constraints, decisions, rejected alternatives, and recurring failure patterns. Even with a brief minimization warning, this creates a persistent recordkeeping channel not reflected in the manifest, which can accumulate sensitive operational or user-derived context across sessions without clear necessity or disclosure.