autoskill

MEDIUM W011: Third-party content exposure detected (indirect prompt injection risk).

• Third-party content exposure detected (medium risk: 0.30). In scripts/run.py → fetch_window() the agent reads text and window_title returned from the local screenpipe /search endpoint and then feeds the derived cluster/titles into the LLM via scripts/synthesize.py, so an outsider who can submit free text into screenpipe’s stored OCR/search results can poison the runtime prompt content.

HIGH W008: Secret detected in skill content (API keys, tokens, passwords).

• Secret detected (high risk: 1.00). I reviewed each automatically-detected potential match against the repository text and the secret definition/ignore rules.
• OPENAI_API_KEY: sk-abcdefghijklmnopqrstuvwxyz012345 — Flagged. This exact, high-entropy-looking literal appears verbatim in test code and in synthetic OCR payloads (tests/test_redact.py, tests/test_run.py, tests/test_e2e.py). Even though these are test fixtures / toxic-input examples, the string is a literal secret-shaped value (sk-... with long random-like suffix) and therefore meets the "API key / high-entropy literal" definition and should be treated as sensitive.
• PRIVATE_KEY: -----BEGIN OPENSSH PRIVATE KEY----- — Flagged. A PEM-style private key block appears verbatim in tests/test_redact.py (the multiline OPENSSH private key test fixture). PEM/private key blocks are explicitly included in the "Include" list and must be considered secrets.
• ANTHROPIC_API_KEY: sk-ant-xxxxxxxxxxxxxxxxxxxxxx — Ignored. This value contains an obvious redaction/placeholder pattern (x's) and is used in test cases as a placeholder for exercising redaction rules. Per the ignore rules for truncated/redacted or placeholder values, this is not treated as a real credential.

Notes:

• Many detections were duplicates of the same literal across tests; I reported representative locations where the actual secret-shaped literals occur.
• These flagged values are in test fixtures and tox/validation samples. If you know they are intentionally synthetic and not real live credentials, you can mark them as safe; otherwise treat them as secrets and remove/replace them from source (or move into test-time-only construction that avoids literal secrets in the repo).