Handle credentials and recorded data

Keep management keys, app credentials, and recorded app data separate when deciding who needs access. environments:read permits reading recorded bodies. environments:connect permits obtaining credentials that act inside an app.

​

Give a program the scope it needs

Create the program’s API key in the workspace that holds its environments. When creating a key through the management API, request only the permissions the program needs. The creator must hold each requested permission. Workspace access describes the available permissions and member-only operations. Use an app actor whose permissions match the test. An administrator actor can prepare a fixture, but it can hide permission failures that another actor would encounter. Store keys and credentials in the process environment or your secret store. Exclude them from source files, logs, screenshots, and shared exports. Treat Copy prompt output as a secret because it contains credentials for the selected app actor. A URL created with tokenInUrl: true is also a secret. For an exposed management key, revoke it and replace the value used by the program. If app credentials were exposed, delete the affected environment to end app access. Revoking the management key does not invalidate previously issued app credentials.

​

Check recorded data before sharing it

Open a request’s coverage and omission reason before using it as evidence. The recorder replaces recognized credential fields with [REDACTED]. It omits any body that contains a credential State Machines issued. Application records can still contain sensitive values under other names. The gateway omits bodies for credential routes and for formats it cannot redact, including XML and multipart payloads. The recorder also omits a JSON or form body that is invalid or larger than 1 MiB. These controls do not remove arbitrary personal or business data from ordinary records. Use synthetic data for fixtures. Before sharing a request, downloaded body, or agent transcript, remove sensitive application data yourself. Preserve the environment ID, app version, request method, status, and sanitized error needed to reproduce the issue.

​

Clean up each copy of the data

Delete the environment when its task ends. Delete unneeded snapshots separately because snapshots can outlive their source environment. An environment already restored from a snapshot owns another copy of the app data. Recorded requests and audit events are kept separately from the environment. Deleting an environment does not delete those records. The API has no operation that erases a single request. State Machines publishes no retention period for recorded requests and audit events. Do not put data that must be deleted on a schedule into an environment. Remove local body downloads and copied credentials from the places where you stored them. Deleting a State Machines resource cannot remove files or transcripts outside State Machines.