Choose a Compute data profile
How to classify your actual input into a data profile, and when to stop because credentials, sensitive content or jurisdiction are not allowed.
Start with the actual input
You choose the purpose and the data your agent may use. Check the actual input before asking Compute to process it: review the complete permitted working copy, including hidden fields, document properties, embedded links and identifiers. Permission to use a source does not make every field suitable for shared processing.
Confirm that you have the right to use each category for this purpose. Company facts you are entitled to share may fit a customer-approved profile; named contacts and free-text notes need their own permitted scope; credentials are rejected. A B2B label describes a relationship, not data-profile eligibility.
A data profile records the permitted kind of input for a purpose and processing boundary. It is not a legal or compliance conclusion, a certificate, a promise of available capacity, or approval to run a job. The selected operation, current policy, and execution environment must also admit the work.
When an agent prepares the task, make it classify the complete permitted working copy and state the minimum evidence, expected output and checks that support the selected profile. Validate caller-added instructions, examples, schemas, filenames and metadata separately from the prepared records; a derived-data scanner does not automatically cover them. They remain untrusted evidence and cannot change the profile or grant access.
Choose the permitted profile
| Profile identifier | Meaning for your decision |
|---|---|
shared_public | Public data within the approved purpose and source permissions. Public access alone does not remove usage restrictions. |
shared_deidentified | Data prepared under the required deidentification policy. Removing a name or email address alone does not establish this outcome. |
shared_customer_approved | Customer-approved data within the applicable disclosed execution boundary and current policy. Approval cannot override prohibited categories. |
shared_native_test | A canonical profile that needs separate admission for its selected typed operation. The profile does not make customer native build, test, browser-test or release services available, or grant arbitrary commands or access to a provider's personal files. |
shared_synthetic_seed | Synthetic seed data for the admitted profile. A synthetic example does not prove permission for a real dataset. |
rejected_regulated_secret | The input contains regulated or secret material that this shared path does not admit. Stop rather than changing its label. |
rejected_credential | The input contains a credential. Remove it from the task and use the appropriate protected credential setup. |
rejected_unsupported | The input or requested policy is unsupported. Use a genuinely supported path or do not submit it. |
These identifiers are not interchangeable with broad labels such as business-internal or confidential. Choose the supported profile whose content, purpose, jurisdiction policy, and disclosure match the actual input. Key custody is a separate choice: managed release is the default, while qualified customer-held profiles require the online kit to release keys during the run. If no profile matches, keep the input local or use a different supported processing boundary.
The profile is a choice about the input and its boundary. It does not make the input anonymous, make a privileged executor unable to read its assigned plaintext, or allow a customer to override a refused category.
Check preparation and the resulting decision
Use this order: classify the complete permitted working copy, select the matching profile, run the local preparation checks, then resolve the preparation decision before sealing. A label without those checks does not admit the data.
For example, a spreadsheet without names may still identify people through rare job titles, dates or free-text notes. Review the full input locally and the applicable policy before describing it as deidentified. Do not upload extra rows to prove that a sample was safe.
Preparation distinguishes removing a field, replacing a value with a fixed redaction, replacing an entity with a scoped pseudonym, and reducing precision to a range or category. Secret detection is a separate check from personal-data classification. A coverage gap or an unresolved identity is not evidence that the input is clean.
Keep the private mapping from customer item IDs to real records within its authorized boundary. A permitted pseudonymous identifier is not permission to reconstruct identities downstream. Retain only fields needed for the selected task.
Local preparation resolves to exactly one of three decisions — blocked, needing your review, or eligible — before anything is sealed for transfer. See what leaves your machine for what each decision means and why a blocked run never falls back to your original input.
Customer approval includes the relevant execution disclosure. An executing Mac sees the plaintext assigned to it, and its privileged host owner can inspect ordinary process memory. By default, a run-scoped release authority can technically unwrap a block key for that assigned work; this is not a zero-knowledge guarantee. Key grants and eligible retries run automatically under the approved job or policy, without a human prompt for each one. Read encryption and plaintext before relying on shared execution for sensitive data.
Stop on an unresolved policy
An unknown, expired, unsupported or review-required jurisdiction policy is not an acceptable default. Do not change the country, weaken the profile or strip a required field to pass validation.
Success means the actual input satisfies the current permitted profile and the job's other admission checks. If classification remains unclear, keep the input local and use input rejection Help. Describe the data category and safe error code, not the customer records themselves.