Why this verdict
- suspicious: finding skill:logfire-sdk/logfire/.agents/skills/logfire-infrastructure:logfire-sdk/logfire/.agents/skills/logfire-infrastructure/SKILL.md:18:SUPPLY
- suspicious: finding skill:logfire-sdk/logfire/.agents/skills/logfire-infrastructure:logfire-sdk/logfire/.agents/skills/logfire-infrastructure/references/collector/host-and-infra-metrics.md:32:SUPPLY
Security findings 2
Supply chain
highContextual riskhigh confidenceThe collector reference instructs the agent to fetch credential-handoff instructions from a remote, unpinned pydantic.dev URL while handling the project-scoped Logfire write token, so the token-handling behavior the agent follows can change independently of the shipped artifact; the destination is the official vendor domain and the local advice (gitignored env file, no printing) is disclosed, so this is contingent risk, not an established exfiltration chain.
Follow its [credential handoff instructions](https://pydantic.dev/.well-known/agent-skills/logfire-instrumentation/references/auth.md
conceal:remotevector:instruction
Counter-argument considered
The quote is exact: the agent is told to follow unpinned remote instructions while placing the project-scoped write token, so token-handling behavior depends on mutable remote text; the fetch is overtly declared (undeclared gate fails) and the domain is the vendor's own, but neither declaration nor domain pins the followed content and no carve-out or mitigation neutralizes the dependency.
Supply chain
highContextual riskhigh confidenceThe skill's Step 1 instructs the agent to load and follow authentication and project-selection instructions from a mutable remote URL (pydantic.dev/.well-known/.../auth.md) rather than shipped content, so runtime behavior depends on unpinned remote text.
Use [Authenticate and Select the Exact Project](https://pydantic.dev/.well-known/agent-skills/logfire-instrumentation/references/auth.md) to derive the CLI target
conceal:remotevector:instruction
Counter-argument considered
The quote is exact: Step 1 makes the agent follow authentication and credential-handoff instructions fetched from an unpinned, mutable pydantic.dev URL, which is not a listed carve-out, so the supply-chain risk stands. The undeclared gate fails only because the fetch is overtly declared in the same unit, and open declaration does not pin the remote content.
Open questions 5
What the analysis could not settle from the code alone.
Whether the runtime content served at the mutable URL https://pydantic.dev/.well-known/agent-skills/logfire-instrumentation/references/auth.md matches any reviewed content and stays within authentication/credential handoff — this cannot be settled from the artifact shown.
Supply chain
What do the credential-handoff instructions at the remote URL https://pydantic.dev/.well-known/agent-skills/logfire-instrumentation/references/auth.md tell the agent to do with the Logfire write token, and can that remote content change independently of the shipped skill (the collector reference makes token handling depend on it)?
Supply chain
[file request logfire-sdk/logfire/.well-known/agent-skills/logfire-instrumentation/references/auth.md] Does the repository ship the auth.md document that SKILL.md Step 1 and the collector reference instruct the agent to load from https://pydantic.dev/.well-known/agent-skills/logfire-instrumentation/references/auth.md, and if so does it contain only authentication/project-selection and write-token handoff instructions without directives beyond that task?
Supply chain
[file request logfire-sdk/logfire/.agents/skills/logfire-instrumentation/references/auth.md] The infrastructure skill delegates Step 1 authentication and the write-token credential handoff to this auth reference (served remotely from pydantic.dev/.well-known/agent-skills/). Does this file issue instructions beyond authenticating — e.g. reading or writing credential files or env vars, network sends, persistence, or executing commands — and does its credential-handoff section keep the write token ⟦… 10 more chars …⟧
Supply chain
[file request logfire-sdk/logfire/.agents/skills/logfire-instrumentation/references/auth.md] Does this auth reference contain the credential-handoff instructions that the collector reference points to via the remote pydantic.dev URL, and do those instructions send the Logfire write token anywhere other than a gitignored env file, Kubernetes Secret, existing secret manager, or the Logfire exporter itself?
Credential access
Refuted findings 3
Candidates the review stage examined and rejected, kept for transparency.
Data exfiltration
criticalRefutedlow confidenceThe reference instructs configuring an OTel Collector hostmetrics receiver that scrapes host CPU, memory, load, disk, filesystem, network, and process metrics and exports them via OTLP/HTTP with a LOGFIRE_TOKEN Authorization header to the user-selected Logfire origin — a concrete host-telemetry-to-network chain that is, however, the skill's explicitly declared core capability with a disclosed destination and user-created token, so no harm beyond the declared purpose is established.
Use the `hostmetrics` receiver. Each host that ships these metrics appears on the
Why it was refuted
Scraping hostmetrics and exporting over OTLP/HTTP with a LOGFIRE_TOKEN header to the user-selected Logfire origin is exactly the skill's declared core capability, stated in the artifact itself with the destination and user-created project token disclosed, so the harm gate fails under the declared-core-capability carve-out and no exfiltration beyond the declared purpose is established.
Privilege escalation
highRefutedlow confidenceThe Docker monitoring section instructs mounting /var/run/docker.sock into the Collector container and running it as a user that can read it (often root, user 0:0), a configuration granting root-equivalent host access; this is the documented standard way to scrape docker_stats and the skill itself directs the agent to warn the user about it, so the capability is real but no abuse is shown.
mount `/var/run/docker.sock` into the container and run it as a user that can
Why it was refuted
Mounting /var/run/docker.sock and running as 0:0 is the standard, overtly disclosed mechanism for the skill's declared core capability (shipping container metrics via docker_stats), and the text itself mandates warning the user that it is root-equivalent, so the declared-core-capability carve-out defeats the PRIVESC reading; no abuse beyond the declared purpose is instructed.
Privilege escalation
highRefutedlow confidenceThe collector reference instructs mounting the Docker daemon socket (/var/run/docker.sock) into the Collector container and running it as a root-compatible user (user: 0:0) for the docker_stats receiver, a setup the text itself notes grants effectively root-level control of the host.
mount `/var/run/docker.sock` into the container and run it as a user that can
Why it was refuted
Same unit as the prior finding: the socket mount with a root-compatible user is the overt, standard configuration for the declared capability of monitoring Docker containers via docker_stats, and the text mandates disclosing the root-equivalent risk to the user first, so the declared-core-capability carve-out neutralizes the privesc claim.
