← Authorised OSINT ToolkitCONTENT HISTORYWHAT CHANGED · RULE-BASED ANALYSIS
Update to Authorised OSINT Toolkit
Snapshot Sep 30, 2026 · 23:15 UTC · version 1.1.0
Collection source: not recorded for this historical snapshot.
First saved snapshot
No earlier snapshot is available to establish a change.
Compare saved observations
Download comparison JSONFull technical diff · 0 changed fields
Full snapshot data
{
"name": "email-domain-security",
"description": "Analyse published DNS records to reach a defensible email-spoofability and SPF supply-chain verdict. Use for passive email-domain security reviews; do not send test mail, enumerate recipients or submit credentials.",
"included_files": [
{
"relative_path": "agents/openai.yaml",
"size_in_bytes": 284
},
{
"relative_path": "references/source-playbook.md",
"size_in_bytes": 44842
}
],
"skill_md_contents": "---\nname: email-domain-security\ndescription: \"Analyse published DNS records to reach a defensible email-spoofability and SPF supply-chain verdict. Use for passive email-domain security reviews; do not send test mail, enumerate recipients or submit credentials.\"\n---\n\n# Email Domain Security\n\n## Authorisation and safety\n\n- Confirm the target is owned by the user or covered by written authorisation before sending target-directed traffic, executing bundled recon scripts, validating credentials, enumerating users, scanning ports or scheduling recurring checks. Record the exact in-scope domains, IP ranges, methods, rate limits and engagement window.\n- Passive analysis of user-supplied data and public documentation may proceed without target interaction. Clearly label unverified attribution and do not convert discovered sibling assets into scan scope.\n- Do not exploit vulnerabilities, bypass access controls, submit or replay credentials, perform password spraying, induce state changes, evade detection, send phishing messages, access non-public data or use destructive probes.\n- Treat exposed secrets and personal data as sensitive. Minimise collection, redact reports, avoid unnecessary validation and follow the engagement's evidence-handling and disclosure rules.\n- Stop when authorisation is absent or ambiguous, a technique would exceed scope, rate limiting or defensive blocking appears, or an action could materially affect a system. Ask for a narrower safe action.\n\n## Workflow\n\n1. Establish whether the request is passive analysis or involves target interaction. For interaction, capture the scope and authority required above before proceeding.\n2. Read [references/source-playbook.md](references/source-playbook.md), searching within it for the topic relevant to the request. Load only the relevant sections into working context.\n3. Prefer passive and keyless sources first. Separate observed facts, attribution inferences, hypotheses and proposed validation.\n4. Use bundled scripts only when they directly support the authorised task. Inspect their prerequisites and resolved target/output paths before execution; do not install dependencies or run network operations implicitly.\n5. Preserve source URLs, timestamps, commands, hashes and confidence so another analyst can reproduce the result. Redact secrets and unnecessary personal data from deliverables.\n6. Report scope, method, evidence, confidence, limitations, findings and proportionate next actions. Never represent a candidate asset, guessed identity, exposure or exploitability as proven without supporting evidence.\n\n## Source and licence\n\nThis adaptation preserves methodology from Sachin Sharma's `elementalsouls/Claude-OSINT`, pinned at commit `13d920413448c026b52ac74efee0f1eb39dd81ff`. See the package-level `ATTRIBUTION.md`, `LICENSE`, and `LICENSE-CONTENT`.\n"
}SHA-256: a1cc661d0bc32f5195fa4d7927ee888e1239114615af53f2c6ee98e12f23a84e