AuthFI Agent

Identity at the kernel.
Zero code changes.

eBPF intercepts HTTP traffic at the kernel. Validates JWT, checks roles, enforces MFA per route. ~45us overhead. No sidecars, no proxies.

Available on Pro and above. See pricing

Start free Read the docs

The mechanism

A verified program on the kernel hook path.

eBPF lets a sandboxed program run inside the Linux kernel on a defined hook — at the socket layer (sockops/sk_msg), the traffic-control classifier (clsact), or XDP at the driver. Before it ever loads, the in-kernel verifier walks every path to prove the program halts and touches no memory it shouldn't, then the JIT compiles it to native instructions. The AuthFI agent attaches there, reconstructs the HTTP request from the socket stream, validates the JWT, checks roles, and returns allow/deny — in the kernel, on the data path, with ~45us overhead.

  • No SDK, no app change: the workload binary is untouched — enforcement lives below it, not inside it.
  • No sidecar, no proxy: packets aren't re-routed through a userspace hop, so there's no extra TCP handshake or second copy of TLS to operate.
  • BPF maps carry policy and decisions between kernel and userspace, so the control plane updates rules without reloading the program.
  • The verifier is the safety contract: a program that could panic the kernel is rejected at load, not at runtime.
Where the program attaches
XDP
Driver / NIC Earliest hook, before sk_buff allocation. Drop or pass at line rate.
TC (clsact)
Traffic control Ingress + egress classifier on the qdisc. Inspect the full L3/L4 frame.
sockops / sk_msg
Socket Fires on connect/accept and on sendmsg. Identity is bound per-socket.
cgroup/skb
cgroup v2 Scopes enforcement to a pod or service without touching the app.
Loaded only after the in-kernel verifier proves termination & memory safety.
Per-request decision
method + pathGET /api/patients/123
JWT (RFC 7519)exp, iss, aud — signature verified
roles claim["doctor"]
mfa_verifiedtrue
decisionallow · ~45us
A request with no token, an expired exp, or a missing role never reaches the app.

Per request, per route

It reads the request, not just the packet.

Network policy stops at L3/L4 — IPs and ports. The agent parses the HTTP request off the socket stream and decides on method + path, the verified JWT, its roles claim, and mfa_verified. That's how GET /api/patients/123 for alice is allowed while a tokenless GET /api/patients is denied — the same identity context your app would check, enforced before the app sees the byte.

  • JWT (RFC 7519) is verified for signature, iss, aud and exp on the data path — a forged or stale token is a deny.
  • The problem it removes: auth logic scattered across every service in every language. One enforcement point, one place to audit.
  • The payoff: a legacy app you cannot recompile gets per-route MFA and RBAC without a single line of new code.

Policy model

Declarative rules. Ship them in shadow first.

Policy is route plus identity predicate — method, path, required roles, required groups, and an MFA flag. Run it in monitor mode first so it only logs what it would have blocked; flip to enforce when the access log is clean. No flag day, no risky cutover — the same artifact validated in monitor is the one that enforces.

Route-level rules

Match HTTP method + path. Protect specific endpoints.

GET /api/patients/*  roles: [doctor, nurse]
POST /api/patients/* roles: [doctor]

MFA per route

Sensitive ops require mfa_verified: true in the JWT.

DELETE /api/patients/:id
roles: [admin]  require_mfa: true

Group-based access

Require group membership for deployment endpoints.

POST /api/deploy/*
required_groups: [devops]

Monitor or enforce

Start in monitor mode, switch to enforce when ready.

mode: monitor  -> log only
mode: enforce  -> block unauthorized

Agent dashboard

Every node, every decision, in real time.

Because the decision happens in the kernel, the log is the ground truth: who hit which route and whether it was allowed — not a sampled trace reconstructed after the fact.

console.authfi.io/agent
Active nodes
node-01
16 CPU / 32GB · 4 services
node-02
4 CPU / 8GB · 2 services
Live access log
10:30:05 allow alice GET /api/patients/123
10:30:06 allow alice POST /api/patients/123/notes
10:31:00 deny bob DELETE /api/patients/456
10:31:02 deny (no token) GET /api/patients

Mesh networking

Encrypted between every node. Identity on every packet.

Nodes connect over WireGuard — peer-to-peer tunnels built on the Noise protocol framework, Curve25519 key agreement and ChaCha20-Poly1305, at roughly ~1ms overhead. There's no VPN gateway to funnel through and become a bottleneck or a single point of failure. eBPF then enforces identity on every packet traversing the mesh, so there is no anonymous traffic between services.

  • Encrypted tunnels: WireGuard between every node pair — modern, audited crypto, kernel-fast.
  • Identity routing: the same kernel enforcement that gates HTTP also gates east-west traffic on the wire.
  • Auto discovery: new nodes join the mesh automatically, with key exchange via the AuthFI control plane.
WireGuard mesh
node-01
node-02
encrypted · identity-checked
Tunnel
WireGuard / Noise
Cipher
ChaCha20-Poly1305
Key agreement
Curve25519
Overhead
~1ms

The trade-off

vs. sidecars and proxies.

A service mesh enforces in a userspace proxy beside every pod: a second process to run, an extra hop on every request, and millisecond-scale latency. Kernel enforcement removes the hop entirely.

FeatureAuthFIIstioEnvoy
Latency~45us~2ms~1ms
Code changesNoneNoneSidecar config
MFA per routeYes----
WireGuard meshBuilt-in----
Policy mgmtDashboard + APIYAMLYAML
Start free Talk to sales

Get started

Ready to get started?

Free for 5,000 monthly active users. No credit card required.

Start free Read the docs