T09 · Insecure Skill Coding Practices
- Location
SKILL.md:165- Finding
Bearer Token Persisted Without Mandatory Security Controls
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This chess skill is transparent about its game API use, but it requires persistent token storage and unattended background polling that users should review before installing.
Install only if you are comfortable with an agent storing game bearer tokens and polling the external chess service in the background. Prefer using a secure credential store, deleting tokens when a game ends, avoiding logs or ordinary memory for tokens, and requiring explicit user approval before unattended heartbeat play.
SKILL.md:165Bearer Token Persisted Without Mandatory Security Controls
HEARTBEAT.md:46Heartbeat Instructions Permit Bearer Token Storage in a Generic File or Database
The skill explicitly instructs the agent to persistently store agentToken values and to automatically use them for authenticated network calls, but it provides no safeguards around secret handling, storage protection, rotation, minimization, or user consent. In an agent ecosystem, long-lived tokens in persistent memory increase the chance of credential leakage, replay, or cross-task misuse if memory is exposed or another skill can access it.
The file includes explicit instructions to transmit bearer tokens to an external service, which is expected for the chess integration but still constitutes external data transmission of sensitive credentials. While the destination appears aligned with the skill's purpose, the danger comes from normalizing outbound authenticated requests without any trust boundary explanation, domain validation guidance, or warning that tokens are being sent off-platform.
curl https://chessmaster.mrbean.dev/api/agents/game/YOUR_ROOM_ID \
-H "Authorization: Bearer YOUR_AGENT_TOKEN"
The instruction to operate without external human intervention authorizes autonomous decision-making and external actions after the initial trigger. In context this is game play rather than financial or system administration activity, so the danger is reduced, but it still creates a capability for unsupervised network actions and combines with the heartbeat/persistence instructions to extend activity beyond a single user request.
## Operational Guidelines
1. **Autonomously Execute Moves**: Once a game starts, operate without external human intervention.
2. **Handle Time Constraints**: Respond within the `timeLimit`. Game loss occurs if `lives` are exhausted.
3. **Stale Room Timeout**: If no move is made for **30 minutes**, the game will automatically end as a draw due to inactivity. Keep your heartbeat running!
4. **Respect Invitations**: Access games only via provided `roomId`; room listing is not supported.
The skill explicitly instructs the agent to store the agentToken and roomId in persistent memory or a database so it can reconnect later. Persisting reusable authentication material beyond the active session increases the chance of credential leakage, unintended reuse across contexts, or later access without fresh user approval; this is broader than what is necessary for a simple chess interface.
The documentation tells the agent to persist the authentication token but provides no warning about credential sensitivity, retention, or privacy implications. That omission normalizes unsafe credential handling and increases the risk that tokens are stored insecurely or retained longer than necessary.
The natural-language instruction to save authentication tokens for later reuse creates a direct credential retention risk. If the agent's memory, logs, or backing database are exposed, the token could let an attacker re-enter games, submit moves, or monitor game state without authorization from the user at the time of access.
The heartbeat section directs autonomous periodic execution and checking of active games without a user prompt. This expands the skill from a user-invoked chess interface into ongoing background behavior, which can bypass user awareness, trigger unrequested external actions, and create a standing channel for continued interaction with the remote service.
No suspicious patterns detected.