What is market-scoped access control

Most enterprise software claims to support "row-level security." Most enterprise software then implements it as a UI filter, a query parameter, or a permission check that happens after the data is already in memory. These are not security boundaries. They are conveniences.

Market-scoped access control is the strict form: every query against the underlying data store is automatically filtered to the user's authorized scope before any data leaves the database. There is no path by which a user can retrieve unauthorized data, not even by calling the API directly with a different parameter.

For multi-market sales organizations, this is the single most important security property in the platform.

Why the UI is not enough

A UI filter is a convenience. The user clicks "India only" and the page shows India leads. That is helpful.

A UI filter is not a security boundary. The same user can:

• Open the browser developer tools and inspect the underlying API call.
• Modify the request to remove the market filter.
• Send the modified request directly and receive every market's data.

This is not a hypothetical attack. It is a five-minute exercise for anyone who has ever opened the network tab in Chrome. If the security model assumes users will not do this, the security model is wrong.

The same critique applies to permission checks that happen in the application server but after the data has been queried. A bug in the filtering logic, a misconfigured permission, or a query that bypasses the filter (because the developer forgot to apply it) returns data that the user was not authorized to see.

The fix is to push the filter to the data store itself. Every query, automatically, with no opt-out.

The five-layer defense-in-depth model

Real access control on enterprise lead data has five layers. Only one of them is the security boundary; the others are conveniences that exist for performance and UX.

Layer 1: User interface. Hides buttons, links, and form fields the user is not authorized to use. UX hygiene; never a security control. Bypass is a browser developer tools session.

Layer 2: API gateway. Coarse authentication. Is the JWT valid, is the user active, is the session current. Cheap reject for unauthenticated traffic. Not a market-scope check.

Layer 3: Application-level policy engine. Per-request policy decision. Is this user allowed to perform this action on this resource type. Returns allow or deny. The policy engine is the right place for "can this role view audit logs at all," but not the right place for "which markets can this user see."

Layer 4: Data access layer. Every query is automatically scoped to the user's market and team. The scope is applied as a server-side WHERE clause appended to every query against lead-related tables. This is the security boundary. Even if Layer 3 is bypassed, the data store refuses to return rows outside the scope.

Layer 5: Database role separation. The application user account at the database level has only the permissions it actually needs. Defense in depth: if application code is compromised, the underlying data is still bounded by what the application user can read.

A well-built platform implements all five. The boundary that matters is Layer 4. The others reduce the attack surface but do not constitute access control on their own.

Markets as a controlled vocabulary

Market is a tag on every lead. The tag values are a controlled vocabulary, not a free-text field.

The vocabulary is admin-editable per organization. Common values are country names (India, United States, Germany, France, Singapore), but the vocabulary is not restricted to ISO country codes. Continents (Europe, Africa, APAC), trade blocs (EU, GCC, ASEAN), and arbitrary business segments (Enterprise NAM, SMB EMEA) are all permitted.

Two properties of the vocabulary matter for access control:

It is set at ingestion, not at query time. Each connector's configuration declares how market is derived for incoming leads. Static (every lead from this connector is in this market), mapped (this column in the CSV is the market), or lookup (this attribute maps to this market via a table). Leads that cannot be confidently tagged are quarantined for admin review.

Changing a lead's market is a high-privilege operation. Once a lead is tagged, the market does not change silently. A super-administrator can reassign it, but the change is audited and triggers a re-evaluation of who can see the lead.

These two properties make market a stable security boundary, not a soft analytic attribute.

Composing scope: role + market + team

A real user has three scopes that compose:

• Role. Their base permission set: sales representative, team lead, regional manager, regional administrator, global head, super administrator, auditor, service account.
• Market. Zero or more authorized markets. Most users have one or two. Global heads have all. Super administrators have all (and the explicit ability to change other users' market scope).
• Team. Optional. Within a market, a user can also be bound to a specific team, in which case their queries are further filtered to leads owned by that team.

Composition is multiplicative. A team lead bound to (UAE inside-sales) sees UAE leads owned by the UAE inside-sales team. They cannot see UAE enterprise team leads. They cannot see Saudi inside-sales leads. The platform enforces both bounds at every query.

Delegated administration is also scoped

The same principle applies to administrative operations. A regional administrator bound to UAE can create and modify users, but only users whose market scope is a subset of theirs. They cannot create a user with global scope. They cannot modify a user bound to a different market.

This sounds obvious. Most CRMs do not enforce it correctly. A regional admin in HubSpot can typically see and modify users outside their scope unless every individual permission is configured manually. In a multi-market lead intelligence platform, the constraint is structural: the data layer refuses to write a user record whose scope exceeds the writer's scope.

What good looks like

Three questions to ask a vendor:

1. "Show me what happens when a user scoped to India calls your API for United States data." The right answer is the response is filtered to India. Not denied; just filtered. The user does not see an authorization error because they should not know United States data exists. The query simply returns India rows.

2. "What is your database role for the application?" The right answer specifies that the application database user has only SELECT, INSERT, UPDATE, DELETE on lead-related tables, not full superuser or schema-modification rights. Defense in depth.

3. "How is a lead's market set, and can a user change it?" The right answer specifies derivation at ingestion, quarantine for untaggable leads, and a separate audited operation for changing market after the fact.

If the vendor cannot answer all three concretely, the access control is decorative.

For how MegatronLead implements the data-access-layer boundary specifically, see market-based access control and security and compliance.