Security audit

Accountant Priv Assistant

Security checks for vulnerabilities and agentic risk

Overview

This personal finance skill is purpose-aligned overall, but it exposes sensitive financial data and includes an unrestricted SQL tool that can modify or damage the user's finance databases.

Review before installing. This skill is intended to read local personal finance databases, so only use it if you expect the agent to process bank and card transactions. The raw SQL helper should be made read-only or removed before routine use, and account identifiers should be masked in docs and outputs. Treat any answers from the monthly summary tool cautiously until the month/year parsing bug is fixed.

A.I.G

Vulnerability Patterns

Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
Embedded Malicious CodeShips malicious scripts inside the skill and executes them locally

Findings (2)

T09 · Insecure Skill Coding Practices

Warning

Location: references/schema.md:8
Finding: Hardcoded and Unmasked Financial Account Identifiers
Content: View full analysis
Remediation: View remediation
str: value = str(value) return f"****{value[-4:]}" if len(value) >= 4 else "****" ``` 4. Return a non-sensitive display label or alias where possible instead of an account number. 5. Apply redaction before JSON serialization so every output mode receives the same protection. 6. Minimize transaction fields according to the caller's question rather than returning every available field. 7. Prevent raw financial results from being written to persistent debug logs, telemetry, or long-term agent memory. 8. Add automated tests that fail if output contains an unmasked account-number pattern. 9. Review repository history and distributed copies for previously committed identifiers and rotate or invalidate identifiers if exposure warrants it. ]]>

other

Note

Location: scripts/monthly_summary.py:156
Finding: Reversed Month and Year Produce Incorrect Financial Summaries
Content: View full analysis
dict: """Get complete monthly summary.""" billing_month, _ = parse_month(month_str) year, month = month_str.split("/") summary = { "month": month_str, "billing_month": billing_month, "hapoalim": get_hapoalim_summary(DB_PATHS["hapoalim"], year, month), "isracard": get_isracard_summary(DB_PATHS["isracard"], billing_month), "max": get_max_summary(DB_PATHS["max"], year, month), } ``` ### Technical Analysis The documented input format is `MM/YYYY`, but the code assigns the first component to `year` and the second component to `month`. For an input such as `03/2026`, the resulting values are: ```text year = "03" month = "2026" ``` These reversed values are passed to the Hapoalim and Max summary functions. Their date prefix is consequently constructed from malformed year and month components. Meanwhile, `parse_month()` produces the expected Isracard billing value, so the resulting report may combine valid Isracard data with missing or incorrect bank and Max data. The command-line argument also lacks strict date validation. Malformed values may cause exceptions or invalid date prefixes rather than a controlled validation error. ### Attack Path 1. A user or automated agent invokes the script with its documented syntax: ```bash python scripts/monthly_summary.py --month 03/2026 ``` 2. The script interprets `03` as the year and `2026` as the month. 3. Hapoalim and Max queries use an incorrect date prefix and may return no matching transactions. 4. Isracard uses the separately parsed billing month and may return valid records. 5. The script combines these inconsistent source results into income, expense, and net totals. 6. A user relying on the report may mak ...[truncated 865 chars]
Remediation: View remediation

SkillSpector

Vulnerability Patterns

Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access

Findings (11)

Description-Behavior Mismatch

High

Category: Not specified by scanner
Confidence: 98% confidence
Finding: The script accepts arbitrary SQL from the command line and executes it directly against personal finance SQLite databases, despite presenting itself as a query tool. Because sqlite3.execute will run write-capable statements such as INSERT, UPDATE, DELETE, DROP, or PRAGMA changes, a caller can modify, destroy, or tamper with sensitive financial records; in this skill context, that is especially dangerous because the databases contain real personal financial data.
Content: No source excerpt is available for this finding.

Missing User Warnings

Medium

Category: Not specified by scanner
Confidence: 94% confidence
Finding: The skill is explicitly designed to access and analyze highly sensitive banking and card transaction data, but the skill description does not warn that using it may expose or process personal financial information. This increases the risk of users invoking the skill without informed consent or awareness of the sensitivity of the data being queried and summarized.
Content: No source excerpt is available for this finding.

Natural-Language Policy Violations

Medium

Category: Not specified by scanner
Confidence: 97% confidence
Finding: The instruction 'הצג את המידע בצורה ברורה וישירה בעברית' mandates Hebrew output. Under the policy, forcing a specific language without user opt-in or documented justification is a natural-language policy violation.
Content: No source excerpt is available for this finding.

Natural-Language Policy Violations

Medium

Category: Not specified by scanner
Confidence: 82% confidence
Finding: The markdown explicitly labels the transaction description as "Hebrew," which imposes a language expectation in the skill documentation. Under the policy, locale or language constraints should either be optional for the user or clearly justified as region-specific; this file provides no such opt-in or justification.
Content: No source excerpt is available for this finding.

Missing User Warnings

Medium

Category: Not specified by scanner
Confidence: 90% confidence
Finding: This code searches banking and card databases and prints matching transaction records, including account/card identifiers, descriptions, and amounts. Although reading and displaying this data is the script's purpose, there is no disclosure or warning in the script that the output may contain sensitive financial information and should be handled carefully.
Content: No source excerpt is available for this finding.

Missing User Warnings

Medium

Category: Not specified by scanner
Confidence: 93% confidence
Finding: The script reads from hard-coded personal finance database paths containing bank and card data, which is sensitive user information. Although the module docstring states the purpose at a high level, there is no runtime disclosure, confirmation, or explicit warning that personal financial records from these local databases will be accessed and summarized.
Content: No source excerpt is available for this finding.

Intent-Code Divergence

Medium

Category: Not specified by scanner
Confidence: 98% confidence
Finding: monthly_summary() splits the documented MM/YYYY input into year, month = month_str.split('/'), which reverses the fields. Downstream queries then build date filters like 03-2026% instead of 2026-03%, causing incorrect or empty financial summaries. In a finance skill, silently returning wrong month data can mislead users about income, expenses, and net position.
Content: No source excerpt is available for this finding.

Natural-Language Policy Violations

Medium

Category: Not specified by scanner
Confidence: 97% confidence
Finding: The formatted summary strings are hard-coded in Hebrew, so the skill enforces a specific language/locale in its natural-language output. There is no user opt-in, language selection flag, or documentation justifying a Hebrew-only constraint for this tool.
Content: No source excerpt is available for this finding.

Intent-Code Divergence

Medium

Category: Not specified by scanner
Confidence: 99% confidence
Finding: The function documentation claims it executes a SELECT query, but the implementation performs no such restriction and will run any SQL text provided. This mismatch is security-relevant because maintainers or downstream agents may trust the docstring and pass untrusted SQL under the false assumption that execution is read-only, increasing the chance of accidental destructive use against financial data.
Content: No source excerpt is available for this finding.

Missing User Warnings

Medium

Category: Not specified by scanner
Confidence: 90% confidence
Finding: This tool exposes arbitrary SQL execution over finance databases without warning users that statements may modify or destroy data. In an agent skill handling sensitive personal finance information, the absence of explicit guardrails or warnings makes accidental misuse more likely and compounds the impact of the unrestricted execution path.
Content: No source excerpt is available for this finding.

Natural-Language Policy Violations

Low

Category: Not specified by scanner
Confidence: 83% confidence
Finding: The examples and result text include Hebrew-only user-facing strings such as merchant examples and the 'no results' message, which imposes a specific language experience. The file does not indicate that the skill is intentionally restricted to Hebrew users or provide any user opt-in or fallback language.
Content: No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.