Security audit
Security checks for vulnerabilities and agentic risk
HeteroMind has a coherent data-QA purpose, but its implementation gives generated queries and code too much power compared with the safety controls it claims to enforce.
Install only in an isolated environment with nonprivileged credentials, read-only database copies, trusted SPARQL endpoints, and non-sensitive table files. Do not rely on the documented sandbox/read-only claims until exec-based code execution, SQL validation, endpoint restrictions, and dependency pinning are fixed.
src/engines/table_qa/multi_stage_engine.py:892Unrestricted Execution of LLM-Generated Python Code
src/engines/nl2sql/base_engine.py:229Generated SQL Safety Validation Does Not Enforce Read-Only Queries
src/engines/nl2sparql/multi_stage_engine.py:739Caller-Controlled SPARQL Endpoint Permits Server-Side Request Forgery
requirements.txt:3Mutable and Unnecessary Third-Party Dependencies Create Supply-Chain Risk
Executing generated_code with exec is direct code injection risk because the input originates from a model that can be influenced by malicious prompts or poisoned context. In a heterogeneous QA skill with filesystem access, database connectivity, and external endpoints, successful injection could read secrets, pivot to network resources, or tamper with local analysis results.
}
exec(generated_code, safe_scope)
**SQL Execution:**
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
# Create .env file (NEVER commit to git)
cp .env.example .env
chmod 600 .env # Restrict permissions
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
# Create .env file (NEVER commit to git)
cp .env.example .env
chmod 600 .env # Restrict permissions
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
# Create .env file (NEVER commit to git)
cp .env.example .env
chmod 600 .env # Restrict permissions
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
# Create .env file (NEVER commit to git)
cp .env.example .env
chmod 600 .env # Restrict permissions
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
# Create .env file (NEVER commit to git)
cp .env.example .env
chmod 600 .env # Restrict permissions
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
# Create .env file (NEVER commit to git)
cp .env.example .env
chmod 600 .env # Restrict permissions
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
# Create .env file (NEVER commit to git)
cp .env.example .env
chmod 600 .env # Restrict permissions
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
# Create .env file (NEVER commit to git)
cp .env.example .env
chmod 600 .env # Restrict permissions
# Edit with your credentials
The documented command export $(cat .env | xargs) is unsafe because it can misparse values, expose secrets via shell history/process inspection, and execute unexpectedly if the file contents are not strictly controlled. In practice, users may copy this pattern into environments where .env content includes spaces, shell metacharacters, or untrusted modifications.
chmod 600 .env # Restrict permissions
# Edit with your credentials
nano .env
# Load environment
export $(cat .env | xargs)
The instruction to echo the API key for verification encourages displaying secrets directly in the terminal, screen recordings, shell scrollback, or session logs. This increases the risk of accidental disclosure of high-value credentials.
nano .env
# Load environment
export $(cat .env | xargs)
# Verify
echo $DEEPSEEK_API_KEY # Should show value
If the actual implementation is only a narrow schema-formatting utility rather than a full heterogeneous QA system, the mismatch can mislead users about what data will be accessed and what guarantees exist. Misrepresentation of capability is especially risky in agent skills because activation and approval may rely on the declared purpose rather than audited code.
If the actual implementation is only a narrow schema-formatting utility rather than a full heterogeneous QA system, the mismatch can mislead users about what data will be accessed and what guarantees exist. Misrepresentation of capability is especially risky in agent skills because activation and approval may rely on the declared purpose rather than audited code.
If the actual implementation is only a narrow schema-formatting utility rather than a full heterogeneous QA system, the mismatch can mislead users about what data will be accessed and what guarantees exist. Misrepresentation of capability is especially risky in agent skills because activation and approval may rely on the declared purpose rather than audited code.
If the actual implementation is only a narrow schema-formatting utility rather than a full heterogeneous QA system, the mismatch can mislead users about what data will be accessed and what guarantees exist. Misrepresentation of capability is especially risky in agent skills because activation and approval may rely on the declared purpose rather than audited code.
If the actual implementation is only a narrow schema-formatting utility rather than a full heterogeneous QA system, the mismatch can mislead users about what data will be accessed and what guarantees exist. Misrepresentation of capability is especially risky in agent skills because activation and approval may rely on the declared purpose rather than audited code.
If the actual implementation is only a narrow schema-formatting utility rather than a full heterogeneous QA system, the mismatch can mislead users about what data will be accessed and what guarantees exist. Misrepresentation of capability is especially risky in agent skills because activation and approval may rely on the declared purpose rather than audited code.
If the actual implementation is only a narrow schema-formatting utility rather than a full heterogeneous QA system, the mismatch can mislead users about what data will be accessed and what guarantees exist. Misrepresentation of capability is especially risky in agent skills because activation and approval may rely on the declared purpose rather than audited code.
If the actual implementation is only a narrow schema-formatting utility rather than a full heterogeneous QA system, the mismatch can mislead users about what data will be accessed and what guarantees exist. Misrepresentation of capability is especially risky in agent skills because activation and approval may rely on the declared purpose rather than audited code.
If the actual implementation is only a narrow schema-formatting utility rather than a full heterogeneous QA system, the mismatch can mislead users about what data will be accessed and what guarantees exist. Misrepresentation of capability is especially risky in agent skills because activation and approval may rely on the declared purpose rather than audited code.
If the actual implementation is only a narrow schema-formatting utility rather than a full heterogeneous QA system, the mismatch can mislead users about what data will be accessed and what guarantees exist. Misrepresentation of capability is especially risky in agent skills because activation and approval may rely on the declared purpose rather than audited code.
If the actual implementation is only a narrow schema-formatting utility rather than a full heterogeneous QA system, the mismatch can mislead users about what data will be accessed and what guarantees exist. Misrepresentation of capability is especially risky in agent skills because activation and approval may rely on the declared purpose rather than audited code.
The instruction export $(cat .env | xargs) is an unsafe pattern for loading secrets because it can mis-handle special characters, expose values in shell history/process context, and encourage casual plaintext secret handling. In shared or logged shell environments, this increases the likelihood of credential leakage.
cp .env.example .env
# Edit with your credentials
nano .env
# Load environment
export $(cat .env | xargs)
Package name closely resembles a popular package, suggesting possible typosquatting. Attackers publish malicious packages with similar names to trick developers into installing them.
Skill contains instructions that could directly expose system prompts, internal rules, or hidden instructions to users or external parties.
logger.debug(f"Rule-based detection: {source_scores}")
return RuleBasedScore(
source_scores=source_scores,
matched_keywords=matched_keywords,
matched_patterns=matched_patterns,
Detected: suspicious.exposed_secret_literal