Security: skill instructions can leak LANGFUSE_SECRET_KEY into agent context

[ishii1648]

Describe your idea or feedback

The skill contains three patterns that can cause LANGFUSE_SECRET_KEY to flow into the coding agent's context (and from there into LLM provider logs and persistent transcript files such as ~/.claude/projects/**/*.jsonl). They differ in scope, so I'll separate them:

1. Echoing the secret key (references/prompt-migration.md, lines 13-18)

echo $LANGFUSE_PUBLIC_KEY   # pk-...
echo $LANGFUSE_SECRET_KEY   # sk-...
echo $LANGFUSE_HOST         # https://cloud.langfuse.com or self-hosted

A compliant agent will run echo $LANGFUSE_SECRET_KEY and the value lands in its context and transcripts.

Scope: this file is loaded only when the agent is invoked specifically for the prompt-migration workflow — it is not loaded on every Langfuse interaction. So this concrete echo command is gated by that use case rather than always-on. Even so, the agent never needs to read the actual key value; an existence check is sufficient.

2. Asking the user to paste API keys into chat (SKILL.md, references/cli.md)

Both the entry-point SKILL.md and references/cli.md say:

If not set, ask the user for their API keys (found in Langfuse UI → Settings → API Keys).

This is loaded on every invocation of the skill. The natural user response is to paste the secret key directly into the chat, which produces the same end state as #1 (key in context + transcripts).

3. --curl preview in references/cli.md

references/cli.md recommends --curl to preview HTTP requests. If the CLI's --curl output emits the Authorization header, agents using this flag for debugging will surface the secret. I have not verified the actual CLI behavior — flagging for the maintainers' attention.

Why this matters

The Langfuse secret key grants full API access — read all traces, overwrite/delete prompts, mutate scores. Once it lands in an agent's transcript:

• It is sent to the LLM provider on every subsequent turn
• It persists in local session-log files long-term
• It can be exposed if the user shares debug transcripts (gist, Slack, blog post)

This is the CWE-532 / CWE-200 anti-pattern.

What would the ideal outcome look like?

1. prompt-migration.md prerequisites — replace value-printing with an existence check, e.g.:

   for v in LANGFUSE_PUBLIC_KEY LANGFUSE_SECRET_KEY LANGFUSE_HOST; do
     if [ -n "${!v}" ]; then echo "$v: set"; else echo "$v: missing"; fi
   done

2. SKILL.md / cli.md — reword "ask the user for their API keys" to instruct the agent to ask the user to set the env vars in their shell or .env file, rather than provide them in chat.

3. cli.md --curl — verify whether the output includes the Authorization header. If it does, either mask it in the CLI itself or add a warning discouraging agent use of --curl against authenticated endpoints.

These changes preserve the diagnostic value of the prerequisites while removing the leak surface entirely.

[ishii1648]

Note on the choice of channel: I considered filing this as an Issue (with a security / bug label) since it concerns credential exposure rather than a feature idea. I went with a Discussion in Ideas & Improvements because skills/langfuse/references/skill-feedback.md explicitly prescribes that flow (createDiscussion mutation + this category) for skill feedback.

Happy to convert this to an Issue or open a parallel Issue if maintainers prefer — please let me know what fits the repo's triage workflow best.

[Lotte-Verheyden]

Hi @ishii1648, thanks for flagging this. I updated the skill according to your first 2 points. For the third point: the CLI already truncates the Basic auth value so no change needed.
Appreciate the input!