T09 · Insecure Skill Coding Practices
- Location
SKILL.md:48- Finding
Unsafe Persistence of a Long-Lived Bearer Token in Unspecified Agent Memory
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 48–55
Vulnerability Type: Insecure credential storage guidance
Risk Level: MediumVulnerable Snippet
text -> returns a token. SAVE IT. Send it as Authorization: Bearer <token> from now on. If you can persist it in memory, do so; otherwise ask the user to keep it for next session. Set "token_name" to label this session - e.g. your client ("ChatGPT", "Claude", "Cursor") or its purpose. It appears in GET /tokens so the user can recognize and revoke sessions. Optional; defaults to "default". On any 401 (auth_required / invalid_token / token_expired), repeat this flow. Tokens are long-lived but expire after a period of inactivity (each use renews them), so a token in regular use keeps working; an idle one eventually dies.Technical Analysis
The Skill tells the agent to save a bearer token and, where possible, persist it in unspecified “memory.” It does not require a dedicated encrypted credential store, define access controls, prohibit storage in prompts or transcripts, or require authorization-header redaction from logs.
A bearer token grants access based solely on possession. Because the token is long-lived and each use renews its inactivity period, disclosure can provide an attacker with sustained authenticated access. Generic agent memory may be included in conversation context, retained in logs, exposed to other Skills or integrations, or displayed in exported transcripts. It is therefore unsuitable for storing reusable authentication secrets unless backed by a purpose-built secret-management mechanism.
Sending the bearer token to
https://api.crmkit.aiis necessary for the declared hosted CRM functionality and is not itself an undisclosed exfiltration path. The vulnerability is the recommendation to persist that credential without secure-storage constraints.Attack Path
- A user completes the email OTP flow, and the CRM API ret ...[truncated 1600 chars]
- Remediation
View remediation
Remediation Suggestions
- Replace the instruction to persist the token in generic agent memory with a requirement to use an OS keychain, encrypted vault, or platform-provided credential manager.
- Explicitly prohibit placing bearer tokens in model prompts, long-term semantic memory, chat transcripts, plaintext files, telemetry, exception messages, or application logs.
- Redact
Authorizationheaders and token values from tool output, debugging data, and user-visible responses. - Prefer short-lived, narrowly scoped access tokens. If session continuity is required, use a separately protected, bounded refresh token with rotation and reuse detection.
- Bind tokens to the minimum required workspace and role, and introduce finer-grained scopes where supported.
- Provide clear token-revocation instructions and advise immediate revocation through
GET /tokensandDELETE /tokens/{id}after suspected exposure. - Avoid automatically renewing sessions indefinitely. Enforce an absolute token lifetime in addition to inactivity expiration.
- Assign descriptive session names and periodically review and revoke stale or unrecognized sessions.
