You've created a workspace for Team North. Before handing it over, check whether North can do its work without reading Team South's records or changing South's configuration.
Answer that with a small acceptance suite. Test the administrative boundary and the agent runtime boundary separately. A successful test with a platform administrator's credentials tells you little about what a workspace-scoped developer or agent can do.
State the boundary you are testing
Dome's scope model distinguishes organization, tenant, workspace, and agent scope. A tenant is a data-isolation boundary; a workspace organizes operations within a tenant. Neither label is a substitute for inspecting the permissions and resource visibility that apply to the caller.
Write a test statement before creating fixtures:
Team North's workspace-scoped developer can inspect the North configuration needed for development, cannot administer South, and cannot use North's agent credentials to call a resource outside the agent's authorized path.
That statement contains three different assertions. Keep their results separate. It also does not claim that an organization administrator should be unable to see both teams. Higher-scope administrative grants intentionally cascade.
Use fictional resources and synthetic payloads. The acceptance suite should not need real customer data to demonstrate isolation.
Build a scope matrix
Create a permitted fixture and a forbidden fixture for each boundary. Record the credential's actual scope, not just the shell's current workspace selection.
| Caller and operation | Positive fixture | Negative fixture | Evidence to keep |
|---|---|---|---|
| North workspace developer reads configuration | North configuration allowed by the role | South configuration outside the grant | Principal, effective scope, requested resource, result |
| North-scoped management API client changes configuration | A change within its explicit permissions | The same operation outside that scope | Permission set and response, with credentials removed |
| North agent calls a tool | Authorized North resource and action | South resource without authorization | Agent identity and relevant call evidence |
| Tenant-scoped operator reviews workspaces | Workspaces covered by that tenant grant | A resource belonging to a different tenant without a grant | Tenant context and absence of unintended data |
| Organization administrator performs onboarding | Expected cross-workspace administrative access | No negative assertion inferred from this broad principal | Explicit note that this is an administrative control case |
Do not require every negative test to return the same HTTP status. A system may deny an operation, hide an object, or return no matching records. The acceptance condition is that the caller neither receives protected data nor performs the forbidden change. Record the actual response and investigate unexpected differences.
Check the credentials before trusting the result
Before running the matrix, inspect the test principal's memberships and inherited permissions. A developer who also has an organization-level administrative grant is not a useful least-privilege test subject.
Likewise, changing CLI context selects a destination; it does not remove the privileges of the credential making the request. Use a dedicated, appropriately scoped test principal or API key. Follow the permission reference when selecting its grant.
Keep credentials out of the evidence packet. Store a stable test-principal identifier and permission description instead. Reviewers need to reproduce the conditions, not receive a copy of the secret.
Run the positive case first. If it fails, the negative case might be passing only because the setup is broken. Then vary one dimension at a time: workspace, tenant, resource, or requested action. That helps you see which change caused a failure.
Test the whole intended access path
An agent call involves runtime authority, resource exposure, and the controls on the connection. Use the tool access matrix for those decisions; do not rebuild its full explanation in the scope suite.
Scope isolation inside Dome also does not remove a direct route to the backend. If both teams share a backend credential outside Dome, review that path separately. The acceptance report should name the path it actually exercised.
After onboarding, rerun the suite when membership, scope inheritance, resource exposure, or management credentials change. A one-time screenshot of a workspace selector is not lasting evidence of isolation.
Say exactly what the tests showed
The completed record should include the tested scopes, principals, fixtures, expected and observed results, configuration revision, date, and reviewer. List any untested paths explicitly.
Write the conclusion in terms of the tests: North's developer could read the intended configuration and couldn't read or change South's. List untested routes separately. That tells the next operator more than a general claim that the teams are isolated.