• 

  1)Compares requested payment details with the trusted vendor record and places mismatched destinations on HOLD for human verification.

• 

  2)Highlights email evidence, compares it with the vendor record, and explains why human verification is required.

• 

  3)Binds a one-time verification event to a specific request, destination, and reference version to reduce reuse.

• 

  4)Shows the configured Gemini extractor and selected test case for the demonstration.

ThreadGate

Inspiration

AI has made fraudulent emails much more convincing. A payment-redirection email no longer needs poor grammar or suspicious wording to trick an accounts-payable employee. It can look like a perfectly normal message from a trusted supplier while requesting a change to the bank account receiving future payments.

We focused on a specific question: instead of trying to decide whether an email looks suspicious, what if we checked whether the payment change it requests matches the vendor record already on file?

That led to ThreadGate. Our principle is simple: AI interprets the email; deterministic code verifies the change; a human attests before anything executes.

What it does

ThreadGate is a security prototype for vendor payment-detail change requests received by email.

A user submits a vendor email, and ThreadGate normalizes the text, finds relevant financial tokens, interprets the requested change, validates the supporting evidence, compares the extracted details against the vendor record, and applies deterministic security rules.

The result is one of three decisions:

• CLEAR: No change was identified by the prototype.
• REVIEW: A change was identified that matches the record or involves a supported non-destination field; human attestation is still required before execution.
• HOLD: Out-of-band human verification is required before the request can proceed.

The interface highlights relevant evidence, shows differences against the record, and provides a callback checklist for held requests.

CLEAR is not a declaration that an email is safe, and ThreadGate does not execute payments or connect to a real banking system.

How we built it

We built the application in Python, using Streamlit for the interactive interface, Google Gemini through the google-genai SDK for email interpretation, and Pydantic for structured output validation. The project uses pytest for regression and security testing.

The processing pipeline has several stages:

1. Normalize the email. Handle selected Unicode and formatting tricks while preserving text offsets so detected evidence can be highlighted in the original message.
2. Find financial tokens deterministically. Identify account-like numbers, routing codes and other supported token types.
3. Interpret the request. Gemini extracts structured claims from the email. The production prompt does not include the trusted vendor record.
4. Validate the evidence. A claim must be supported by a verbatim quote from the message, and its reported value must be grounded in that evidence.
5. Compare against the record. The application computes field-level differences between requested details and the synthetic vendor record.
6. Apply security invariants and policy. Deterministic checks can escalate a decision from CLEAR to REVIEW or HOLD, but the model cannot override the policy or clear an existing security trigger.

We also implemented safeguards for alternate payment destinations, unsupported changes, evidence contradictions, stale or missing reference records, reference-version lineage, and single-use verification events within the prototype's active verification store.

The evaluation tooling includes a rules-only baseline, an offline test double, and adversarial harnesses that steer the model toward claiming there is no change or supplying a misleading quote.

Challenges we ran into

The hardest problem was not extracting account numbers. It was deciding whether a message actually requests a payment change.

A message might mention a bank account without directing a payment to it. A request might correct an earlier instruction, contain negation, or include quoted text that contradicts the sender's current instruction. A compromised model could also return a plausible-looking answer supported by an irrelevant quote.

We addressed these problems with a combination of deterministic token detection, structured extraction, evidence-to-quote validation, action-specific security checks, and a policy that only permits escalation.

We also had to distinguish real evaluation evidence from simulated model behavior. Offline test doubles and adversarial harnesses help test the security boundary, but they are not substitutes for genuine model-backed benchmark results.

Accomplishments that we're proud of

• Built an end-to-end pipeline that separates AI interpretation from deterministic decision-making.
• Implemented a closed-world evidence validator that rejects unsupported claims rather than trusting model-generated values.
• Created explicit security invariants for payment-destination changes, evidence validation, record freshness and version lineage, and verification-event reuse.
• Added adversarial test harnesses for misleading model verdicts and forged or irrelevant evidence.
• Built a Streamlit interface that explains decisions using evidence highlights, record differences and a callback checklist.
• Kept the prototype's limitations visible instead of claiming that a test result proves real-world fraud prevention.

The project includes fourteen named security invariants in its documented design. Model-backed comparison results should be reported only after the corresponding live evaluations have actually run.

What we learned

A language model can be useful for understanding an email without being the authority that decides whether a financial change is allowed.

We learned to treat model output as an untrusted set of claims, require evidence for those claims, and keep security decisions in deterministic code. We also learned that a system that fails safely may create extra manual reviews, so evaluations must measure both unsafe releases and unnecessary holds.

Finally, reliable security claims require reproducible tests and clear limitations. A prototype tested on synthetic data is useful evidence about its implementation, but it is not proof of effectiveness in a real payment operation.

What's next for ThreadGate

Our next priorities are to complete reproducible model-backed evaluations against the rules-only and model-alone baselines, test the workflow with accounts-payable users, and measure the trade-off between unnecessary reviews and missed changes.

We would also explore integration with existing payment-approval workflows and durable verification storage, subject to further security review. Any future integration would preserve the central design principle: AI can interpret the request, but a model must never independently authorize a payment-detail change.

All financial identifiers used in the current prototype are synthetic demo data.

Built With

• ai
• api
• argparse
• cloud
• community
• gemini
• gen
• git
• github
• google
• hashlib
• json
• logging
• pathlib
• playwright
• pydantic
• pytest
• python
• python-dotenv
• rich
• sdk
• sha-256
• streamlit