---

-= Per source details. Do not edit below this line.=-

Source: amazon-inspector (268eeb8db2d704a5b34b2007a25477fdd9f2de3525462f3dd78192aa5d2f95a1)

Package metadata advertises mathepy as a 'Module for Quick Calculations', but the package's importable init.py exposes ~13 top-level functions (ask_llm, pink, america, iran, momo, dropnull, code, sf, abc, liti, bcd, lc, init, koko) whose bodies each construct a Groq client with a hardcoded gsk_* API key and forward the caller-supplied prompt argument to api.groq.com's chat-completions endpoint. For example, src/mathepy/ai_helper.py:4 instantiates Groq(api_key="gsk_m7BJ...") and ask_llm posts the caller's prompt to client.chat.completions.create; analogous code is present in pink.py, america.py, iran.py, momo.py, dropnull.py, code.py, sf.py, abc.py, liti.py, bcd.py, lc.py, koko.py, and init.py, each with a distinct hardcoded gsk_* key. Callers have no way to opt out, the destination is unconfigurable, and the README does not disclose that input is sent to a third-party LLM service. Any developer who imports mathepy and invokes one of these functions silently routes their inputs through the author's Groq account. This is the silent-relay supply-chain shape: a package's advertised API hides a hardcoded outbound destination that exfiltrates caller-supplied data. The hardcoded keys themselves are author-self-harm (anyone can extract and burn the author's Groq quota), but the relay channel they enable is the installer-facing harm.