No. Because identity comes from the session someone already has, switching a system from audit-only to enforcing doesn't log anyone out or interrupt anything in progress. The next request from a restricted location is simply the one that gets denied.

By default, the proxy fails open: the request is still allowed, and a location_lookup_failed event is written to the audit log so the outage is visible and distinguishable from a normal allow. The same applies to GeoIP provider errors. For your most sensitive resources, you can configure a fail-closed override instead, so access is blocked rather than allowed during an outage.

The Location Service reads the most recent location record for that user across every source that's submitted one, whether that's the proxy's own IP geolocation on each request or another signal you wire in, like an HR feed, a travel desk, or a badge system. Recency wins, regardless of source.

If it's a system type we already support, like Bitbucket, SonarQube, Artifactory, or Bamboo, you register it yourself from the admin console: pick the type, add your connection details, and it's live in minutes. If it's a system we don't support yet, our team builds that connector for you as part of onboarding, so you're never the one writing integration code.

Yes. Every new system starts in audit-only mode: identity and location are resolved and logged, but nothing is blocked. You review real traffic and country distributions, then flip that specific system to enforcing when you're confident.

Rules support exact resource matches and wildcards. The most specific match wins, so a tightly-scoped rule on one repo can be stricter than your org-wide baseline even though the baseline is default-allow.

Today that's a single admin role, covering rule management and the audit log together. Per-team scoping for larger organizations isn't available yet. Admins sign in through a built-in identity provider that can also connect to an existing identity provider (like Okta, Microsoft Entra ID, Ping Identity, JumpCloud, or Cisco Duo), so you don't need to stand up a separate account system.

API tokens and other connection details are encrypted and held in a dedicated secrets service, never as plain text. Rotating a credential automatically re-runs the connectivity check for that system.

Just enough to enforce policy: an identity resolved from the session or token your system already issued, a location record with its source and timestamp, and the resulting access decision. No passwords, and nothing beyond what's needed to make and log that decision.

No. It runs self-hosted, inside your own infrastructure. You're not depending on a third-party cloud vendor to enforce your own compliance obligations.