For AI service providers · Guide
How to separate client data in AI agents
Separate client data at the workspace and connected-account level, then test the boundary. Use one Team workspace per client, check membership and attach only the intended client context. In Agentic Workers, client integration invitations target one agent in Agent only mode. Names and prompt instructions alone are not access controls.
By Agentic Workers Team · Published · Updated
Responsibilities and evidence
Agree on the owner and retain a safe evidence reference for each responsibility.
- Service scope
- Provider drafts; client accepts. Evidence: agreed output and stop conditions.
- Account ownership
- Client and provider confirm owners. Evidence: account inventory without secret values.
- Configuration
- Provider sets up the intended workspace and agent. Evidence: reviewed settings.
- Action review
- Named reviewer checks supported actions. Evidence: request and decision.
- Acceptance
- Client or delegated reviewer checks the result. Evidence: accepted artifact.
- Exit
- Account owner and provider remove access. Evidence: handoff and denied-access check.
1. Inventory every source of context
List files, knowledge, agent instructions, memories, tool accounts and destination channels. Identify any shared organization connection. Remove the previous client’s examples when reusing a procedure.
2. Use two fictional clients to test
Create distinct reference facts and test accounts for Client A and Client B. Ask each agent for its own fact, then for the other client’s fact. Inspect account selection and source references. Investigate any unexpected access before using client data.
3. Test a change in access
Remove a test member, revoke a portal link and disconnect a test account separately. Verify the intended denial. Keep the result with the setup record and repeat the checks when shared context or membership changes.
Example provider workflow. Adapt it to the client’s agreed scope.
- 01
Step 1: Inventory every source of context
- 02
Step 2: Use two fictional clients to test
- 03
Step 3: Test a change in access
Fit and limitations
- Good fit
- Providers applying this process to an agreed client service.
- Poor fit
- Treating this checklist as an automatic product feature or a substitute for a client agreement.
- Known limits
- These are operating recommendations. Test each supported product path in the target workspace and plan. Examples are not performance, pricing or security benchmarks.
Sources and evidence
Documentation establishes the scope of a claim. It does not replace an acceptance test in your client’s environment.
| Source | What it supports | Checked |
|---|---|---|
| Team workspace setupProduct documentation | Teams organize agents and connected tools by workspace. Verify membership and the active workspace before setup. | |
| Customer portal operating notesProduct documentation | Upload and app-connection invitations are scoped to a selected agent. Revoking an invitation is separate from disconnecting an account. | |
| Connect tools to a Super AgentProduct documentation | Authorization requirements depend on the provider. Verify the actual account and resource access with a read-only request. |
Questions providers ask
Who is responsible for the result?
The provider names an operator; the client names the person who can accept the deliverable. The platform does not replace those responsibilities.
What evidence should we retain?
Keep the source date, workspace and agent, expected output, review decision and artifact reference. Exclude credentials and unnecessary personal data.
When should we stop and review?
Stop when the account, recipient, output or permissions differ from the agreed scope, then resolve the exception before continuing.
Set up one client service
Set up the client workspace, connect its tools and review the first deliverable. Use a tested delivery path, such as Telegram, so the client can receive work in chat. Track operating costs and review effort before pricing a recurring service.
Sign up now