Many organisations have strong network boundaries around infrastructure but weaker boundaries around the control plane that manages users, credentials and permissions. An attacker who reaches that control plane may be able to change access across the environment without touching a database directly.
Place policy where authority is exercised
A network rule can matter when a role is assumed, an administrator signs in, a tenant integration provisions members or a service account calls an API. Apply the rule at the operation that matters and link the decision to identity and resource context.
WebFrolic documents allow and deny lists for IP addresses and CIDR ranges across roles, identity classifications, tenants, SCIM integrations, tenant integrations, application access, service accounts and API keys. This breadth is useful only if the rule is evaluated at the intended enforcement point.
Use allow lists with discipline
An allow list can be powerful for a stable server integration and painful for a team whose egress ranges change frequently. Document approved ranges, owners, environments and the change process. If an exception is necessary, scope it narrowly and record when it must be removed.
Do not assume an IP address uniquely identifies a person or workload. Offices and proxies serve many users, while attackers may use distributed proxy pools. Network filtering is one signal in a layered policy, not a substitute for authentication, least privilege or monitoring.
Keep tenant and identity rules distinct
B2B tenants may have their own network requirements, while platform operators need separate rules for privileged roles and integrations. One broad policy can be too restrictive for tenants or too permissive for platform management. Make ownership and scope clear in the configuration.
Test both allowed and denied cases. Confirm which identity class is evaluated, whether role assumption is restricted independently from sign-in, and how the request behaves when its source address falls outside the permitted range.
Monitor decisions and failures
Record the policy that matched and its result without collecting unnecessary request data. Repeated denials may indicate misconfiguration, infrastructure change or an attack. Give operators enough context to distinguish those cases and a safe route to update the rule.
Review rules after application, tenant or deployment changes. A rule that remains saved but is no longer attached to the intended operation creates a false sense of protection. Verify active enforcement as well as configuration state.
In practice
Map every sensitive operation to its network enforcement point.
Separate platform, identity-class, tenant and integration policy.
Document approved CIDRs and exception-removal steps.
Test allow/deny outcomes and monitor unexpected denials.