Security audit
Security checks for vulnerabilities and agentic risk
This appears to be a legitimate molecule profiling skill, with the main caveat that one optional script can send submitted molecule strings to ADMETlab.
Before installing, decide whether your SMILES strings could reveal confidential research compounds. Use the local chain_entry.py/RDKit path for sensitive molecules, and only use scripts/admetlab3.py when you are comfortable sending the molecule string to ADMETlab. Treat the predictions as screening information, not clinical or regulatory conclusions.
The documented behavior exceeds the stated scope by including undeclared outbound API usage and toxicity prediction capabilities, while also claiming PAINS alerts that may not actually be implemented. This mismatch undermines user consent and trust boundaries, and in this domain can expose proprietary molecular structures or lead downstream systems to rely on outputs that are incomplete or misleading.
The skill advertises functionality that includes an external ADMETlab 3.0 API path, but the manifest/documentation does not declare any tool scope, permissions, or allowed network access. In a chemistry/pharmacology context, user-supplied SMILES strings may represent confidential research compounds, so undeclared outbound transmission creates a meaningful data leakage and governance risk.
The trigger list is broad enough that the skill may be invoked for general pharmacology or drug-related prompts beyond the user's specific intent. Because this skill may send molecular data to an external API and produce quasi-decision-support outputs, overbroad invocation increases the chance of unintended data exposure or unreviewed automated analysis.
The overview expands the skill from ADME/PK profiling into toxicity risk prediction without that scope being clearly declared in the manifest. Scope expansion is security-relevant because it changes how outputs may be used and can cause unintended invocation or inappropriate reliance on quasi-safety assessments.
The skill description does not warn users that molecule inputs may be transmitted to an external ADMETlab 3.0 service. In this context, SMILES strings often encode proprietary candidate compounds, so omission of that warning can lead to unconsented disclosure of valuable research data.
The documented admetlab3 script includes broader ADME and toxicity endpoints than the manifest declares, indicating capability drift. In regulated or IP-sensitive drug discovery workflows, undeclared analytical scope and externalized processing can cause misuse, compliance issues, and accidental disclosure of sensitive compound information.
The manifest lists a narrower set of supported outputs such as BBB permeability, aqueous solubility, GI absorption, CYP3A4 inhibition, P-gp substrate, plasma protein binding, PAINS alerts, and common drug-likeness metrics. In contrast, the endpoint map declares many additional capabilities not mentioned in the manifest, expanding the effective behavior and user-visible analysis surface beyond the stated description.
The manifest describes the skill as a pharmacology agent for ADME/PK profiling, drug-likeness, and specific listed ADME-style endpoints, but this file also implements a dedicated toxicity capability set including hERG, Ames, DILI, carcinogenicity, respiratory toxicity, and eye irritation categories. Toxicity assessment is broader than the manifest's stated ADME/PK profiling purpose and is additionally emphasized in the module docstring as ADME/Tox prediction.
The function sends user-supplied SMILES to a third-party service without any explicit user-facing consent, warning, or privacy control. In a pharmacology workflow, SMILES may represent confidential drug candidates or proprietary lead structures, so silent transmission can leak sensitive IP to an external operator and across network boundaries.
This code performs external transmission of the input molecule to a remote service via HTTPS POST. In the context of drug discovery and ADME/PK profiling, the transmitted structure itself can be highly sensitive intellectual property, making exfiltration to a third party materially risky even if the transport is encrypted.
try:
# ADMETlab 3.0 accepts SMILES via POST
payload = {"smiles": smiles}
resp = requests.post(
f"{ADMETLAB_URL}/alogps",
json=payload,
timeout=TIMEOUT,
The skill’s stated purpose is ADME/PK profiling of drug candidates from SMILES. Hard-coding ip-expansion as an always-recommended next step introduces a capability or workflow bias unrelated to pharmacology assessment itself, unlike recommending toxicology which is at least scientifically adjacent.
Earlier documentation defines the main entry point input as JSON containing a smiles field, and the manifest says the agent profiles candidates from SMILES while chaining from chemistry-query for SMILES input. The error-handling note claiming it requests 'smiles or name' contradicts that stated interface by implying direct name-based input support.
The docstring states that RDKit predictions are a fallback used when the API is unavailable. However, the implementation unconditionally computes RDKit-based results as a baseline or fallback, and attaches them even after successful ADMETlab responses.
The manifest describes this skill as performing ADME/PK and drug-likeness profiling from SMILES, but the code also recommends next-step routing to "ip-expansion" in both success and error paths. Suggesting intellectual-property expansion is not part of the declared pharmacology profiling behavior and broadens the skill's apparent function beyond what the manifest claims.