SAG / ARCHITECTURE NOTE

Why Authorization Checks Are Needed Even When the Company Name Appears in the Tenant Path

Use customer paths for navigation, but have the server authorize access to data. A company name in the URL does not replace authentication. If changing an identifier lets someone read other data, a separate menu is not a security boundary.

Download Markdown

What Does Separating Paths and Permissions Mean?

Customer paths are used for navigation, while the server authorizes access to data. This note considers the separation of paths and permissions in terms of the responsibilities for input, transformation, and output, rather than as a feature name. To trust an analysis result, it must be possible to trace what data was received, what was checked, and how far the conclusions can go.

Why Is This Technology Needed?

A company name in the URL does not replace authentication. If changing an identifier lets someone read other data, a separate menu is not a security boundary.

Design Principles and Data Flow

Check the account, organizational membership, and resource ownership together, and apply the same controls to original-file downloads. Hiding something on screen is not an authorization check.

Account authentication → Tenant and resource authorization → Permitted data

Each stage should not describe the success of the preceding stage as the achievement of the next. Keeping records of data identifiers, periods, and validation status makes it possible to locate where omissions and errors occurred and determine what needs to be checked again.

Connection to the SAG Architecture

SAG customer menus use tenant paths, while data queries check account permissions. Public trials and customer spaces are kept separate.

SAG’s operational value lies in connecting these relationships to pages and questions, comparison results, and improvement tasks. Instead of only reading numbers, customers can review both what needs to be strengthened and the rationale for decisions. Patterns that require additional application should be interpreted within the scope of the relevant paragraph.

Illustrative Example and Evaluation Criteria

For illustration, changing the customer name in the URL must not provide access to that company’s data. The criterion is whether the server rejects the request, not whether the menu is hidden.

The example above is intended to explain the structure and calculations; it is not measured performance from a specific customer. In an actual report, the selected period, subject, observation conditions, and original records must be linked so that the same assessment can be checked again.

Practical Verification Checklist

Flow stageItem to verify
Account authenticationReject requests for another tenant
Tenant and resource authorizationCheck download permissions
Permitted dataDistinguish authentication from organizational membership

Check that the same meaning is maintained not only for normal inputs, but also for empty data, duplicate data, and data with different conditions. Connecting verification items to completion criteria can reduce the gap between a feature description and actual operations.

Limitations and Points to Consider When Applying It

RLS in the database and permissions in the application have different scopes. The actual deployment roles and bypass conditions must be checked separately.

Research and Official Documentation

External sources provide background on the design topic above; they do not certify every SAG implementation or customer outcome. The interpretation of this note and its illustrative example are based on SAG’s operational structure. Materials checked: 2026-10-06.

Further Reading and Feature Information

How to Explore This Technology Further

Review tenant permissions, job retries, caching, and approval history.

Articles