Adding authentication to a service normally means a library, configuration, a code review and a release. Multiply that by every internal tool, every team and every language in use, and the usual result is a short list of services that were done properly and a long list sitting behind a VPN. Zero-code authentication is an attempt to close that gap by moving the work out of the application.

This post defines the term, compares the three places the check can live, and is honest about what the approach cannot do.

What "zero-code" means

Zero-code authentication means that the service being protected is not modified. No SDK is imported, no middleware is added, and no release of the application is needed. Something outside the application process answers two questions before a request is delivered:

  • Who is calling? A person with a session, or a program with a valid token.
  • Is this allowed? Whether that caller may reach this service or this route.

"Zero-code" does not mean zero work. Someone still decides which services are protected, which groups may reach them and what the rules are. The claim is narrower: those decisions are configured once, in one place, and take effect without touching application code.

Three places the check can live

An edge proxy or gateway

The oldest form. A reverse proxy or API gateway at the edge of the network terminates TLS, runs the sign-in redirect, validates tokens and forwards the request.

It is simple to reason about and works for anything that speaks HTTP. Its weakness is coverage. It protects traffic that passes through it. A request from one internal service to another, or from a compromised pod to a neighbour, usually never touches the edge.

A sidecar

A service mesh places a proxy container next to every application container and redirects the pod's traffic through it. Each sidecar can validate tokens and enforce policy for its own workload, which fixes the coverage problem for traffic inside the cluster, and it can add mutual TLS between services.

The costs are operational. Every pod gains a container that uses memory and CPU, must be injected and upgraded, and sits in the request path. The sidecar also shares the pod with the workload it governs. An attacker with code execution in the application container may be able to send traffic that avoids it.

Kernel-level interception

eBPF allows small, verified programs to be attached to hooks inside the Linux kernel: where packets arrive, where a process opens a connection, where a program is executed. A program attached at these points sees traffic for every workload on the node without being part of any pod.

For authentication, the kernel program identifies connections bound for a protected service and hands them to an agent on the node, which runs the redirect or validates the token. For enforcement, the kernel can refuse a connection outright, so the decision does not depend on the workload's cooperation.

The property that distinguishes this option is that the workload cannot opt out. There is no code path from inside a container that goes around the kernel. The trade-offs are different too: it is Linux-only, it depends on kernel version and configuration, and it sees what the kernel sees, which means HTTP that has not been encrypted by the application itself.

What zero-code can and cannot give you

It does these well:

  • Single sign-on in front of web applications, including ones that cannot be changed. See zero-code SSO with an eBPF proxy.
  • Token validation for APIs: signature, issuer, expiry and audience, applied uniformly.
  • Coarse authorisation: which groups or roles may call which service or route.
  • Discovery: a list of what is actually running and which of it accepts unauthenticated calls.
  • Outbound limits: which destinations a workload may connect to.

It cannot do these:

  • Object-level authorisation. "May this user edit this document?" depends on data only the application has.
  • In-app flows. Step-up prompts inside a checkout, consent screens, account linking and profile management are product features.
  • Client-side behaviour. A single-page app or mobile app that needs tokens to call third-party APIs must obtain them itself.
  • Anything outside its platform. A kernel-level approach on Kubernetes does not protect a serverless function or a Windows host.

When it fits, and when to integrate an SDK

Zero-code is a good fit when:

  1. The application is internal, bought, or old, and changing it is expensive or impossible.
  2. You need consistent coverage across many services quickly.
  3. The access rule is expressible as "these groups may reach this service or route".
  4. You want a control the workload cannot switch off, for example around an AI agent. See the agent boundary.

Integrate properly when:

  1. The application is a customer-facing product where sign-in is part of the experience.
  2. Authorisation depends on the application's own data.
  3. The app needs to call other APIs with the user's delegated access.
  4. It runs somewhere your interception layer does not.

These are not exclusive. A sensible pattern is zero-code as the baseline for everything on the cluster, with SDK integration on top for applications that need finer control. The baseline also catches the endpoint someone forgot to protect in code.

How to roll it out safely

The main risk is not weak security. It is refusing legitimate traffic on the first day. A cautious sequence:

  1. Discover. Install in observation mode and list workloads and the routes they serve.
  2. Classify. Mark what each workload is. System components should be watched, not blocked.
  3. Define. Write rules, ideally drafted from the traffic that was observed.
  4. Rehearse. Run rules in a mode that reports what they would refuse.
  5. Enforce. Turn on one workload at a time, with a quick way back.

How AuthFI does it

AuthFI's Zero-Code takes the kernel-level route. It is one install on a cluster, built on eBPF, with no SDK, no sidecar and no change to applications. It does two jobs from the node a service runs on.

Zero-Code auth answers who is calling. A person in a browser is sent to your sign-in page and brought back with a session. A program's access token is checked on every request, including that it was issued for that API.

Zero-Code enforcement answers what may be reached. Rules on a route say which roles and groups may call it and whether it needs a second step. Outbound rules say where each workload and each AI agent may connect, and refusals happen on the machine itself.

The console holds you to four steps in order: discover, classify, define, enforce. Nothing can be enforced for the first 24 hours after install, system workloads are only ever watched, and every rule starts in watch-only.

The published limits are plain. It runs on Kubernetes on Linux, x86. It reads plain HTTP as seen on the node. Connections already open when you switch on are untouched until they close. The sign-in redirect needs the standard kube-proxy mode. Each node reports which protections attached, and the cluster owner can turn enforcement off on a node; the control plane cannot override that.

Key takeaways

  • Zero-code authentication means the protected service is unchanged. Policy is still your work.
  • Edge proxies miss internal traffic, sidecars add a container per pod, and kernel-level interception covers the node but depends on its kernel.
  • It handles sign-in, token checks and coarse access rules. Object-level authorisation still belongs in the application.
  • Use it as a baseline everywhere and integrate an SDK where the product needs more.
  • Always observe before you enforce.