T09 · Insecure Skill Coding Practices
- Location
SKILL.md:33- Finding
Persistent Storage of Credentials Is Explicitly Encouraged
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, line 33
Vulnerability Type: Sensitive credential retention in persistent memory
Risk Level: MediumVulnerable Code Snippet:
markdown - Use `importance >= 0.7` for architectural decisions, credentials, project goals, user preferences.Technical Analysis
The Skill explicitly identifies credentials as suitable content for persistent storage with an importance value of at least
0.7. According to the Skill's own description, higher-importance records are retained longer and weighted more heavily.Stored nodes can subsequently be exposed to Agent context through
cortex_search,cortex_recall, and the mandatory session-startcortex_briefingworkflow. The document does not prohibit storing passwords, API keys, access tokens, private keys, session cookies, or recovery codes. It also provides no requirements for secret redaction, encryption, access control, tenant isolation, consent, retention limits, or secure deletion.This is an insecure configuration and data-handling practice rather than evidence of deliberate exfiltration. No executable code, external endpoint, or malicious payload was identified in the audited project.
Attack Path
- A user, tool response, configuration file, or task context exposes a credential to the Agent.
- The Agent follows the Skill's guidance and submits the credential to
cortex_store. - The credential is assigned an importance value of at least
0.7, increasing its retention and retrieval weight. - The persistent memory retains the secret across sessions.
- A later
cortex_briefing,cortex_search, orcortex_recalloperation retrieves the stored credential into an Agent's active context. - The credential may then be disclosed in a response, exposed to a different task or user if isolation is inadequate, recorded in downstream logs, or misused by an actor with access to the memory system.
Imp
...[truncated 640 chars]
- Remediation
View remediation
Remediation Suggestions
- Replace the credential-storage instruction with an explicit prohibition against storing passwords, API keys, access tokens, private keys, session cookies, recovery codes, and other authentication secrets.
- Store only non-sensitive references or identifiers that point to secrets held in an approved secret manager.
- Implement secret detection and redaction before any content is passed to
cortex_store. - Reject storage when content matches known credential formats or contains high-entropy secret material.
- Encrypt persisted data in transit and at rest, with keys managed separately from the memory store.
- Enforce strict per-user, per-agent, and per-project access controls and isolation.
- Prevent briefings and broad semantic searches from returning sensitive fields.
- Apply short retention periods and low importance to sensitive non-secret information unless explicit user consent and a legitimate need exist.
- Provide auditable deletion and revocation workflows for mistakenly stored sensitive data.
- Document incident-response procedures requiring immediate deletion of an exposed secret and rotation or revocation of the original credential.
