GST + UPI Reconciliation Copilot (India)

• Outcome: Review
• Latest audit: Sep 11, 2026 · 3:38 PM UTC
• Version: 1.0.0

Overview

This GST-UPI reconciliation skill matches its stated purpose, but it has concrete report-safety and reconciliation-integrity issues that users should review before relying on it.

Use this only with trusted GST and UPI exports, write outputs to a private dedicated folder, and treat the generated reports as sensitive financial records. Before using the reports for books, collections, or audit decisions, sanitize CSV outputs for spreadsheet formulas and validate missing statuses plus duplicate or blank invoice numbers.

A.I.G

Vulnerability Patterns

• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review
• Embedded Malicious Code: Ships malicious scripts inside the skill and executes them locally

Findings (3)

T09 · Insecure Skill Coding Practices

Error

• Location: scripts/reconcile_gst_upi.py:220
• Finding: Spreadsheet Formula Injection in Generated CSV Reports<![CDATA[ ## Vulnerability Details **File Location**: `scripts/reconcile_gst_upi.py`, lines 220-257 **Vulnerability Type**: CSV/spreadsheet formula injection **Risk Level**: High ### Vulnerable Code ```python with open(recon_csv, "w", encoding="utf-8", newline="") as f: fields = [ "invoice_no", "invoice_date", "customer_name", "invoice_total", "upi_txn_date", "upi_amount", "upi_txn_id", "upi_utr", "match_score", "match_reason", "match_status", ] w = csv.DictWriter(f, fieldnames=fields) w.writeheader() for r in matched: w.writerow(r) with open(gst_csv, "w", encoding="utf-8", newline="") as f: fields = ["invoice_no", "invoice_date", "customer_name", "total_amount", "taxable_value", "gst_amount", "match_status"] w = csv.DictWriter(f, fieldnames=fields) w.writeheader() for g in unreconciled_gst: w.writerow( { "invoice_no": g.invoice_no, "invoice_date": g.invoice_date.isoformat() if g.invoice_date else "", "customer_name": g.customer, "total_amount": g.total_amount, "taxable_value": g.taxable_value, "gst_amount": g.gst_amount, "match_status": "GST_UNMATCHED", } ) with open(upi_csv, "w", encoding="utf-8", newline="") as f: fields = ["txn_date", "amount", "status", "txn_id", "utr", "payer", "note", "match_status"] w = csv.DictWriter(f, fieldnames=fields) w.writeheader() for u in unreconciled_upi: w.writerow( ``` ### Technical Analysis Values originating in untrusted GST and UPI input files—including invoice numbers, customer names, transaction identifiers, UTR values, payer names, and notes—are written directly to CSV output. The implementation does not neutralize strings beginning with spreadsheet formula indicators such as `=`, `+`, `-`, `@`, tab, or carriage ...[truncated 1925 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions Introduce a centralized CSV-cell sanitization function and apply it to every string originating from an input file before writing any report: ```python def sanitize_csv_cell(value): if value is None: return "" text = str(value) if text.startswith(("=", "+", "-", "@", "\t", "\r")): return "'" + text return text ``` Additional hardening measures: 1. Sanitize all string fields, including invoice numbers, customer names, transaction IDs, UTR values, payer names, notes, status values, and match reasons. 2. Apply sanitization at the final output boundary so newly added fields are less likely to bypass protection. 3. Document that generated files may contain untrusted financial-statement content. 4. Add regression tests for values beginning with `=`, `+`, `-`, `@`, tab, and carriage return. 5. If exact raw values must be preserved, generate a non-executable format such as JSON alongside a separately sanitized spreadsheet report. ]]>

T09 · Insecure Skill Coding Practices

Warning

• Location: scripts/reconcile_gst_upi.py:113
• Finding: Missing UPI Status Fails Open as a Successful Transaction<![CDATA[ ## Vulnerability Details **File Location**: `scripts/reconcile_gst_upi.py`, line 113 **Vulnerability Type**: Fail-open validation of transaction status **Risk Level**: Medium ### Vulnerable Code ```python def map_upi(rows: List[Dict[str, str]]) -> List[UpiRow]: out = [] for i, r in enumerate(rows): out.append( UpiRow( idx=i, txn_date=parse_date(r.get("txn_date") or r.get("date") or r.get("transaction_date") or ""), amount=parse_amount(r.get("amount") or r.get("txn_amount") or ""), status=normalize_str(r.get("status") or "success"), txn_id=(r.get("txn_id") or r.get("transaction_id") or "").strip(), utr=(r.get("utr") or r.get("rrn") or "").strip(), payer=(r.get("payer_name") or r.get("payer") or "").strip(), note=(r.get("note") or r.get("description") or r.get("remarks") or "").strip(), ) ) ``` ### Technical Analysis The documented input schema identifies transaction status as required, and the matching policy permits only success-like statuses. However, the implementation replaces a missing or empty status with `"success"`: ```python r.get("status") or "success" ``` This is a fail-open default. A malformed, incomplete, or manipulated transaction without a status can satisfy the successful-status check in `score_match()` and be matched when its amount and date align with an invoice. The script also does not validate the presence of required columns before mapping records. Consequently, a UPI export lacking the entire `status` column can cause every otherwise eligible transaction to be treated as successful. ### Attack Path 1. A UPI CSV is exported incorrectly or deliberately modified to omit the `status` column or leave selected status values empty. 2. The script maps each missing value to `"success"`. 3. An affected row has an amount equal to an invoice total and a date w ...[truncated 831 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions Use a fail-closed default and explicitly validate required input columns: ```python raw_status = r.get("status") status = normalize_str(raw_status or "") ``` Records with missing statuses should remain unmatched or be placed in a dedicated validation-error report. Recommended controls include: 1. Reject a UPI file if none of the supported status columns is present. 2. Treat blank or unknown statuses as non-successful. 3. Report the row number and validation reason for every invalid record. 4. Require an exact normalized status from the documented allowlist: `success`, `completed`, `captured`, or `paid`. 5. Add tests covering a missing status column, blank values, whitespace-only values, and unknown statuses. 6. Include invalid-row counts in the summary so users cannot overlook rejected records. ]]>

T09 · Insecure Skill Coding Practices

Warning

• Location: scripts/reconcile_gst_upi.py:190
• Finding: Duplicate or Empty Invoice Numbers Cause Unmatched GST Rows to Be Omitted<![CDATA[ ## Vulnerability Details **File Location**: `scripts/reconcile_gst_upi.py`, lines 190-191 **Vulnerability Type**: Incorrect reconciliation identity tracking **Risk Level**: Medium ### Vulnerable Code ```python matched_invoice_numbers = {m["invoice_no"] for m in matched} unreconciled_gst = [g for g in gst_rows if g.invoice_no not in matched_invoice_numbers] ``` ### Technical Analysis The reconciliation loop processes each GST row separately, but the implementation later determines whether a GST row was matched by comparing only its `invoice_no`. Invoice numbers are not validated as present or unique. If two or more GST rows have the same invoice number, matching one row places that invoice number in `matched_invoice_numbers`. Every other row with the same number is then excluded from `unreconciled_gst`, even if no UPI transaction was assigned to it. The same problem is more pronounced for blank identifiers: all GST rows with an empty invoice number share the same comparison key. Matching one blank-identifier row can remove every other blank-identifier row from the unmatched report. Because omitted rows are absent from both `matched` and `unreconciled_gst`, summary totals can also undercount the original GST input. ### Attack Path 1. A GST input contains duplicate invoice numbers or multiple blank invoice identifiers. 2. One of those rows finds an eligible UPI transaction and is added to the matched list. 3. The invoice number is inserted into `matched_invoice_numbers`. 4. All GST rows sharing that identifier are filtered out of the unmatched list, regardless of whether they were individually matched. 5. Generated reports and summary totals omit the affected records. 6. An auditor may incorrectly conclude that no additional unmatched invoices exist for that identifier. ### Impact Assessment This issue does not provide operating-system access or additional privileges. It compromises the completeness and integrity of reconciliation output. Pote ...[truncated 490 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions Track matched GST records by their unique internal row index instead of invoice number: ```python matched_gst_indices = set() for g in gst_rows: # Select a candidate. matched_gst_indices.add(g.idx) unreconciled_gst = [ g for g in gst_rows if g.idx not in matched_gst_indices ] ``` The matched result should retain the source GST index internally, even if that field is not exposed in the final user-facing report. Additional controls should include: 1. Validate that every invoice identifier is non-empty. 2. Detect and report duplicate invoice numbers before reconciliation. 3. Define whether duplicate identifiers are invalid or valid only with an additional unique key. 4. Preserve every input row in exactly one terminal category: matched, unmatched, or invalid. 5. Verify through an invariant that: `input GST rows = matched GST rows + unmatched GST rows + invalid GST rows`. 6. Add regression tests for duplicate invoice numbers, multiple empty identifiers, and duplicate rows with different totals. ]]>

SkillSpector

Vulnerability Patterns

• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
• MCP Least Privilege: Underdeclared Capability, Wildcard Permission, Missing Permission Declaration
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access

Findings (3)

Lp3

Medium

• Category: MCP Least Privilege
• Confidence: 89% confidence
• Finding: The skill instructs the agent to read input CSVs and generate multiple output files, but it does not declare any explicit tool scope or permissions boundary. This creates an authorization ambiguity where a host system may grant broader file read/write access than intended, increasing the risk of accidental access to unrelated financial data or overwriting files in sensitive locations.

Vague Triggers

Medium

• Confidence: 91% confidence
• Finding: The invocation description is broad enough to match generic accounting or cashflow-related requests, which can cause the skill to activate in contexts beyond GST-UPI reconciliation. Over-broad activation is risky because it may prompt unnecessary handling of sensitive financial files or cause the wrong workflow to run on unrelated bookkeeping tasks.

Missing User Warnings

Medium

• Confidence: 93% confidence
• Finding: The script writes multiple CSV/JSON files containing sensitive financial and personal data such as invoice totals, customer names, payer names, UTRs, and transaction IDs. In an agent/skill context, creating these files without explicit user notice, output-location controls, masking, or data-minimization increases the risk of unintended local persistence, accidental sharing, or exposure through permissive directories and downstream tooling.

Static analysis

No suspicious patterns detected.