> ## Documentation Index
>
> Fetch the complete documentation index at: https://lithi.ai/llms.txt
>
> Use this file to discover all available pages before exploring further.

---
title: Data profiles Compute accepts and refuses
description: >-
  The eight data profiles, what each one admits and rejects, and why regulated or
  credential-bearing content is refused outright rather than accepted with a warning.
route: /docs/compute/security/data-profiles
page_id: docs-compute-security-data-profiles
page_type: reference
content_layer: technical reference
surface_profile: technical_reference
audience: Integrators and security reviewers classifying an input before submission
voice: D
reader_question: Which data may I send to Compute, and what is refused?
primary_action: Read where plaintext can exist
source_locale: en-US
source_status: APPROVED
source_version: docs-compute-security-data-profiles-en-us-2026-09-05-v1
last_updated: '2026-09-05'
robots: index
claim_registry_pinned: true
claim_registry_resync: "npm run governed:tsx -- scripts/build-compute-public-claim-registry.ts --write"
---

## The eight data profiles

| Profile | What it admits | What it rejects |
|---|---|---|
| `shared_public` | Content that is already published or lawfully public | Anything you have not confirmed is public |
| `shared_deidentified` | Records whose direct identifiers you removed before sending | Records that remain re-identifiable, and identifiers you meant to strip but did not |
| `shared_customer_approved` | Your own content, approved for this processing by someone in your organization who can authorize it | Content nobody in your organization approved for this use |
| `shared_native_test` | Bounded test material for checking a native capability | Production content borrowed for a test run |
| `shared_synthetic_seed` | Generated material with no real person or record behind it | Synthetic material derived from real records you did not deidentify |
| `rejected_regulated_secret` | Nothing. This is a refusal class | Regulated content and secret-bearing content |
| `rejected_credential` | Nothing. This is a refusal class | Keys, tokens, passwords, signed URLs and every other credential |
| `rejected_unsupported` | Nothing. This is a refusal class | Anything outside the five accepted profiles above |

## How the five accepted profiles differ

- **Public** is a fact about the content, not about your intent to share it. If you cannot point to where it is public, it is not `shared_public`.
- **Deidentified** is your work, done before you send. Compute does not deidentify on your behalf.
- **Customer approved** carries an approval from a person in your organization who holds that authority. It is the profile for your own business content.
- **Native test** is bounded material used to check a capability. Keep production records out of it.
- **Synthetic seed** has no real subject behind it. Material generated from real records is not synthetic until it is also deidentified.

## What each profile does not decide

A data profile is not a residency rule, a retention window, or an approval to spend. Those are separate settings with separate authorities.

A profile also does not widen a workflow. The workflow you choose states which profiles it accepts, and your quote repeats that.

## The three rejected classes are refusals

Regulated content, secret-bearing content and credential content are refused. They are not discouraged, and they are not accepted with a caution.

Anything outside the accepted classes lands in `rejected_unsupported`. A profile you cannot name for your input is a reason to narrow the input, not a reason to guess.

## Where the decision is made

1. You classify the input before you send it, using your own knowledge of the records.
2. Validation reads the frozen snapshot and checks bytes, schema and item identity against the workflow's declaration.
3. Admission refuses a job whose declared profile does not match the workflow.

## What a refusal returns

A refusal is a typed non-success outcome. It carries a safe reason and a non-empty next action, and it never becomes a silent partial run.

The safe reason names the constraint that failed. It does not quote your content back to you, because refusal records stay content-free.

Common next actions are narrowing the input, deidentifying it before resending, choosing a workflow that accepts the profile, or removing the credential the input contained.

## Credentials inside an input

A credential found inside your data is refused under `rejected_credential`, whatever the surrounding content was for.

Treat that refusal as an exposure. Rotate the credential at the system that issued it, then resend the input without it.

[Read where plaintext can exist](/docs/compute/security/encryption-and-plaintext)