Guardrails
A project can override your organization’s prompt injection protection and data loss prevention policy, such as blocking on a customer-facing assistant while a batch job only alerts. Unset fields inherit from the organization. Each resource supports GET, PUT (replaces the whole override), and DELETE (clears it), with the manage_projects scope.
How an override applies
GET shows the override as a project API key sees it, so a project named only per request can show a relaxed value while its requests run the organization policy. To run a looser policy, give the project a project API key.
Prompt injection
PUT /v1/projects/{project_id}/pi-settings accepts these fields:
pi_pass_threshold, pi_input_action, pi_safer_vendor_route, and pi_log_full_text_on_block are organization-only and return 422 here. Allowlist patterns add to the organization’s list; one broad enough to match ordinary text is ignored.
The response returns override (what you set), effective (merged), and inherited_fields.
Data loss prevention
PUT /v1/projects/{project_id}/dlp-settings takes an override map keyed by entity type. Each entry sets enabled (scanned or not) and/or action (log, redact, or block), inheriting the other. An entity that isn’t a seeded or custom rule in your organization returns 422 naming it.
The response returns your override plus every catalog entity with org_action, effective_action (null means not scanned), and overridden.
Inheriting again
DELETE, or PUT with {} (PI) or {"override": {}} (DLP), clears a project’s override. To drop one field and keep the rest, send it as null.
Limits
Writes past a limit return 422 naming it. Only active projects count toward per-organization limits.
See the Management API reference for full schemas.