Protecting client data before connecting an AI workflow

Suppose a professional services team wants to prepare an onboarding checklist from an approved agreement. The model may need the services, dates, and delivery obligations. It may not need unrelated financial records, identity documents, or the client's entire correspondence history.

I would define the required fields before enabling broad retrieval. For each field, record its source and purpose. If the workflow cannot explain why it needs a category of information, keep that information outside the initial scope.

This does not mean deleting information the business must retain. It means limiting what this particular workflow receives. Retention in the source system and disclosure to a model are separate decisions. Keep those decisions visible so that a convenience feature does not silently expand the data boundary.

List the source application, integration service, model provider, storage service, search index, logs, monitoring platform, and review interface. Record whether each component receives full content, selected fields, identifiers, or metadata. Include temporary files and failed-job storage.

For external providers, inspect the current contract and documentation for the exact product and account configuration. Verify retention, training use, region, subprocessors, deletion, and administrative controls. Do not apply a statement about one consumer product to a different business API.

I would keep this inventory next to the architecture and revisit it when a component changes. A new tracing tool or document parser can introduce another copy of client material. A small implementation change can therefore require a fresh data-flow review.

A search result should be filtered by the caller's authorized scope before it reaches the model. I would use the same client and matter boundaries that the business has approved, with enforcement in the application or data layer rather than relying on a prompt to hide unauthorized results.

Test this through every path. The main interface may apply a filter while a background job, tool endpoint, or debugging screen does not. Include a test in which one authorized employee attempts to retrieve a document belonging to a client they cannot access.

Also test changes in access. If an employee moves off an engagement, the search index and any cached permissions need to reflect the change. A snapshot of yesterday's permissions should not become a permanent grant. The implementation must define how quickly revocation takes effect and how that behavior is verified.

A document can contain instructions aimed at the AI system. Anthropic's documentation describes indirect prompt injection through third-party content such as emails, webpages, documents, and tool results. That is why a document's text should not be treated as authority to change the workflow's permissions or goals. Anthropic's prompt-injection guidance

My design recommendation is to keep trusted instructions separate from retrieved content and to constrain what downstream tools can do. If the task is to extract onboarding fields, the model should not receive a general-purpose tool that can send arbitrary files to arbitrary addresses.

Add a hostile test document to the evaluation set. It might ask the system to ignore its instructions or copy other clients' records into the answer. Passing that test does not prove immunity to every attack. It provides one repeatable check while permission controls limit the consequences of model error.

Use server-side credentials with the narrowest practical permissions. The model can request a permitted operation through a defined interface; it should not need to see the raw credential. Separate read access from write access when the platform allows it.

Record who can rotate credentials, how rotation is tested, and what happens when a credential expires. A failed authorization should produce an explicit stopped state. It should not lead the workflow to search for another credential or broaden access on its own.

Review administrative access separately from ordinary workflow access. A support engineer may need diagnostic information without needing the full client document. Build that distinction into the operating process so troubleshooting does not become a reason to expose everything.

I would log the workflow identifier, source record reference, version, action, policy result, reviewer, and execution receipt. Whether the full prompt or document body belongs in a log depends on the approved data policy and the diagnostic need.

A useful operational record can often point to the source rather than duplicate it. If detailed payload capture is necessary during testing, restrict its access and retention and use sanitized material where possible. Do not assume that a monitoring platform is an acceptable destination for confidential content merely because it is useful to developers.

Make deletion behavior explicit. If the original document is removed, identify which derived copies must also be removed or retained under an applicable requirement. Search indexes, caches, failed jobs, and diagnostic exports need owners. A delete button on the source application does not establish what happened elsewhere.

Use a small matrix of users, clients, document states, and actions. Include permitted access, denied access, revoked access, missing ownership metadata, and a malformed document. Verify the resulting behavior and retain the test evidence without unnecessary client content.

I would also test failure paths. If the permission service is unavailable, does the workflow stop or continue? If a record has no client identifier, is it rejected or placed in a shared bucket? If a source document changes, can the reviewer tell which version produced the proposed output?

NIST's AI RMF includes privacy and security evaluation within a broader lifecycle approach. It is a framework for organizing risk work, not a certificate that an implementation is safe. NIST AI RMF Core

The release checklist should identify who reviews access, who handles incidents, who approves new data sources, and who can pause the workflow. Changes to vendors, retention settings, or client requirements should trigger a review of the relevant controls.

Keep a tested manual path for work that cannot proceed safely. If the system cannot establish permission or document identity, an operator needs a clear way to resolve the case. Quietly skipping it or guessing the answer creates a different problem for the client team.

The practical goal is a data path you can explain and test. Before connecting a workflow, identify its permitted information, its allowed actions, and its evidence of completion.