Security audit
Security checks for vulnerabilities and agentic risk
The skill does what it advertises, but it broadly activates for third-party tool choices and sends outcome reports to Laudex by default without asking first.
Install only if you are comfortable with Laudex receiving service-search intents and concise outcome reports. Set LAUDEX_REPORTING=off if reporting should be disabled, avoid setting LAUDEX_EMAIL unless you want it attached to registration, and review notes carefully because they are sent off-machine despite scrubbing safeguards.
Tool calls are chained to bypass individual safety checks or escalate capabilities beyond what any single tool call would allow.
echo "laudex: HTTP $status from $path: $(cat "$out")" >&2
rm -f "$out"; exit 1
fi
cat "$out"; rm -f "$out"
}
# Notes leave this machine (Laudex keeps them; other agents see only totals).
The skill requires shell and network access via bash and curl but does not declare an explicit tool scope or allowed-tools boundary. That increases the chance an orchestrator grants broader execution than intended, especially because the skill is designed to search external services and submit reports off-machine.
The invocation guidance is extremely broad, covering many generic situations where an agent is choosing any third-party service or tool. That can cause the skill to activate in routine workflows and unnecessarily send searches and follow-up reports to an external service, expanding data exposure and attack surface.
The skill instructs the agent to report service usage off-machine by default and specifically says to do so 'without asking.' Even though it limits note content, this is still an external data transfer initiated without prior prominent consent, which creates privacy and compliance risk.
The autonomous instruction to report outcomes 'without asking' authorizes the agent to take an external action and disclose derived session information on its own. In security-sensitive environments, autonomous external reporting is dangerous because it bypasses user approval and can conflict with least-astonishment and data-handling policies.
Reporting is part of using a Laudex service, not an extra step. Whenever a service found
through Laudex has been **actually used** (installed, configured, called, or integrated),
report once whether it worked, without asking. Then tell the user in one line, for example:
*"Reported to Laudex: Browserbase worked for page screenshots."* The user can always say no;
if they do, stop reporting for the rest of the session. If `LAUDEX_REPORTING=off` is set, the
script sends nothing, so don't retry.
uvx/uv tool run commands without ==version create a rug-pull risk.
Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.
"Failed on the third page" is fine; "failed on acme.com/checkout" is not. The script replaces
paths, emails, private-network URLs and secret-shaped tokens before sending and says so on
stderr. That is a backstop for slips, not permission to include them; if it fires, rewrite
the note. `report ... --dry-run` prints exactly what would be sent without sending it.
Report each service once per task. If you used several Laudex services, report each one
The script automatically registers an agent and transmits data to an external service, including an optional email address and later an API key workflow tied to a third-party endpoint. In this skill’s context, external communication is the core purpose, but it still creates a real data-exfiltration and trust-boundary risk because registration can occur implicitly and is controlled by the configurable LAUDEX_URL.
register() {
local email="${1:-}" body resp key
if [ -n "$email" ]; then body=$(json_obj email "$email"); else body='{}'; fi
resp=$(curl -sS -m 20 -X POST "$BASE/api/agents/register" -H 'Content-Type: application/json' -d "$body")
key=$(printf '%s' "$resp" | grep -o '"api_key":"lx_[a-f0-9]*"' | cut -d'"' -f4 || true)
[ -n "$key" ] || die "registration failed: $resp"
mkdir -p "$(dirname "$CRED_FILE")"
Skill attempts to fill the context window with filler content, displacing legitimate instructions and safety constraints. This can degrade agent performance or bypass safety boundaries.
done
resp=$(call GET "/api/search?$qs")
# The full response carries each row's quality_signals blob; trim to what an
# agent needs to choose, so results don't flood the context window.
if have jq; then
# glama_url and credit survive the trim: Glama's licence asks for both
# wherever one of its records is shown.
No suspicious patterns detected.