Long texts and documents

Limits

Requests over the body limit are rejected with 413 (payload_too_large). Invalid sizes for single fields return 400 (invalid_payload).

The whole text is masked

Guard masks the complete input, not a prefix. Each response tells you so:

{
  "transformed_input": "...",
  "input_char_count": 48211,
  "transformed_input_complete": true
}

Check transformed_input_complete before you forward a long text. Long texts and documents are processed in overlapping chunks, so entities and secrets that cross a chunk boundary (for example a PEM key or a long token) are still masked whole.

Detection depth for very long texts

To stay within the request time budget, AgentID adapts detection to the size of each text:

• Texts below 50,000 characters get the full detection pipeline, including language-aware detection of names, organizations and addresses.
• A single text of 50,000 characters or more, typically an attachment's extracted content, is scanned with the deterministic layer: validated patterns, context rules and record fields. Each text is judged on its own, so a large attachment does not reduce detection on a short prompt.
• In fail-open systems, when time runs short on a long text, AgentID first drops the slowest refinement steps and then falls back to the deterministic layer rather than sending the text unmasked.

Systems with Strict Security (Fail-Closed) do not take that fallback: if a required detection stage fails, the request is blocked with pii_detection_unavailable.

Latency

Guard can take noticeably longer on long texts and documents. The official SDKs wait up to 30 seconds for Guard by default (guardTimeoutMs in Node.js, guard_timeout_s in Python). If you call Guard directly, use a similar timeout for long documents.

Fast retry after a slow check

Integrations that must answer quickly can retry a slow or failed check once in a faster, rule-based mode:

{
  "system_id": "cf84f936-95bc-45a4-bf98-9a1a16bf29c9",
  "input": "...",
  "pii_detection_mode": "minimal",
  "metadata": { "minimal_retry_of_client_event_id": "0467f78f-5821-4827-a09b-d59a9b08866c" }
}

Guard honours minimal only as one retry of a full check of the same system that started within the last 60 seconds with that client_event_id. Otherwise the request runs as a normal full check. Fail-closed systems keep their full masking path even in minimal mode.