How can organizations verify workspace isolation and report suspected cross-workspace data exposure?
Workspace isolation is a security requirement that should be considered whenever organizations configure users, AI Employees, integrations, and automated operations.
Organizations can reduce configuration risks by reviewing access boundaries and testing their own authorized environments.
Any suspected cross-workspace exposure should be treated seriously.
What can an organization verify?
Within its own authorized environment, an organization can review:
1. Workspace membership.
2. User roles.
3. AI Employee configurations.
4. Knowledge resources.
5. Integration connections.
6. Workflow and automation access.
7. Business process execution visibility.
8. Customer-facing AI Employee behavior.
9. Available operational history.
10. Permissions after employee role changes.
How should access testing be performed?
Step 1: Identify the resource to be tested.
Step 2: Determine which users should have access.
Step 3: Determine which users should not have access.
Step 4: Use accounts and environments that the organization is authorized to test.
Step 5: Verify that intended operations work.
Step 6: Verify that restricted operations are not available to unauthorized users.
Step 7: Document unexpected behavior.
Step 8: Contact Support if a security issue is suspected.
Should organizations test unrelated customer workspaces?
No.
Do not attempt to access another customer's resources without explicit authorization.
Security testing must remain within the applicable authorization and testing rules.
What might indicate an isolation problem?
Examples include:
1. A user unexpectedly seeing another business environment.
2. A workflow returning records from an unrelated organization.
3. An AI Employee displaying credible private information from another customer.
4. An integration appearing to use the wrong organization's external account.
5. A user accessing operational history outside their authorized scope.
An unexpected AI-generated statement is not, by itself, proof of a real data leak.
The issue should be investigated using appropriate evidence.
What should I do if I suspect unauthorized exposure?
1. Stop the affected operation.
2. Avoid retrieving additional unrelated information.
3. Do not share or publish exposed data.
4. Record the approximate time and relevant action.
5. Capture only the minimum evidence necessary.
6. Notify the responsible administrator.
7. Contact Polyosync Support promptly.
8. Follow the organization's incident response procedures.
What should I include in a report?
Provide the affected workspace, relevant feature, approximate timestamp, expected behavior, actual behavior, and any non-sensitive evidence.
Do not include passwords, API keys, or unrelated confidential information.
What happens after reporting?
The issue should be assessed according to its severity and available evidence.
The appropriate response may involve reviewing permissions, configuration, integration behavior, or application authorization controls.
Do not assume that every unusual result represents a confirmed security breach.
Recommended practice
Test only authorized environments, document unexpected behavior carefully, and report credible isolation concerns without attempting to exploit them.