v0.1.0-alpha

agentaccesscontrol

the agent gateway for Kubernetes

discovery auth routing credentials rate-limits mcp

$ kubectl apply -f agentpolicy.yaml

The Problem

• AI agents are calling other agents, external APIs, and LLMs — but there's no standard way to secure these interactions
• Every team hand-wires auth, rate limiting, and credential injection — scattered across code, envvars, and sidecars
• No visibility into who can call what, which agents talk to each other, or how outbound API keys are managed
• Agents get deployed with hardcoded secrets, no access control, and no rate limits — a security incident waiting to happen

What Agent Access Control Is

Two CRDs, Two Personas

Agent Discovery

AgentCards are discovered, not written. The AI Engineer adds a label. GitOps deploys. The operator discovers.

AI Engineer adds label         GitOps deploys pod                 AgentCard CR
kagenti=true, commits          Discovery controller watches       created automatically
────────────────────────       ──────────────────────────         ──────────────────────

A2A agent                 →    GET /.well-known/agent.json   →  protocols: [a2a]
                                 (name, skills, protocols)         skills: [...]

MCP agent                 →    POST /tools/list              →  protocols: [mcp]
                                 (available tools)                 skills: [from tools]

REST agent                →    GET /openapi.json             →  protocols: [rest]
                                 (endpoints, schemas)              skills: [from paths]
  

The AI Engineer never writes a CRD or runs kubectl. They commit, GitOps deploys, the operator discovers.

How It Works

AI ENGINEER                 PLATFORM (GitOps + Operator)      PLATFORM ENGINEER
───────────                 ────────────────────────────      ─────────────────

1. Push image, add           GitOps (ArgoCD/Flux)
   kagenti label to          syncs manifests to cluster
   Deployment, commit                |
                             Discovery controller              2. Define AgentPolicy
                             fetches agent metadata                per tier, commit
                             creates AgentCard CR                  to git
                                     |                                  |
                             AgentCard controller               GitOps syncs policy
                             generates HTTPRoute                        |
                                     |                                  |
                             AgentPolicy controller  <──────────────────┘
                             matches cards by labels
                             generates AuthPolicy, RateLimitPolicy, ConfigMap
                                     |
3. Agent receives traffic    Gateway routes via HTTPRoute
   (no action needed)        Authorino + Limitador + Sidecar enforce everything
  

What Discovery Produces

The AI Engineer commits a labeled Deployment. GitOps deploys it. The discovery controller creates this CR — no human writes it.

# Auto-generated from /.well-known/agent.json
apiVersion: kagenti.com/v1alpha1
kind: AgentCard
metadata:
  name: weather-agent
  labels:
    tier: standard          # from pod labels
    domain: weather         # from pod labels
spec:
  description: "Agent providing weather forecasts and alerts"
  protocols:
    - a2a
    - rest
  skills:                   # extracted from agent card
    - name: get-forecast
      description: "Returns weather forecast for a location"
    - name: weather-alerts
      description: "Returns active weather alerts for a region"
  servicePort: 8080
  

Platform Engineer: Apply a Policy

The only CRD a human writes. The Platform Engineer defines security rules that select discovered agents by label.

apiVersion: kagenti.com/v1alpha1
kind: AgentPolicy
metadata:
  name: standard-tier
spec:
  agentSelector:
    matchLabels:
      tier: standard
  ingress:
    allowedAgents: [orchestrator, planner]
    allowedUsers: ["*"]
  external:
    defaultMode: deny
    rules:
      - host: api.openweathermap.org
        mode: vault
        vaultPath: secret/data/openweathermap
      - host: weather.gov
        mode: passthrough
  rateLimit:
    requestsPerMinute: 60
  

Four Credential Modes

Credential injection happens in the sidecar forward proxy — zero code changes in the agent.

What Gets Generated

One AgentPolicy matching N agents generates N sets of downstream resources.

Policy Tiers in Practice

# Premium: OAuth2 token exchange for GitHub API
external:
  rules:
    - host: api.github.com
      mode: exchange
      audience: github-api
      scopes: [repo, pull_request]
  

Reconciliation Flow

Labeled pod detected
        |
        v
DiscoveryController
  |- Fetch /.well-known/agent.json (A2A) or /tools/list (MCP)
  |- Create AgentCard CR with metadata + pod labels
        |
        v
AgentCardReconciler
  |- Add finalizer
  |- Build HTTPRoute (host, paths, gateway ref)
  |- Create or Update HTTPRoute
  |- If "mcp" in protocols → create MCPServerRegistration
  |- Update status: Ready condition + generatedHTTPRoute
        |
        v  (watcher triggers)
AgentPolicyReconciler
  |- List AgentCards matching policy.spec.agentSelector.matchLabels
  |- For each matched card:
  |    |- Find card's HTTPRoute
  |    |- If ingress defined  → create/update AuthPolicy
  |    |- If rateLimit defined → create/update RateLimitPolicy
  |    |- If external defined → create/update sidecar ConfigMap
  |- Update status: matchedAgentCards count + generatedResources list
  

Architecture

Design Principles

• Persona separation — AI Engineers commit code, Platform Engineers own GitOps and policies, neither crosses into the other's domain
• Discovery, not declaration — agents are found at runtime from their endpoints, not hand-written by anyone
• Zero code changes — security is declared in YAML by the platform team, not wired into agent code
• Label-based matching — policies select agents dynamically, not by hardcoded names
• Defense in depth — NetworkPolicy at the network layer, sidecar at the application layer, gateway at the routing layer
• Graceful degradation — optional CRDs (AuthPolicy, MCPServerRegistration) are skipped if not installed
• Deny by default — NetworkPolicy blocks egress, sidecar blocks unmatched hosts, no access without explicit policy

Inbound vs Outbound

The Agent Gateway

Gateway API + MCP Gateway + this operator = a unified agent gateway handling every call pattern.

Every call — inbound, agent-to-agent, MCP, and outbound — goes through an enforcement point. No direct access.

MCP Gateway Integration

# Premium tier agents get MCP tool access
spec:
  mcpTools:
    virtualServerRef: premium-tools-vs   # MCP Gateway filters tools per-agent
  

Egress: Two Layers

NetworkPolicy blocks at the network. Sidecar injects credentials per host. Both are needed: NetworkPolicy can't do per-host routing, sidecar can be bypassed without NetworkPolicy.

Why a meta-CRD?

Why not let the platform engineer write HTTPRoutes, AuthPolicies, and RateLimitPolicies directly?

Complement, Not Compete

Both discover agents — at different stages and for different purposes.

Registry knows the agent's dependency graph at build time. Access Control enforces what it can actually reach at runtime. Together: full lifecycle governance.

Status

quick start

# Install CRDs
make install

# Run the operator
make run

# Deploy sample agents + policies
kubectl apply -f config/samples/
  

repo → github.com/kagenti/agent-access-control