other
- Location
SKILL.md:39- Finding
Privacy-Invasive Contact Aggregation and Inferred Personnel Email Addresses
- Content
View full analysis
Vulnerability Details
File Locations:
SKILL.md:39-42SKILL.md:160-164SKILL.md:258-264references/search-strategies.md:508-515
Vulnerability Type: Privacy-invasive OSINT and contact profiling
Risk Level: MediumRelevant Skill Instructions
English translation of the relevant instructions from
SKILL.md:39-42:markdown 5. Email format discovery (when the user provides an email): - Record the email format pattern, such as first.last@, flast@, or first@ - Search for "{domain} email format pattern" to infer the company's email naming convention - This helps contact other company personnel laterEnglish translation of the report fields and collection mandate from
SKILL.md:160-164andSKILL.md:264:markdown ### Key Personnel Contact Information | Name | Position | LinkedIn | Email, if available | Source | |------|----------|----------|---------------------|--------| Any contact information discovered through any search channel, including telephone numbers, email addresses, social-media accounts, and key personnel LinkedIn profiles, must be recorded and consolidated into the Contact Information section without omissions.Relevant search instructions from
references/search-strategies.md:508-515:text "{domain}" email format site:rocketreach.co "{company name}" site:zoominfo.com "{company name}" site:apollo.io "{company name}"Technical Analysis
The Skill requires broad aggregation of named personnel, roles, social profiles, telephone numbers, and email addresses. It also directs the Agent to infer a company's email-address convention so that addresses for other employees can be constructed or predicted.
Aggregating individually discoverable facts into a unified personnel-contact dataset materially increases their sensitivity and utility for targeting. Email-pattern inference is particularly problematic because a gene ...[truncated 2345 chars]
- Remediation
View remediation
Remediation Suggestions
- Remove email-format inference and prohibit constructing or guessing individual email addresses.
- Default to official company-level contact channels, such as a published switchboard, sales address, support address, or official contact form.
- Include named-person contact details only when they are necessary for a clearly stated, legitimate purpose and explicitly requested by the user.
- Replace the requirement to collect every discovered contact with a data-minimization rule that retains only information relevant to the due-diligence objective.
- Do not use contact-broker sources for personal contact details unless the workflow includes a lawful-purpose check, source-quality assessment, and explicit user confirmation.
- Clearly distinguish verified official contacts from third-party claims. Never present an inferred address as an existing or verified address.
- Add safeguards against requests for bulk employee lists, mass outreach, credential targeting, harassment, phishing preparation, or executive impersonation.
- Apply retention limits and avoid persisting personnel-contact datasets beyond the immediate task.
- Require source dates and independent verification for personnel information to reduce stale or mistaken attribution.
- Revise the report template so that key-person fields contain official professional profile links only by default, with personal telephone numbers and individual email addresses omitted.