Trust and security

These policies and pages reference the same sub-processors.

1. A worker activity (or an API service) composes the prompt from labelled blocks. Each block is a DataBlock(source, text, trusted); build_prompt renders it on the wire as <data source="<label>" trusted="true|false">…</data> so the model, the redaction layer and the compliance record all see the same label. Trusted blocks are merchant- or platform-sourced (policy text, ids, aggregates); untrusted blocks are shopper-authored free text and prior model output.
2. Untrusted blocks are screened first where the agent declares them (AgentSpec.untrusted_inputs). The injection screen runs the keyword rules and, when the tenant's screen settings allow it, one screen_injection model call whose wire wraps the text as <untrusted_data source="<label>">…</untrusted_data>; that call uses the same router route as every agent call (POST /v1/agents/{agent_id}/model-request), so step 3 applies to it too. A flagged block is withheld from the author agent (dispute reads return empty rows; the case note agent runs without the history block). The screen record stores a hash of each untrusted input, never the text.
3. The router redacts once, before any dispatch (, redact_agent_messages). Every string on the wire - user prompt, every data block, every tool return, every prior model turn on multi-step runs - passes the universal redact_string baseline from:
4. secret shapes (provider keys, bearer tokens, webhook secrets) → [REDACTED];
5. Luhn-valid 13-19 digit sequences (card numbers) → [REDACTED];
6. email addresses → the literal [EMAIL]@[REDACTED] (the whole address, local-part and domain, is replaced; nothing of the address survives). Blocks whose label appears in the tenant policy's agents.pii.redact_by_source map are additionally routed through the field-wise redact_block hints for that label. The default map is {} (migration 122), so at launch the baseline is what every block gets.
7. Dispatch goes to the endpoint the tenant's routing policy selects among the sub-processors (Anthropic, OpenAI, Mistral, Google, xAI, plus the optional Vercel AI Gateway transport); the same redacted wire goes to whichever endpoint wins, regardless of vendor. Google and xAI carry compliance_cleared=false in the shipped platform policy (feature 581), so the routing policy and publish gate both refuse to select either vendor for production agent traffic until an operator records that vendor's sub-processor row and flips the flag; the tables below describe what would be sent, not that it is currently sent.
8. Model output comes back into the worker activity, is validated against the agent's typed output, and is persisted as a proposal or draft. Output never reaches a processor, store platform or Slack unreviewed; it is text or a proposal row an operator acts on.

Only platform-issued UUIDs cross: refund_case_id, dispute_case_id, policy_version_id, agent_run_id, discrepancy and execution row ids. They identify a row inside the tenant's own data and carry no shopper identity. The correlation id is an internal header between worker, router and API; it is not placed in the prompt and is not sent to the provider. Email addresses inside free text are not pseudonymised but removed outright ([EMAIL]@[REDACTED]), so no address-derived pseudonym reaches a provider either.

Every model call emits a span and an invocation row with token counts, cost, route decision, endpoint, effort and redaction counters. Prompt and completion content is attached only when both RouterSettings.equali_ai_content_capture_enabled and the tenant policy flag agents.telemetry.content_capture are true; the attached content is passed through redact_key_value first. Either flag off means no content in Logfire. Event payloads (gen_ai events) carry no prompt, completion or provider response body.