SteadyInfraTech/ai-agent-edge-tunnel

ai-agent-edge-tunnel is a Kubernetes operator designed to provision short-lived Cloudflare Zero Trust Tunnels, DNS routes, and Access policies specifically for ephemeral AI Agent microservices (e.g., AutoGen, LangGraph, CrewAI).
## How it works
yaml
apiVersion: edge.steadyinfra.com/v1alpha1
kind: AgentEdgeTunnel
metadata:
name: sample-agent-tunnel
spec:
service: { name: langgraph-worker, port: 8080 } # in-namespace Service to expose
cloudflare: { zoneID: "...", subdomain: agent-job-8f92 }
ttl: 2h
security:
allowedEmails: [devops@company.com] # or: allowPublic: true
For each object the operator creates, in this order:
1. a Cloudflare Tunnel (its ID and credentials are stored immediately, so retries never leak tunnels);
2. for objects with security.allowedEmails, a Cloudflare Access application and allow policy, so the hostname is protected before it exists (objects with security.allowPublic: true deliberately get none);
3. a proxied DNS CNAME, which is what makes agent-job-8f92. reachable;
4. a cloudflared Deployment in the object's namespace, configured to send that hostname, and nothing else, to service.
If the Access policy of a protected object cannot be created, nothing after it runs: the hostname never goes live unprotected.
When the ttl expires, or the object is deleted, everything is removed in reverse order
(connector first, because Cloudflare will not delete a tunnel that is still connected).
Terminated is final; an expired object is never re-provisioned.
console
$ kubectl get agentedgetunnels
NAME PHASE HOSTNAME CONNECTED EXPIRES
sample-agent-tunnel Active agent-job-8f92.agents.acme.dev true 2026-11-05T14:00:00Z
Active means the tunnel and DNS record exist, plus the Access policy for email-protected objects; CONNECTED is whether the cloudflared pod
has connected to Cloudflare's edge.
### Access policy verification cadence
Email-protected active tunnels re-verify the complete Cloudflare Access application and policy on a per-tunnel
jittered interval of 5-10 minutes. Session reconciliation and Kubernetes watch events reuse the last successful
verification until that deadline, rather than issuing Access API reads on every 10-second session poll. Successful
checks persist their verification time and next deadline in status.
A Cloudflare HTTP 429 is treated as API-budget pressure, not proof of policy drift: the tunnel remains Active,
the existing tunnel state is retained and surfaced as a rate-limit warning, and verification is deferred for a
per-tunnel jittered 1-2 minute backoff. Other verification errors remain visible as unprotected and are retried by reconciliation;
a confirmed policy mismatch still terminates the tunnel fail-closed.
## Exposing an AgentSession
Instead of a fixed spec.service, a tunnel can follow an AgentSession from
agentops-operator:
yaml
spec:
sessionRef: { name: support-session-8f92 } # same namespace; mutually exclusive with service
The session's status.phase and status.endpoint are the whole contract; the session is read as
unstructured, so this operator does not depend on agentops-operator and starts without it installed.
Waiting. Until the session is Bound (or if it does not exist yet), nothing is created in