IP allow-list
Status of org-level IP allow-listing for dashboard and API traffic.
IP allow-list
Status: roadmap. Org-level IP allow-listing for dashboard sessions and API traffic is not generally available as a self-serve control. This page exists so you can plan around the current state honestly.
What works today
You can constrain who reaches AACsearch by combining controls that are generally available:
| Control | Where it lives | Page |
|---|---|---|
| Origin allow-list (browser keys) | Per API key | Origin allow-list |
| Scope on every API key | Per API key | API keys |
| Per-key rate limit | Per API key | API keys |
| Tenant filter via scoped token | Per session / per user | Scoped tokens |
| SSO / SAML enforcement | Per organization (Enterprise) | SSO and SCIM |
| 2FA enforcement | Per user | Best practices |
For most threat models, origin allow-list + tight scope + 2FA on the dashboard covers what an IP allow-list would have covered.
What does not work today
- A per-organization "block all dashboard sign-ins outside CIDR
203.0.113.0/24" toggle. - A per-API-key "only accept calls from IPs in this list" toggle.
- A per-user "I can only sign in from these IPs" preference.
If you set up something that looks like one of these (e.g. via a CDN WAF in front of app.aacsearch.com), you are routing traffic that we cannot reach to bypass via a different region, and you may inadvertently block our own health checks. We don't recommend it.
What works for self-hosted / private deployments
If your compliance requirement is "must be reachable only from our office network", the supported path is a private deployment with the network controls on your side — front the cluster with your own firewall, VPN, or IP allow-list at the load balancer. See Enterprise overview.
A managed AACsearch tenant on the shared cluster cannot be IP-restricted today.
Workarounds available now
- Dashboard hardening. Require 2FA for every member of the organization. Combined with SSO enforcement (Enterprise), the dashboard requires a possession factor on top of the IdP.
- API-key origin allow-list. For browser-facing keys, restrict to your domains. See Origin allow-list.
- Service-account isolation. Run your ingest/admin workers from a known set of egress IPs and review the audit log for
ipAddressvalues that don't match. - Custom WAF in front of your own caller. If your worker is the only thing calling AACsearch, your own outbound network controls determine which IPs reach us — you don't need us to enforce that.
Roadmap
- Dashboard sign-in IP allow-list. Block dashboard sessions whose IP is not in an org-level CIDR list. Expected to ship after SAML enforcement.
- API-key IP allow-list. Per-key list of CIDRs, evaluated alongside the origin allow-list.
- Audit-log alerting on IP anomalies. Dashboard alert when an admin action happens from a previously unseen IP.
If any of the above is a buy-blocker for you, please email sales@aacsearch.com so we can prioritize. We will not announce them as generally available on this page until they actually are.
See also
- Origin allow-list — the closest existing control
- Best practices — what to do today
- Enterprise overview — when private deployment is in scope