SOX compliance and AI security — prompt injection in financial document processing

SOX controls implicated by AI financial document processing

The Sarbanes-Oxley Act was written in 2002, fifteen years before large language models could read an invoice image. The statute's control framework, however, is technology-neutral by design. Sections 302 and 404 apply to any IT system that contributes to the accuracy of financial statements — and that definition now includes AI models that extract amounts, categories, and terms from financial documents.

Section 302 — CEO and CFO certifications

Under Section 302, principal executive and financial officers must personally certify with each quarterly and annual filing that: (a) the financial statements do not contain material misstatements, and (b) they have evaluated the effectiveness of disclosure controls and internal controls over financial reporting and reported their conclusions. The certification is not delegable and carries personal liability under 18 U.S.C. § 1350 for knowing falsification.

The SOX Section 302 risk from AI financial document processing is direct. If an accounts payable AI model processes a supplier invoice image that has been adversarially crafted to instruct the model to extract an inflated invoice amount, the wrong vendor identifier, or a falsified GL code — and that manipulated data flows into the ERP and is incorporated into a financial statement — then the financial statement contains a misstatement that the CEO and CFO certified did not exist. The causal chain from adversarial pixel to signed certification runs through the AI model's failure to detect the embedded instruction. That failure is an input validation gap in an ICFR system.

Section 404 — ICFR effectiveness assessment

Section 404 requires management to annually assess the effectiveness of ICFR and attach that assessment to the annual report. For companies with a market cap above the non-accelerated filer threshold, the external auditor issues an independent attestation on management's ICFR assessment. The PCAOB's Auditing Standard No. 2201 governs that attestation and requires the external auditor to test the IT components of ICFR — the systems and applications that support financial reporting processes.

An AI model that processes financial document images is an IT component of ICFR if its outputs flow into the financial reporting pipeline. External auditors testing that IT component will examine the same categories of control they examine for any other financial reporting application: access controls (who can submit images for processing), input validation controls (what prevents malformed or adversarial inputs from corrupting the extracted data), and the audit trail (what evidence exists that the control operated effectively during the period). A multimodal prompt injection scanner positioned at the inference boundary — before the image reaches the vision model — is the input validation control for this class of IT component. Its absence is a Section 404 gap.

IT General Controls (ITGCs) for AI image processing

SOX auditors test IT General Controls that support financial reporting applications. The ITGC domains relevant to AI financial image processing are: access controls over who can submit images and who can configure the AI pipeline; change management controls over how AI models or processing logic are modified; and input validation controls over the data flowing into the system. Of these, input validation for the image channel is the domain most frequently absent in early AI deployments. Teams that document thorough access controls and change management procedures for their AI pipeline frequently have no documented control that prevents an adversarial image from producing a corrupt extraction — because the risk was not contemplated when the AI feature was designed.

The Glyphward scan constitutes the input validation ITGC. Every image submitted to the financial processing workflow passes through the scan before reaching the LLM. The scan ID and result are logged to the audit trail. The control is testable: an auditor can submit a known adversarial test image, confirm that the API returns a score above the threshold and a block decision, and verify that the scan ID appears in the audit trail log. That is the operating-effectiveness evidence format that an external auditor can document in their ITGC workpapers.

COSO Framework — control activities for AI financial inputs

The 2013 COSO Internal Control — Integrated Framework is the reference framework for ICFR design under Section 404. COSO Principle 10 requires that an organization "selects and develops control activities that contribute to the mitigation of risks to the achievement of objectives to acceptable levels." For financial reporting, the primary objective is accurate financial statements. The risk introduced by AI image processing is that adversarial inputs produce inaccurate extracted data. The COSO-required control activity that mitigates this risk is input validation at the point where external image content enters the AI processing pipeline.

A vision AI model that accepts unvalidated image inputs — images that have not been scanned for adversarial content before being passed to the model — is operating without the COSO-mandated control activity for that risk. This is not a matter of interpretation: COSO Principle 10 applies to every significant risk to financial reporting accuracy, and a manipulable AI extraction step is a significant risk to accuracy if its outputs feed financial statements. Deploying the Glyphward scan as the input validation control activity satisfies the COSO requirement and provides the documentation that management's ICFR assessment needs to identify the control, describe it, and conclude that it is designed effectively.

Change management — AI deployment as an ICFR change event

