---
title: Privacy and security
description: Basic rules for data, access, and external actions.
reviewedOn: 2026-09-08
sourceRefs: [evidence-lab-methodology]
---

## Result

The project states which data and accounts may be used, where information may leave the device or organisation, who can approve access, and which actions need separate confirmation. Credentials and private evidence stay outside chats, repositories, and handover files.

| Data class                                              | Default treatment                                                                 |
| ------------------------------------------------------- | --------------------------------------------------------------------------------- |
| Public or approved training material                    | Use only for the stated task and retain source identity                           |
| Personal, confidential, unpublished, or client material | Use only with recorded authority, minimum scope, and an approved service          |
| Passwords, API keys, tokens, recovery codes             | Never place in prompts, source files, screenshots, logs, or commits               |
| De-identified examples                                  | Verify that content and metadata cannot reasonably identify the source before use |

## Actions

1. Identify the data owner, applicable organisational policy, approved account, service terms, storage location, retention rule, and permitted recipients.
2. Classify the case inputs and remove data that is not required for the accepted outcome.
3. Grant the minimum file, account, connector, network, and write permissions needed for the current step.
4. Keep passwords, keys, tokens, recovery codes, and secret values in an approved credential store, never in chats or instruction files.
5. De-identify training and diagnostic examples and inspect both visible content and file metadata.
6. Verify the active account, workspace, target, and recipient before reading private data or publishing, sending, uploading, or editing externally.
7. Require separate confirmation for destructive, irreversible, public, account-wide, credential, purchase, and access-broadening actions.
8. Record how access is revoked and test revocation with a safe account or component when practical.

## Check

The project record answers what data is permitted, why it is needed, where it is stored or sent, which account and workspace are active, who has access, how long it is retained, which actions need confirmation, and how access is revoked. Repository and output checks reveal no credentials or unapproved private material.

## If it fails

Stop the affected operation and preserve the current state without copying the sensitive value into a report. Revoke or rotate exposed access through the authorised owner, remove unauthorised copies through an approved process, and consult the data owner or security specialist before resuming.

**Next:** [Troubleshooting](/en/reference/troubleshooting/).