suggestibility.ai
Sample review. The document below is fictional — the organisations, people and figures in it are invented. The review itself is real output from a suggestibility.ai board, unedited.
Security threat model

Threat Model: Customer Document Upload

A STRIDE threat model for a claims-portal upload path. Seven reviewers.

Board
7 reviewers
Score
58 / 100
What that means
Needs work
Real problems the board expects you to address before this goes further.

Consensus

The board concurs that the threat model exposes critical SSRF risk via the URL fetcher, high‑risk unsandboxed image/OCR processing, insecure long‑lived presigned URLs, absent malware scanning, and insufficient audit visibility. Immediate isolation, sandboxing, URL hardening, and improved logging are required.

Findings

critical

Unauthenticated SSRF via URL fetcher

The fetcher worker can download arbitrary URLs and follows up to 5 redirects without validating IP ranges, allowing access to internal services and metadata endpoints.

Raised by Principal Software Architect

high

Unsandboxed subprocess execution and extension‑only validation

ImageMagick and Tesseract run as raw subprocesses on uploaded files validated only by extension, exposing the worker to RCE through crafted payloads.

Raised by Security and Reliability Reviewer

high

Insecure long‑lived presigned URLs

Presigned S3 URLs are valid for 7 days, sent via plaintext email, and cannot be revoked, giving unauthenticated parties prolonged access to sensitive documents.

Raised by Product Delivery Lead

high

Absence of malware/virus scanning

Uploaded documents are never scanned; reliance on endpoint protection on handlers’ laptops leaves the system vulnerable to zero‑day exploits delivered via documents.

Raised by Threat Modeling Specialist

medium

Insufficient audit logging and document‑level access control

Audit rows capture upload metadata but omit the original fetcher URL and lack granular document‑level ACLs, reducing traceability and fine‑grained protection.

Raised by AI Governance and Evaluation Reviewer

Dissent — recorded, not resolved

SSRF severity should be rated medium — Threat Modeling Specialist

Majority view: critical

Recommendations — ranked, not scored

  1. now Isolate the fetcher in a dedicated subnet, block private IP ranges, enforce an outbound allow‑list, and log full request details to mitigate SSRF.
  2. now Run ImageMagick/Tesseract inside hardened containers or sandboxes, add magic‑byte content sniffing, and integrate automated malware scanning for all uploads.
  3. now Replace 7‑day presigned URLs with short‑lived (<1 hour) tokens generated on‑demand, deliver them via an authenticated portal, and implement a revocation list.
  4. next Introduce document‑level access controls and extend audit logs to record source URLs, download events, and hash verification results.

Coverage

  • network security — partial. No allow‑list or subnet isolation for fetcher; SSRF controls missing.
  • execution environment — partial. Processing binaries run unsandboxed; lacks containerization and seccomp profiles.
  • access control — partial. Long‑lived presigned URLs and claim‑level ACLs only; no revocation or document‑level granularity.
  • observability — gap. Fetcher source URLs not logged; audit trail lacks download and integrity verification details.

The board

Principal Software Architectgoogle · gemini-3.6-flash
Security and Reliability Reviewercloudflare · @cf/openai/gpt-oss-120b
Threat Modeling Specialistcloudflare · @cf/meta/llama-3.3-70b-instruct-fp8-fast
Product Delivery Leadcloudflare · @cf/google/gemma-4-26b-a4b-it
API and Integration Architectcloudflare · @cf/nvidia/nemotron-3-120b-a12b
Data and Analytics Reviewercloudflare · @cf/moonshotai/kimi-k2.6
AI Governance and Evaluation Reviewercloudflare · @cf/mistral/mistral-7b-instruct-v0.2-lora
Read the document that was reviewed (3,206 characters)

Threat Model: Customer Document Upload

System: Document intake for the claims portal

Author: Security engineering

Review date: 2026-07-30

Method: STRIDE, informal

System description

Authenticated customers upload supporting documents (photos, PDFs, occasionally

DOCX) to a claim. Files go to S3. A worker generates a thumbnail and extracts

text with an OCR library so claims handlers can search across attachments.

Handlers download originals through a signed URL.

An additional path exists: a customer may supply a URL instead of a file, and

our fetcher retrieves the document on their behalf. This was added for

insurers who host documents on their own portals.

Assets

  • Customer documents (may contain medical records, ID scans, bank statements)
  • The claims database
  • Internal network reachable from the fetcher worker

Trust boundaries

  • Browser → API (authenticated, TLS)
  • API → S3 (IAM role)
  • Fetcher worker → arbitrary internet host (customer-controlled URL)
  • OCR worker → uploaded file contents

Threats considered

Spoofing

Session hijacking is covered by the existing auth review. No new surface.

Tampering

S3 objects are written once and never updated. Bucket versioning is on.

Repudiation

Every upload writes an audit row with user_id, claim_id, SHA-256 of the

file, and timestamp.

Information disclosure

Signed URLs are generated with a 7-day expiry so handlers can reference a

document across a working week without re-requesting. URLs are emailed to

handlers as part of the claim digest.

Bucket is private; only signed URLs grant access. There is no mechanism to

revoke a signed URL before expiry, but the window is short enough that we

consider this acceptable.

Denial of service

Upload size capped at 25MB. Rate limited to 20 uploads per claim per hour.

The OCR worker runs on a separate queue so a large batch cannot starve the API.

Elevation of privilege

No user-supplied content is executed. Thumbnails are generated with ImageMagick

and OCR uses Tesseract, both invoked as subprocesses with the file path as an

argument.

Accepted risks

  • Malware scanning is out of scope. We do not scan uploads. Claims handlers

open documents on managed laptops with endpoint protection, so the control

exists one layer out. Adding a scanner would add ~4s to the intake path.

  • MIME type is validated by extension. We accept .pdf, .jpg, .jpeg,

.png, .docx and reject everything else. Content sniffing was considered

and deferred; the extension check has been sufficient in practice.

  • The URL fetcher follows redirects. Up to 5 hops, matching the HTTP client

default. Customers occasionally supply shortened links and this keeps that

working.

Controls in place

  • TLS 1.2+ everywhere
  • S3 SSE-KMS at rest
  • IAM role scoped to the single bucket
  • Audit trail on upload and download
  • 25MB size cap and per-claim rate limit

Open items

  • Should the fetcher run in its own VPC with no route to internal services, or

is the current shared subnet acceptable given it only makes outbound calls?

  • Do we need document-level access control, or is claim-level sufficient?
Run a review See pricing