SOX auditors treat the deployment of a new application or significant change to an existing application that supports financial reporting as a change management event requiring documented review. The deployment of an AI model to process financial document images — whether as a new AP automation system, an upgrade to expense management software, or the addition of document extraction to a contract management platform — is an ICFR change event. Change management review for that deployment should document: the risks introduced by the new component, the controls designed to mitigate those risks, and the testing performed before go-live. Multimodal prompt injection is a risk that must appear in that change management documentation. If the deployment went live without documenting the multimodal PI risk and identifying a detection control, the change management review has a gap. Adding Glyphward to the processing pipeline and documenting the scan as the input validation control closes the risk documentation gap retroactively and prevents future deployments from repeating it.

AI attack surfaces in financial reporting workflows

Multimodal prompt injection in financial contexts follows a consistent pattern: an adversarial instruction is embedded in an image — in pixel regions that are imperceptible to human reviewers but legible to a vision model — and the model executes the instruction when it processes the image. The instruction is typically designed to modify the extracted output in a way that is plausible enough to pass downstream review. The following workflows are the primary AI attack surfaces in financial reporting.

Accounts payable invoice processing

AP automation platforms that accept scanned supplier invoices or mobile photo captures from AP teams are the highest-volume target. A manipulated invoice image can carry an instruction telling the LLM to extract a higher invoice amount (an amount close enough to the actual amount to pass three-way match within tolerance), substitute a different vendor identifier (routing the payment to a controlled account), or assign a different GL code (moving the expense to a category with weaker review controls). The manipulated data is then submitted to the ERP — SAP, Oracle Financials, NetSuite — via API, where it is posted as a legitimate transaction with the correct document references. The adversarial modification is in the AI extraction layer, not in the ERP transaction, making it invisible to most ERP audit queries.

Expense management receipt processing

