The Identity Control Plane
One identity.
Every access point.
Your team uses AWS, GCP, Azure. Your app has roles and permissions. Your services need protection. Today that's 6+ systems. AuthFI makes it one.
Available on Free and above. See pricing
The control plane
One place to decide. Four planes to enforce.
A control plane is the layer that holds policy and configuration — who is in which group, what that group is allowed — and pushes those decisions out to wherever access is actually enforced. The enforcement itself lives in the data plane: the SDK on your app, the cloud's IAM, the kernel on your servers, the tunnel on your network. AuthFI is the control plane for all four. You change one thing in one console; the change reconciles to every enforcement point.
- One set of roles, one audit trail. App, cloud, service and network access are managed from the same dashboard instead of 6+ disconnected systems.
- Separation of concerns. The control plane never sits in the request path — an enforcement point that loses contact keeps enforcing its last-known policy.
- The CTO payoff: the access model becomes one object you reason about, not a diff you chase across four products.
App AccessSDK middleware checks JWT permissions
12.4K reqs/hr
Cloud AccessAWS + GCP + Azure role mappings
4 clouds
Service AccesseBPF kernel-level enforcement
6 services
Network AccessWireGuard mesh + eBPF controls
2 nodesAll four access layers, one dashboard. One set of roles. One audit trail.
Group: devops
App layer → role: "admin"
permissions: [deploy:*, manage:infra]
Cloud layer → AWS: AdministratorAccess
GCP: roles/owner
Azure: Owner
Service layer → full access to all services
MFA: required for production
Network layer → SSH: sudo on all servers
WireGuard: full mesh access
// One group change. All four layers updated instantly.Define once. Enforce everywhere.
Add a user to a group. Four planes converge.
Membership is declarative: you state the desired access, the control plane reconciles
the world to match it. Add someone to devops and they instantly get app permissions,
cloud IAM roles, server SSH access, and network policy — because the group is the single binding
that fans out to all four enforcement points. Remove them, and the same fan-out runs in reverse.
- The problem it removes: drift. No more granting access in Okta, then AWS, then the bastion, then the VPN — and forgetting one on the way out.
- Mechanism: one group → app role, cloud role mappings, service access, and network policy, applied together rather than ticket by ticket.
- The payoff: a joiner-mover-leaver change is one edit with a deterministic blast radius, not a multi-system runbook.
Metadata, not secrets
It carries the config. It never carries the keys.
A well-built control plane holds metadata and configuration — group membership, role mappings, policy — and deliberately not the credentials or PII those decisions gate. That boundary is what shrinks the blast radius: the layer you administer is not the layer that holds the secret a thief actually wants. Enforcement points fetch or mint their own short-lived credentials at the edge of the request, so the standing material that can be stolen approaches zero.
- Group & role definitions
- Cloud IAM role mappings
- Service & network policy
- Audit metadata — who, what, when
- Long-lived cloud access keys
- End-user passwords or PII
- Private SSH / WireGuard keys at rest in the request path
- Anything an attacker could replay offline
Enforcement, per plane
One decision, spoken in four protocols.
The same group decision is delivered to each plane in the language that plane already understands — so AuthFI sits beside your stack, not on top of it. No agent rewrites your app, no proxy fronts your cloud; each enforcement point keeps its native mechanism and AuthFI keeps it in sync.
SDK middleware reads the signed token; the app never holds a password.
A group maps to an IAM role; the cloud mints short-lived credentials on assume.
Policy is enforced at the syscall boundary — no sidecar, no app change.
Membership becomes a peer entry; revocation drops the tunnel.
App access checks JWT permissions in SDK middleware; cloud access maps a group to an IAM role and lets the provider mint short-lived credentials; service access is enforced in the kernel via eBPF; network access is a WireGuard peer governed by the same policy. Four mechanisms, one source of truth.
One audit trail
If it isn't auditable in one place, it isn't governed.
Four separate access systems mean four separate log formats — and an access review that has to correlate them by hand. Because every grant flows through one control plane, every change lands in one audit trail with the same shape across app, cloud, service and network. The question an auditor actually asks — who had access to what, and when did it change? — is a single query, not a four-way reconciliation.
- Joiner-mover-leaver is captured as the group change itself, so the trail explains why access existed, not just that it did.
- SOC 2 / access reviews read one consistent record instead of stitching four exports together.
- The payoff: the evidence your compliance program needs is a by-product of how access is granted, not a quarterly fire drill.
role admin → grantedAWS AdministratorAccess → mappedall services → allowed · MFA prodWireGuard mesh → joinedThe stack it collapses
Replaces your entire access stack.
Each row below is a product you license, integrate and audit on its own today. Under one control plane they become one bill, one integration, and one trail — six systems folded into one.
| Layer | AuthFI | Without AuthFI |
|---|---|---|
| App login | Core | Auth0 ($2K/mo) |
| SSO + Directory | Core | Okta ($1.5K/mo) |
| Cloud IAM | Connect | AWS IAM + GCP IAM (ops cost) |
| Service mesh | Agent (eBPF) | Istio + Envoy |
| SSH access | PAM | Teleport ($3K/mo) |
| Audit trail | Built-in | 4 separate log systems |
Get started
Ready to get started?
Free for 5,000 monthly active users. No credit card required.