T06 · System Persistence
- Location
SKILL.md:53- Finding
Persistent Settlement Reminder Can Disclose Financial Position Data to an External Recipient
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This skill is a real-money Kalshi trading agent with live auto-betting, persistent reminders, and external messaging instructions that need review before use.
Install only if you intentionally want an agent that can use Kalshi credentials and place real-money trades. Keep it read-only or demo unless you add explicit trade confirmation, remove or tightly scope cron/Telegram reminders, verify any recipient yourself, and do not rely on the local risk_state.json limits as a complete spending control.
SKILL.md:53Persistent Settlement Reminder Can Disclose Financial Position Data to an External Recipient
scripts/kalshi_agent.py:91Non-Atomic Local Risk State Allows Concurrent Live Orders to Bypass Exposure Limits
The declared description presents a broad end-to-end trading/monitoring skill across two platforms. The supplied code chunk implements only an analysis engine that consumes already-provided market data and returns heuristic scores and recommendations. There are no API calls, no SDK usage, no account/portfolio access, no order placement, no settlement logic, and no proactive or time-based monitoring. This is a material description-behavior mismatch because the implemented capability is only a subset of the declared functionality, and one declared platform (Polymarket) is not represented at all.
The code substantially matches part of the description around Kalshi monitoring, market scanning, positions, portfolio/risk summary, and placing bets. However, the declared purpose overstates capabilities in several material ways. Most importantly, there is no Polymarket functionality at all—only a KalshiClient is used with Kalshi credentials and Kalshi market/order endpoints. The description also mentions checking settlement status, but this code only retrieves recent fills and open positions; no settlement lookup or resolution-status handling is present. Finally, the description says it should be used proactively when a bet is approaching settlement time, yet this code is purely a command-line tool invoked via flags and contains no timer, watcher, or trigger mechanism. These are material description-to-behavior mismatches rather than minor implementation details.
The code is clearly focused on Kalshi only: it provides authenticated REST methods for Kalshi portfolio, markets, events, and order management. That aligns with part of the description around checking positions and placing/canceling orders on Kalshi. However, the declared purpose materially overstates the implementation. There is no Polymarket integration at all, no analysis logic for identifying value bets, no proactive trigger/scheduling behavior for approaching settlements, and no dedicated settlement-status functionality beyond generic market/event retrieval. Therefore the description does not accurately represent the supplied code chunk.
There is a clear description-behavior mismatch. The declared purpose describes a broad cross-platform trading/monitoring skill for Kalshi and Polymarket, including exchange interaction and proactive settlement awareness. This code is much narrower: it is an internal support module for risk controls and bookkeeping, specific to a Kalshi agent, using only local file-based state. While bet sizing and position tracking are related to trading, they are supporting implementation details rather than the declared end-user capabilities. The primary purpose of the code chunk is risk management, not market monitoring or trading across the named platforms.
The skill describes live trading, order placement, and portfolio actions involving real-money prediction markets but does not prominently warn about financial risk or require explicit confirmation before execution. In this context, users could unintentionally authorize actual trades, creating immediate monetary loss and regulatory/compliance concerns.
The --run path invokes cmd_scan(..., auto_bet=True) in LIVE mode and can place real orders immediately based only on model-driven ranking logic, with no interactive confirmation, dry-run default, or secondary approval barrier. In a trading skill, this is especially dangerous because accidental invocation, automation misuse, prompt/agent chaining mistakes, or flawed market scoring can directly cause irreversible financial loss on a real-money account.
The skill invokes local scripts, references workspace config and key files, and calls external APIs, but it declares no explicit tool/permission scope. That creates an authorization gap where an agent may use file, environment, and network capabilities more broadly than users expect, increasing the chance of unintended credential access or outbound actions.
The phrase instructing proactive use when a bet is approaching settlement time authorizes agent action without a clear contemporaneous user request. In a trading context, broad autonomous activation is risky because it can trigger analysis, messaging, or even trade-adjacent actions at sensitive times based on stale intent or ambiguous context.
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
# Kalshi API Reference
Base URL: `https://api.elections.kalshi.com/trade-api/v2`
Auth: RSA-PSS signed headers on every request:
- `KALSHI-ACCESS-KEY`: key ID
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
# Kalshi API Reference
Base URL: `https://api.elections.kalshi.com/trade-api/v2`
Auth: RSA-PSS signed headers on every request:
- `KALSHI-ACCESS-KEY`: key ID
The file documents live order placement and cancellation endpoints for a real-money prediction market without any safety guidance, confirmation requirements, or warnings about financial/account impact. In the context of an agent skill explicitly intended to monitor and trade on Kalshi and Polymarket, this omission increases the chance that an automated agent could execute trades or cancellations without adequately informing the user or requiring explicit consent.
The function emits actionable bet recommendations without any built-in risk disclosure, suitability check, or prompt for user confirmation. In a trading skill context, this increases the chance that users treat heuristic output as trustworthy financial advice and place real-money bets without understanding uncertainty, liquidity, or loss exposure.
The formatted report prominently presents 'Bet YES/NO @ X¢' instructions but omits visible cautionary language or disclosure that the analysis is speculative and may be wrong. Because this skill is designed for prediction-market monitoring and trading, the presentation style can materially encourage unsafe financial action by making recommendations appear authoritative.
The module docstring and report output explicitly describe this as a 'Market analysis engine for Kalshi agent' and a 'KALSHI MARKET ANALYSIS REPORT', while the manifest says the skill monitors, analyzes, and trades on both Kalshi and Polymarket. The implementation also assumes Kalshi-shaped fields such as 'series_ticker' and specific bid/ask naming, so this file's actual behavior is narrower than the advertised cross-platform scope.
No suspicious patterns detected.