Multimodal inputs

A user message’s content can be an array of content parts, so a single request can mix text and files. There are six Input Types — Text, Image, Audio, Video, Document, and Archive — and the Guardian inspects each part whose Input Type is enabled.

{
  "messages": [{
    "role": "user",
    "content": [
      { "type": "text", "text": "Please review the attached file." },
      { "type": "image_url", "image_url": { "url": "data:image/png;base64,iVBORw0..." } }
    ]
  }],
  "processType": "input"
}

Content part types

`type`	Input Type	Encoding
`text`	Text	plain string in `text`
`image_url`	Image	`image_url.url` as a `data:` URI (PNG, JPG, WebP, GIF, BMP, TIFF, AVIF, HEIC)
`input_audio`	Audio	`input_audio.data` (base64) + `input_audio.format` (`wav`, `mp3`)
`file`	Document / Archive	`file.file_data` as a `data:` URI + `file.filename` (PDF, DOCX, XLSX, PPTX, TXT, CSV, …, ZIP)
`video_url`	Video	`video_url.url` as a `data:` URI (MP4) — a Starfort extension

Document and Archive both use type: "file"; Starfort routes them to the right Input Type by the file’s actual MIME / magic-byte type, not by the type field. Encode data: URI payloads with standard base64 (+, /, =) — URL-safe base64 (-, _) is not supported.

Rules

A part is only inspected if its Input Type is enabled on the Guardian. Otherwise the request is rejected, or the part is skipped, depending on the Guardian’s unsupported-file handling (below).
In the response, each part is reported as its own input_results[] entry with a type of text / image / audio / video / document / archive, and file parts carry an identifier (filename).

Unsupported files

When a file part’s category or extension isn’t enabled on the Guardian, the Guardian’s Unsupported File Handling setting decides what happens. Starting with v1.4, this setting is enforced at a single point — the Guardian: the gateway doesn’t judge or drop unsupported files itself, it passes the setting along, and the Guardian applies it identically to top-level files and to archive (ZIP) members.

BLOCK (default) — a single unsupported file rejects the whole request. The supported parts (text, allowed files) aren’t inspected either. This is fail-closed behavior: content that can’t be analyzed is never waved through uninspected.
PASS — only the unsupported file part is skipped; the rest of the request is inspected normally. The same rule applies inside archives — only unsupported members are skipped and the remaining members are inspected, so a legitimate archive that happens to contain an extension-less auxiliary file isn’t rejected wholesale.

The original of a skipped file is never delivered onward. An input whose contents Guardian couldn’t verify can’t produce a processed content (processed_content is null), and an input with no processed content is not an egress candidate.

A disguised file is always blocked. Even under PASS, a file whose extension is allowed but whose real content (magic bytes) doesn’t match its declared type is blocked — the check is on actual content, not the file name.

If you need to de-identify files stored in a bucket and save them as masked files (e.g. rebuild a .docx as a masked .docx), use the S3 de-identification batch.

Enable the Input Types you intend to send when you register the Guardian. The default VLM-OCR preset supports text plus a broad set of image, document, and archive formats.

Guard API

Batch API

Multimodal inputs

Content part types

Rules

Unsupported files

​Content part types

​Rules

​Unsupported files

Content part types

Rules

Unsupported files