---
title: "Verify one tenant cannot read another tenant private record"
description: "Use two isolated test organizations and a known private record URL to check tenant isolation across page content, navigation, and application responses."
canonical_url: "https://vostride.com/agent-library/authorization/cross-tenant-record-denial.md"
md_url: "https://vostride.com/agent-library/authorization/cross-tenant-record-denial.md"
content_kind: "recipe"
topic: "authorization"
---

# Verify one tenant cannot read another tenant private record

Use two isolated test organizations and a known private record URL to check tenant isolation across page content, navigation, and application responses.

## Risk

Tenant isolation must remain intact when a user knows a record identifier. This recipe uses entirely test-owned organizations and verifies a narrow authorized boundary without searching for or touching unrelated customer data.

## Fixtures

- Two test organizations with separate accounts and no shared membership.
- A private record in the second organization containing a unique title and secret-free description marker.
- A permission hook that queries the application as the first fixture account and reports the response classification.

## Steps

1. Sign in as the first organization account and verify its organization name and an owned record are visible.
2. Open the exact second-organization record URL provided by setup; verify the documented denied or not-found page.
3. Verify the foreign title, description marker, attachments, and organization breadcrumb do not appear in the response view.
4. Return to the first organization dashboard and verify its normal record remains accessible, proving the failure was scoped to the foreign resource.
5. Run the permission hook as the first account and verify the application refuses the foreign read with the documented status class.

## Expected results

- The foreign private record is inaccessible through the known direct URL.
- Denial content contains no protected record fields beyond what the product deliberately permits.
- The first account retains legitimate access inside its own organization.

## False-pass traps

- A missing navigation link does not prove a known foreign identifier is denied.
- A general application outage could make both allowed and forbidden reads fail, so the owned-record control is necessary.

## Cleanup

- Delete both run-owned records and organizations if setup created them.

## Use with agent-qa

Adapt this test design to your application's acceptance criteria and configured target using the [recipe execution guide](/agent-library/software-factory/turn-a-recipe-into-an-agent-qa-test.md). External fixture setup and non-UI checks require your own supported hooks or test tooling. Validate the authored test, execute it, and inspect the completed evidence; this recipe is not a recorded test result.

## References

- [agent-qa test](/docs/agent-qa/configuration/test.md)
- [agent-qa hooks](/docs/agent-qa/guides/hooks.md)
- [agent-qa auth state](/docs/agent-qa/guides/auth-state.md)

- [Authorization and permission QA recipes](/agent-library/authorization.md)
- [Software factory QA library](/agent-library.md)