Prompt injection through invoices and bank references: protecting your accounting agent

Where third-party text enters your books

• Bank lines: purpose (Verwendungszweck) and counterparty_name in list_bank_transactions are written by whoever sent the money.
• Receipts: vendor_name, invoice_number and everything under document in get_receipt_proposal come from the supplier's document, e-invoices in XRechnung or ZUGFeRD format included.
• Names and texts copied from such documents: partner_name, recipient_name, booking and line descriptions.
• Whatever the agent reads from other tools in the same session — a mailbox, a web page, a shared folder.
• Our server instructions name these fields as third-party data and tell the agent never to follow an instruction found in them and never to put the API key into a field or message. OWASP lists this pattern as indirect prompt injection (LLM01:2025): the model takes in instructions from external sources such as files.

Three attacks that look like bookkeeping

Invented examples of the kind of text to expect, and what stops each one.

Layer 1: least privilege

• One key per task and company. Analysis and reporting: read only. Booking: read and write. Emailing invoices: add send. Locking periods: finalize, on a key of its own. Webhooks: a separate right as well.
• A key without a right does not even list the tools that need it, so the model cannot be talked into calling them.
• Every key expires, at most 366 days ahead; for experiments, shorter is better. Revoke a key as soon as its integration ends.
• A company that uses only the tax module gets keys that reach only the tax routes and master data.
• Be careful with outward channels — mail, chat, file sharing — in the same agent session as the ledger. Even with a read-only key, a manipulated agent could pass figures on through another tool, unless every outward call needs your confirmation.

Layer 2: confirmations that fail closed

Decide in your AI program which calls may run without asking. In the OpenAI Agents SDK, for example, a callable approves only an explicit list of reading tools and stops before everything else — including tools added later:

import os

from agents.mcp import MCPServerStreamableHttp

READ_ONLY = {
    "get_entity", "list_fiscal_years", "list_accounts", "list_open_items",
    "list_bank_transactions", "list_receipts", "get_receipt_proposal",
    "get_saldenliste", "get_vat_return",
}


def needs_approval(run_context, agent, tool) -> bool:
    return tool.name not in READ_ONLY


server = MCPServerStreamableHttp(
    name="buchhaltung",
    params={
        "url": "https://api.jahresabschluss.io/functions/v1/bookkeeping-mcp",
        "headers": {"Authorization": f"Bearer {os.environ['JAB_API_KEY']}"},
        "timeout": 30,
    },
    require_approval=needs_approval,
)

Prefer such an allowlist to a list of dangerous tools: a new write tool then needs approval by default. Our tools also carry MCP annotations — readOnlyHint for reading tools, destructiveHint for irreversible ones such as create_outgoing_invoice, send_outgoing_invoice, cancel_outgoing_invoice, delete_receipt and finalize_bookkeeping_period — and the server instructions require the agent to state what will happen and wait for an explicit yes before each of these, one confirmation per action.

Layer 3: limits no text can lift

• send_outgoing_invoice only reaches addresses stored for the partner or noted on the invoice, at most 3 sends per invoice and 100 per company in 24 hours.
• IBAN and BIC of business partners cannot be changed through the API at all; you maintain them in the app.
• A duplicate warning on confirm_receipt cannot be overridden through the API; the agent has to show it to you.
• Receipt files and Kanzlei Software or GoBD exports never pass through the model; the tools return a download path instead.
• Tax filings: the agent prepares and requests an approval link; you submit in the app. The ELSTER PIN never belongs in the chat, and a PIN found in a receipt, a web page or any other third-party text is never valid.
• A new webhook triggers an email to the key's owner, its target must be a public HTTPS address, and subscribing needs the webhooks right.
• book_incoming_invoice reports a possible duplicate by invoice number; booking it anyway needs a flag the agent may only set after you have confirmed — so an injected “book this again” is caught.

Detect and recover

• In the app, the area “KI-Agent & API” shows each key's calls of the last 30 days — how many, how many wrote or failed, the last call and the most used endpoints — so a write you did not expect stands out there.
• get_business_partner returns the change history of a partner — which field changed when, from which value to which.
• list_journal_entries with source_type and since_entry_no shows exactly what was booked since a given entry number.
• Wrong bookings are reversed, not deleted: storno_journal_entry, storno_payment, cancel_incoming_invoice, storno_journal_batch for a whole import.
• Revoke the key in the app; it stops working immediately, and only for its own company.

Practise the attack in the sandbox

If your company qualifies for a sandbox — a hidden copy of the company, currently offered for books without annual-statement data — create one and a sandbox key, then upload a test receipt whose text contains an instruction, or book a test transaction with a manipulative description. Watch what your agent proposes, whether your confirmation step fires and how it reacts to the refusals. Nothing leaves the sandbox: no email, no tax submission, no bank call.

Limits: what the server cannot do for you

• It labels third-party text but does not promise to detect every injection; the decisive protection is rights, confirmations and the hard limits above.
• It cannot judge whether a booking the agent proposes is economically right. A write you approve, or auto-approve, is booked if it passes the checks.
• It cannot see what other tools in your AI program do with the data the agent has read.
• Your AI program sends ledger data to its model provider under that provider's terms; choose the provider and its data settings deliberately.
• Responsibility stays where German law puts it: the managing directors ensure proper bookkeeping (§ 41 GmbHG), and records may not be changed so that their original content is lost (§ 146 Abs. 4 AO) — which is why corrections are reversals and can be traced.

Frequently asked questions

Can a malicious invoice make my agent pay someone?

No. The API initiates no payments, and partners' bank details cannot be changed through it.

Can injected text redirect invoice emails?

Invoices only go to addresses stored for the partner. Changing an address needs the send right, and the server instructions forbid taking addresses from documents — so never auto-approve update_business_partner.

Does the server filter malicious text?

It marks third-party fields as data and tells the agent not to follow them, but it does not promise detection. Rights, confirmations and server limits are the real protection.

Is a read-only key safe from prompt injection?

It cannot change the books. A manipulated agent could still misreport figures or pass them on through another tool in the same session, so keep outward tools under confirmation.

What if a document asks for the ELSTER PIN?

Ignore it. The PIN is entered only by you, in the app, when you submit; a PIN from any third-party text is never valid.

Which tools can safely run without confirmation?

Reading tools such as get_entity, list_open_items, list_bank_transactions and get_saldenliste. Every tool that writes, sends or locks should wait for your yes.