Compliance · PCI DSS

PCI DSS AI security: multimodal prompt injection in payment environments

PCI DSS 4.0 became effective on 31 March 2024 for all entities, with new requirements fully mandatory from 31 March 2025. Requirement 6.2.4 mandates that bespoke and custom software is protected against all types of injection attacks, including "malicious code or content" injected through application inputs. AI systems in payment environments — vision models that process receipt images, document AI for chargeback evidence, KYC image capture pipelines — are bespoke custom software that accepts untrusted image inputs. Multimodal prompt injection is an injection attack class that text-only scanners cannot detect. Glyphward provides per-scan audit records with a stable scan_id and image hash that satisfy QSA evidence requirements for Requirement 6.2.4 controls.

TL;DR

PCI DSS 4.0 Req 6.2.4 requires injection protection for AI software that processes cardholder-environment images. Call POST https://glyphward.com/v1/scan before any LLM vision call, block on score ≥ 70, and log scan_id + image_sha256 to your audit trail (never log CHD in scan records). Glyphward Pro and Team plans include dashboard access to scan logs for QSA evidence collection. Free tier — 10 scans/day, no card required.

Relevant PCI DSS 4.0 requirements for AI systems

Requirement 6.2.4 — Injection attack protection. Requires that all bespoke and custom software be protected from injection attacks including — explicitly — "malicious code or content" via application input. AI systems that accept image inputs from cardholders, merchants, or external users are bespoke custom software. A multimodal PI payload embedded in a JPEG is "malicious content" injected through the image upload interface. The requirement applies whether the software is developed in-house or by a third party on your behalf.

Requirement 6.3.2 — Inventory of bespoke software. Requires maintaining an inventory of all custom software and ensuring it is included in security testing. If you have deployed a vision AI system in any part of your cardholder data environment (CDE), that system must appear in your software inventory and its injection controls must be testable by a QSA.

Requirement 12.3.2 — Targeted risk analysis. PCI DSS 4.0 introduced customised implementation — entities may deviate from prescriptive requirements with a documented targeted risk analysis that demonstrates equivalent or stronger controls. AI-specific multimodal PI controls (scan before LLM call, log scan_id, block on score threshold) can form the basis of a customised implementation for any AI-adjacent requirement where the default prescriptive control does not map cleanly to AI architecture.

Requirement 10.3 — Audit log protection. Glyphward scan logs stored in your own system (scan_id, image_sha256, timestamp, decision) are audit log entries that must be protected against modification under Req 10.3. Store scan records in an append-only log with access controls equivalent to your other PCI audit logs.

AI attack surfaces in payment environments

Payment receipt and invoice OCR. AI-powered receipt scanning — expense management integrations, merchant invoicing tools, tax prep software — processes user-uploaded images of receipts and invoices. An adversarial receipt image can instruct the LLM to return false amounts, merchant names, or categories, corrupting financial records or bypassing expense limits.

Chargeback and dispute evidence processing. Dispute management platforms that use AI to classify chargeback evidence images (merchant screenshots, delivery photos, product condition images) accept untrusted inputs from merchants and cardholders. A crafted evidence image can alter the AI's dispute classification, affecting the outcome of a chargeback arbitration.

KYC and identity document processing. Onboarding AI that processes government-issued ID photos, selfies for liveness detection, or utility bill scans operates in a high-value, high-fraud-risk environment. Adversarial pixels in a submitted ID scan can redirect the AI's extraction output, producing incorrect name, date-of-birth, or document number fields in the KYC record.

Merchant-submitted product and storefront images. Marketplace platforms in the payment space that process seller-uploaded product images using AI for categorisation, compliance review, or fraud detection accept untrusted inputs from any merchant account. A manipulated product image can alter the AI's categorisation or suppress a fraud flag.

Implementation: scan_payment_image() pattern

import hashlib, base64, requests, logging
from dataclasses import dataclass
from datetime import datetime, timezone

@dataclass
class PaymentScanRecord:
    scan_id: str
    image_sha256: str
    score: int
    decision: str        # "pass" | "block"
    timestamp: str
    # NEVER include cardholder data (PAN, CHD) in this record

GLYPHWARD_API_KEY = os.environ["GLYPHWARD_API_KEY"]
SCAN_THRESHOLD = 70      # Payment environments: standard threshold