Employee expense platforms that photograph receipts with a mobile app and use vision AI to classify and extract the amount are a high-frequency, lower-unit-value target. A manipulated receipt image can instruct the LLM to extract a higher amount (staying within the employee's approval threshold to avoid manager review), change the merchant category (reclassifying a personal purchase as a business expense), or suppress the duplicate-detection signal by returning a different transaction timestamp. Because expense processing is high volume and individual transaction amounts are small, this attack surface is often underweighted in risk assessments — but aggregate manipulation across many employees or many submissions by one employee can produce a material misstatement in operating expense reporting.

Contract extraction for financial terms

Legal and finance AI that extracts payment terms, liability caps, renewal dates, and minimum commitments from scanned or photographed contract pages is an attack surface with direct financial statement impact. An adversarial contract page can instruct the LLM to extract a different payment due date (deferring a payable beyond the reporting period), a different liability cap (understating contingent liability disclosures), or a different renewal term (affecting the lease accounting classification under ASC 842). Contract extraction errors feed into accounts payable schedules, contingent liability footnotes, and lease obligation disclosures — all material components of financial statements.

Bank statement reconciliation

AI that processes scanned bank statement PDFs or images to extract transaction amounts and ending balances for cash reconciliation is an attack surface close to the financial statement bottom line. An adversarial statement page can instruct the LLM to extract an inflated ending balance or to omit specific transactions from the extracted transaction list. Because the bank statement is typically treated as a reliable external document, manipulated extractions in this workflow may receive less skeptical review than AP invoices from unknown vendors. The result of a successful attack is a cash balance misstatement or an unreconciled difference that is incorrectly attributed to timing rather than an extraction error.

Board document and financial report indexing

AI that indexes board meeting slides, management presentations, or draft annual report PDFs for search or summarization is a softer target with disclosure-layer implications. An adversarial diagram or chart embedded in a board document can inject false figures into AI-generated meeting summaries or financial commentary. If those summaries are used as inputs to disclosure drafting workflows — which is increasingly common in AI-assisted financial reporting tools — the false figures can propagate into MD&A language or earnings release drafts. This attack surface is harder to exploit for direct financial statement manipulation but is relevant to the disclosure controls component of Section 302 certifications.

Implementation: scan_financial_image() pattern

import hashlib
import time
import uuid
from dataclasses import dataclass
from typing import Literal
import httpx

GLYPHWARD_API_KEY = "gw-..."          # store in secrets manager, not source
GLYPHWARD_SCAN_URL = "https://api.glyphward.com/v1/scan"

# Threshold for financial document workflows.
# Use 70 for standard commercial AI processing.
# Lower to 65 for transactions above $100K — trades more false positives
# for higher detection sensitivity. Document your chosen value in ICFR controls.
SOX_FINANCIAL_THRESHOLD = 70

WorkflowStep = Literal[
    "ap_invoice",
    "expense_receipt",
    "contract_page",
    "bank_statement",
]

@dataclass
class FinancialScanRecord:
    scan_id: str
    image_sha256: str
    score: int
    decision: Literal["allow", "block"]
    timestamp: float
    workflow_step: WorkflowStep


def scan_financial_image(
    image_bytes: bytes,
    workflow_step: WorkflowStep,
    threshold: int = SOX_FINANCIAL_THRESHOLD,
) -> FinancialScanRecord:
    """
    Scan a financial document image for multimodal prompt injection
    before passing it to any vision LLM.

    Returns a FinancialScanRecord. If decision is "block", do NOT pass
    the image to the model — route to manual review instead.

    This function is the ICFR input validation control for AI-processed
    financial document images. The returned record must be persisted to
    the SOX audit trail via log_to_sox_audit_trail().
    """
    image_sha256 = hashlib.sha256(image_bytes).hexdigest()

    response = httpx.post(
        GLYPHWARD_SCAN_URL,
        headers={
            "Authorization": f"Bearer {GLYPHWARD_API_KEY}",
            "Content-Type": "application/octet-stream",
        },
        content=image_bytes,
        timeout=10.0,
    )
    response.raise_for_status()
    payload = response.json()

    score = payload["score"]          # 0–100; higher = higher injection risk
    scan_id = payload["scan_id"]      # stable UUID for audit trail reference

    decision: Literal["allow", "block"] = (
        "block" if score >= threshold else "allow"
    )

    record = FinancialScanRecord(
        scan_id=scan_id,
        image_sha256=image_sha256,
        score=score,
        decision=decision,
        timestamp=time.time(),
        workflow_step=workflow_step,
    )

    # SOX ICFR evidence — input validation control for AI-processed financial image.
    log_to_sox_audit_trail(record)

    return record


def log_to_sox_audit_trail(record: FinancialScanRecord) -> None:
    """
    Persist the scan record to your SOX audit trail store.
    Replace this stub with your SIEM, append-only log, or audit database.
    The record must be immutable after write — do not allow update or delete.
    """
    import json, logging
    audit_logger = logging.getLogger("sox.icfr.ai_input_validation")
    audit_logger.info(json.dumps({
        "event": "financial_image_scan",
        "scan_id": record.scan_id,
        "image_sha256": record.image_sha256,
        "score": record.score,
        "decision": record.decision,
        "timestamp": record.timestamp,
        "workflow_step": record.workflow_step,
    }))


# --- Usage in AP invoice processing pipeline ---

def process_ap_invoice(image_bytes: bytes) -> dict:
    """
    Example: AP invoice image processing with SOX-compliant scan gate.
    The vision LLM is never called if the image is blocked.
    Fail closed — a block routes to manual review, never bypasses the control.
    """
    scan = scan_financial_image(image_bytes, workflow_step="ap_invoice")

    if scan.decision == "block":
        # Do not pass the image to the LLM.
        # Route to AP team for manual review with the scan_id as reference.
        raise ValueError(
            f"Invoice image blocked by ICFR input validation control "
            f"(scan_id={scan.scan_id}, score={scan.score}). "
            f"Route to manual AP review."
        )

    # Only reached if scan.decision == "allow".
    # Pass image to your vision LLM here.
    extracted = call_vision_llm_for_invoice(image_bytes)
    extracted["icfr_scan_id"] = scan.scan_id   # attach evidence to ERP transaction
    return extracted


def call_vision_llm_for_invoice(image_bytes: bytes) -> dict:
    # Your existing vision LLM call — GPT-4o, Claude 3, Gemini Vision, etc.
    raise NotImplementedError

The scan_financial_image() function is the operative control. It must be called synchronously, before the image reaches the vision model, and the result must be evaluated before proceeding. Fail-closed design is not optional for ICFR controls: if the scan API is unavailable, reject the image and route to manual review rather than falling back to unscanned processing. A fallback that bypasses the control on error negates its SOX value — the control is not operating effectively if it can be circumvented by a transient service interruption. The icfr_scan_id attached to the ERP transaction record creates a forward reference from the financial data to its scan evidence, enabling auditors to sample transactions and trace each one back to its scan log entry.

Get early access

Coverage matrix

Related questions

Further reading

• PCI DSS AI security — injection protection for AI in payment environments.
• SOC 2 AI security controls — comparable ITGC evidence for SOC 2 Type II.
• Prompt-injection scanner for document AI — scanning invoice and contract PDFs with Google Document AI, AWS Textract, Azure Document Intelligence.
• PDF prompt-injection detection — scanning financial statement PDFs.
• Indirect prompt injection via image — remotely-fetched invoice or statement images.
• Multimodal LLM security API — Glyphward API overview.