Conditional Access and Routing

Published
Length
3 min read

Luis Felipe Dias

All posts

You set up conditional access and routing by pairing identity rules with network path rules. These rules check user identity and device state before sending traffic to a database or server. Most teams build this setup using their identity provider and cloud network tables. Still, broad roles often let users run risky commands after they log in. How conditional access and routing works in practice This setup relies on two separate layers working together during login. First, the identity syste

Conditional Access Policies + SNI-Based Routing Security: the complete guide

Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.

Free white paper. No spam. Unsubscribe anytime.

You set up conditional access and routing by pairing identity rules with network path rules. These rules check user identity and device state before sending traffic to a database or server. Most teams build this setup using their identity provider and cloud network tables. Still, broad roles often let users run risky commands after they log in.

How conditional access and routing works in practice

This setup relies on two separate layers working together during login. First, the identity system checks who the user is and where they are. It looks at group membership, device health, and IP address locations. If the user passes these checks, the system grants a session token.

Second, the network layer reads that context to pick the right path. It sends the user to a read replica or a production host. For example, an on-call engineer might route to a primary database during an incident. The same engineer routes to a read-only copy during normal work hours.

Teams also use this pattern to split traffic by region or workload type. Support staff route to a restricted app tier while developers reach staging servers. Each network rule matches a specific role to a specific backend destination.

What native network and identity rules solve

Native rules do a great job of blocking bad logins at the front door. They stop unknown devices and stolen passwords from reaching your private network. They also keep normal users away from hosts they do not need to use. This shrinks the number of people who can reach sensitive servers.

Network routing also helps teams keep production traffic stable and fast. By sending heavy reporting queries to a replica, you protect the main database. You can also keep regional teams inside their own local data centers.

Conditional Access Policies + SNI-Based Routing Security: architecture patterns and best practices

Continue reading? Get the full guide.

Free. No spam. Unsubscribe anytime.

Where login checks and routing rules fall short

The main gap starts the moment a user passes the login check. Conditional access and routing only decide who logs in and which host they reach. Once the network opens the path, the system stops inspecting the session. It cannot see what individual SQL statements or shell commands do in flight.

A user routed to a production database holds full permissions for that role. They can still run a broad table read or drop an important table. Native network routes also cannot mask sensitive fields in query results. If a table holds emails, phone numbers, or card numbers, the query returns them.

Auditing is another major blind spot for network and identity tools. Identity logs show that a user logged in at a certain time. Network logs show that packets moved between two IP addresses. Neither log shows the exact query ran or who approved a risky change. To control live sessions, teams must inspect commands and mask data in flight.

Add runtime guardrails and masking beside your databases and APIs

Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.

Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.

Frequently asked questions

What is the difference between conditional access and network routing?

Conditional access checks user context like device health and location before login. Network routing directs that approved traffic to a specific server or database host.

Can network routing stop a user from running a bad SQL query?

No, network routing only picks which database host receives the user traffic. It does not read or block individual SQL statements inside an active session.

How do teams protect sensitive data after a user logs in?

Teams add command checks and data masking on top of login rules. Masking rewrites matched fields like emails, phone numbers, and national IDs in results.

Save the open-source gateway.

hoop is MIT-licensed infrastructure for controlling how AI agents reach production data. Star hoophq/hoop so you can inspect it, deploy it, or share it when your team starts governing agent access.