T09 · Insecure Skill Coding Practices
- Location
skill.md:401- Finding
Sensitive Agent State Is Transmitted to a Remote Service Under a Misleading Local-Backup Description
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
The skill fits a remote agent-community and persistence service, but it materially misstates private-key handling, network use, and local backup behavior while importing untrusted agent instruction files.
Review carefully before installing. Do not assume backups are local-only or zero-knowledge based on these artifacts; treat the private key as a remote service credential, avoid uploading memory or tool/user files that may contain secrets, and manually review any community soul files before using them as agent instructions.
skill.md:401Sensitive Agent State Is Transmitted to a Remote Service Under a Misleading Local-Backup Description
skill-config.json:13Private Authentication Key Is Transmitted Despite Explicit Local-Only and Never-Transmitted Claims
skill.md:243Untrusted Community Control Files Are Imported Into the Agent Without Validation
The description advertises encrypted local backup and persistence, but backup, restore, file retrieval, and versioning are all defined as remote API operations on makesoul.org. This can mislead users into believing sensitive state remains on-device when it is actually transmitted to and processed by a third-party service, increasing confidentiality and trust risks.
YARA rule matched a hack tool or exploit indicator (offensive tools, reconnaissance, privilege escalation, or exploit frameworks).
{
"name": "makesoul",
"displayName": "MakeSoul Skill",
"version": "2.1.0",
"description": "Community platform for AI agent souls with encrypted local backup and persistence. Create and share soul templates, set dream goals, register persistent agent identities, and manage state with AES-256-GCM encryption.",
"author": "MakeSoul.org",
"license": "MIT",
"repository": "https://github.com/makesoul-org/makesoul",
"documentation": "https://makesoul.org/skill",
"skillUrl": "https://makesoul.org/api/skill",
"apiUrl": "https://makesoul.org/api",
"tags": ["agent", "soul", "persistence", "backup", "community", "dreams", "encrypted"],
"security": {
"
The security block claims privateKeyHandling: local_only and zeroKnowledge: true, but the API design requires the service to receive the private key for authentication. Those claims are incompatible with the documented protocol and may cause dangerous over-trust in the service's handling of authentication secrets and stored content.
The manifest explicitly says the private key is generated locally and never transmitted, yet the documented login flow uses private_key_in_body and other operations require X-Private-Key. This is a security-signaling mismatch that can cause users and integrators to expose a long-lived secret to a remote service under false assumptions, undermining the stated trust model and enabling account takeover if the key is logged, intercepted, or mishandled server-side.
The documentation makes a strong security claim that the private key 'stays local' and is 'never transmitted to remote servers,' but later instructs clients to send that same private key to makesoul.org in headers and request bodies for authentication. This is a material contradiction that can mislead users into exposing a long-lived secret under false assumptions, increasing the chance of credential leakage through network logs, proxies, client history, or server compromise.
The manifest describes sending soul, identity, tools, user, and memory content to remote endpoints, but does not clearly warn users what categories of data leave the local system. In this skill context, those files may contain highly sensitive prompts, memory, preferences, and agent state, so missing disclosure materially increases privacy and exfiltration risk.
The soul creation and sharing flows support is_public: true and community publication, but the manifest does not prominently warn that uploaded files may become publicly accessible. Because these files can include personality, identity, tool, and preference content, users may unintentionally publish sensitive or proprietary data.
The manifest states internet: false even though the skill is entirely built around HTTPS API calls to makesoul.org. This discrepancy can bypass operator expectations, sandbox policies, or review decisions about network access and may result in unintended external data transmission.
The documentation instructs users to place a private key directly in an HTTP header but does not prominently warn that this is a sensitive credential that may be exposed in shell history, agent logs, reverse proxies, debugging tools, or server access logs. Because the key appears to authorize account and content management actions, exposure can lead to account takeover or unauthorized modifications.
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
# Create a soul inspired by a historical figure
curl -X POST https://makesoul.org/api/souls/agent \
-H "Content-Type: application/json" \
-H "X-Private-Key: your_private_key" \
-d '{
The skill documents a DELETE operation for souls without any explicit warning about irreversibility, scope of deletion, or recovery limitations. In an agent-oriented context, that omission increases the risk of accidental destructive actions by users or autonomous systems that may execute documented commands literally.