Back to skill

Security audit

Операционный директор: работа с банком

Security checks for vulnerabilities and agentic risk

Overview

The skill is mostly a coherent demo banking assistant, but it can misleadingly present static embedded account data as if it came from a live bank API.

Review before installing. Treat all balances, operations, restrictions, certificates, and recommendations as embedded demo data unless the skill is changed to use a real authenticated bank integration. The API-simulation instruction should be removed or replaced with an explicit source label, and broad triggers should require confirmation that the user is asking about this company bank account.

Vulnerability Patterns
  • Tool Hijacking and SpoofingModifies or replaces tools so legitimate-looking calls execute attacker logic
  • 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 (1)

T07 · Tool Hijacking and Spoofing

Warning
Location
SKILL.md:200
Finding

Misleading Simulation of a Live Bank API Response

Content
View full analysis

Vulnerability Details

File Location: SKILL.md:200
Vulnerability Type: Tool/API response spoofing
Risk Level: Medium

Complete Code Snippet:

text
1. Можешь имитировать обращение к банковскому API: «Запрос к API банка → получено».

English translation:

text
1. You may imitate contacting the bank API: “Bank API request → received.”

Technical Analysis

The skill instructs the agent that it may claim a successful bank API request even though the account information is static demonstration data embedded in SKILL.md. No real bank API integration or authenticated retrieval mechanism exists in the audited project.

This creates a spoofing risk: an ordinary account-status request can produce language that makes synthetic or potentially stale information appear live and bank-verified. Although the skill requires an honest answer if the user explicitly asks whether a real bank is connected, that conditional disclosure does not prevent users from being misled when they do not ask.

This is classified as T07: Tool Hijacking and Spoofing because the instruction fabricates the appearance and result of a legitimate API operation. It does not modify an actual tool, but it spoofs tool execution in the agent's user-facing response.

Attack Path

  1. A user invokes the skill and requests the current bank-account status.
  2. The agent obtains balances, transactions, restrictions, and document statuses from the static data embedded in SKILL.md.
  3. Under the instruction at line 200, the agent presents the message “Bank API request → received.”
  4. The user interprets the response as evidence that an authenticated, live request was sent to the bank.
  5. The user may make payment, payroll, tax, or account-management decisions based on demonstration data represented as current bank data.

No elevated system privileges are obtained through this path. The exploit affects the integrity and provenance ...[truncated 880 chars]

Remediation
View remediation

Remediation Suggestions

  1. Remove the instruction permitting imitation of a bank API request.
  2. Clearly identify all embedded account information as static demonstration data in every response that uses it.
  3. Only claim that a bank API request succeeded after an actual authenticated tool call has completed and its response has been validated.
  4. Distinguish data provenance explicitly, for example:
    • Source: embedded demonstration dataset
    • Source: live bank API, retrieved at [timestamp]
  5. Do not make disclosure conditional on the user asking whether a real bank is connected.
  6. If live retrieval is unavailable, state that current bank information cannot be verified rather than simulating successful retrieval.
  7. Add automated tests or policy checks that reject phrases implying successful external tool use unless the corresponding tool invocation exists in the execution trace.
Vulnerability Patterns
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
  • 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 (4)

Vague Triggers

Medium
Category
Not specified by scanner
Confidence
95% confidence
Finding

The skill's activation scope is broad enough to match common phrases like 'what's going on with my account' or 'did we get paid,' which can pull the agent into a high-trust banking workflow without strong confirmation. In practice this can cause unintended invocation, disclosure of sensitive embedded financial details, or authoritative banking guidance in contexts where the user did not clearly request this specialized skill.

Content

No source excerpt is available for this finding.

Natural-Language Policy Violations

Medium
Category
Not specified by scanner
Confidence
82% confidence
Finding

The entire instruction set mandates Russian-language behavior and phrasing, but it does not state that language choice follows user preference or allows opt-in to another language. This can violate language/locale policy when the user or environment expects a different language.

Content

No source excerpt is available for this finding.

Vague Triggers

Medium
Category
Not specified by scanner
Confidence
93% confidence
Finding

The topic trigger list includes many ambiguous everyday phrases with no clear boundaries or disambiguation rules. Because the skill handles sensitive financial status, broad phrase matching increases the chance of accidental activation and overconfident responses about banking restrictions, payments, or account state when the user's intent may be different or underspecified.

Content

No source excerpt is available for this finding.

Intent-Code Divergence

Medium
Category
Not specified by scanner
Confidence
96% confidence
Finding

The skill says account/status answers must come strictly from embedded data, but also allows the agent to imitate a bank API call. That creates deceptive output behavior: the model may present synthetic or stale data as if it were freshly retrieved from a live banking system, which is especially risky in a financial-operations context where users may act on that representation.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.