def scan_payment_image(image_bytes: bytes, context: str) -> PaymentScanRecord:
    """Scan image before any LLM vision call in a payment workflow."""
    image_sha256 = hashlib.sha256(image_bytes).hexdigest()
    image_b64 = base64.b64encode(image_bytes).decode()

    resp = requests.post(
        "https://glyphward.com/v1/scan",
        headers={"Authorization": f"Bearer {GLYPHWARD_API_KEY}",
                 "Content-Type": "application/json"},
        json={"image": image_b64, "source": context},
        timeout=5,
    )

    if not resp.ok:
        # Fail-closed: scanner unreachable = block
        record = PaymentScanRecord(
            scan_id="SCANNER-UNAVAILABLE",
            image_sha256=image_sha256,
            score=100,
            decision="block",
            timestamp=datetime.now(timezone.utc).isoformat(),
        )
        log_scan_record(record)
        raise RuntimeError(f"PI scanner unavailable — image blocked. sha256={image_sha256}")

    result = resp.json()
    decision = "block" if result["score"] >= SCAN_THRESHOLD else "pass"
    record = PaymentScanRecord(
        scan_id=result["scan_id"],
        image_sha256=image_sha256,
        score=result["score"],
        decision=decision,
        timestamp=datetime.now(timezone.utc).isoformat(),
    )
    log_scan_record(record)   # append-only audit log, PCI Req 10.3

    if decision == "block":
        raise ValueError(
            f"Image blocked by PI scanner. scan_id={record.scan_id} score={record.score}"
        )

    return record

Call scan_payment_image(image_bytes, "kycupload") before passing any image to your LLM. The PaymentScanRecord is your QSA evidence artefact: it contains a stable scan_id, a content hash, the risk score, and the block/pass decision, with no cardholder data. Store records in an append-only table with write access restricted to the scanning service account.

Get early access

Coverage matrix

Defence layerReceipt OCR imageKYC document scanChargeback evidenceProduct image
WAF (SQL/XSS injection rules)No (image bypass)NoNoNo
Antivirus / malware scannerNo (PI is not malware)NoNoNo
Text-only scanner (LLM Guard, Lakera)No — image bytes ignoredNoNoNo
Glyphward scan_payment_image()Yes — pixel-level scanYesYesYes

Related questions

Is Glyphward a PCI-certified service provider?

Glyphward is not currently listed on the Visa or Mastercard PCI DSS compliant service provider lists. The scanning service operates outside your cardholder data environment — image bytes are sent to the Glyphward API, scored, and returned as a numeric risk score and scan_id. No cardholder data (PAN, CVV, expiry) should be embedded in images sent for scanning; if your images contain CHD, contact us before integrating. QSAs reviewing Req 6.2.4 controls can examine the scan_id log, the code path showing the scan precedes the LLM call, and the block-on-threshold logic as evidence of injection protection.

Does this count as a "required" or "addressable" control under PCI DSS?

PCI DSS 4.0 does not use the "required vs addressable" terminology from HIPAA. Requirement 6.2.4 is a required control — all in-scope entities must implement injection protection for their bespoke software. The customised implementation pathway (Req 12.3.2) allows you to document an alternative control that achieves equivalent security, which a Glyphward integration can satisfy if your QSA agrees the targeted risk analysis is adequate.

Does sending images to Glyphward's API affect PCI scope?

Images of payment receipts or KYC documents may contain sensitive data but generally do not contain PANs in machine-readable form. Before integrating, confirm with your QSA whether the image processing pipeline is already in-scope for PCI and whether routing images through a third-party API expands your scope. In most cases, receipt images and ID scans that do not contain card numbers are not CHD and do not expand PCI scope. Always redact or mask any numeric sequences that could be confused with a PAN before sending for scanning.

How do scan logs integrate with our existing PCI audit log system?

Append the PaymentScanRecord fields (scan_id, image_sha256, score, decision, timestamp) to whatever append-only log system you use for PCI audit events — a dedicated database table with a non-deletable insert-only role, a SIEM event stream, or a write-once blob store. The log must satisfy Req 10.3 (protection against modification, destruction, and unexpected changes). Glyphward Pro and Team plans expose scan history via the web dashboard and API, which can be used as a secondary log for cross-referencing during QSA evidence collection.

Further reading