A courts portal AI should accept text filings but reject image and audio uploads to reduce deepfake-input risk. Which control best implements that policy?

Applying modality limits that allow text only and reject image or audio inputs is the control that implements a courts portal AI policy to accept text filings while reducing deepfake-input risk. Modality limits sit at the AI gateway and declare which input types the endpoint will accept. For civic court filings that only need text, blocking image and audio at the edge shrinks the attack surface for manipulated media, voice clones, and deepfake-style uploads before they reach the model or evidence pipelines.

Applying client-side checks that allow text only and reject image or audio inputs fails because client-side validation can be bypassed with direct API calls, so it does not enforce the text-only rule at the AI gateway. Applying rate limits that allow text only and reject image or audio inputs fails because rate limits throttle volume and frequency, not input type, so they cannot enforce a text-only modality block at the AI gateway. Applying prompt instructions that allow text only and reject image or audio inputs fails because instructions are advisory guidance the model can ignore, not a hard gateway block that prevents image and audio modalities from reaching the model.

Exam caveat: Distinguish modality limits (what input types are allowed) from bypassable client-side checks, rate limits that throttle volume rather than input type, or advisory prompt instructions. When the stem cites deepfake-input risk and a text-only filing need, modality limits are the direct match.

Operational check: Configure the courts portal AI gateway for text-only inputs, submit a sample text filing (accepted), then attempt image and audio uploads (rejected), confirm no rejected media is published to a public gallery, and verify TLS remains enforced on the portal.