Architecture
The identity plane for workloads
Aembit sits between workloads as an authentication proxy — it intercepts service calls, verifies runtime identity, and attaches short-lived credentials. Nothing stored. Everything audited.
Architecture
Control plane and data plane
Two planes, cleanly separated. The control plane holds policy. The data plane handles every authentication hop — without the control plane ever seeing credential material.
Aembit architecture overview
Identity sources
What counts as a workload identity
Five runtime environments Aembit can authenticate. Each brings its own identity primitive — Aembit normalizes them into a unified policy layer.
Kubernetes Pod
SPIFFE SVID from SPIRE
Kubernetes pods get a SPIFFE Verifiable Identity Document from a SPIRE server running in the cluster. The SVID is cryptographically signed and namespace-scoped.
identity source: SPIRE workload API
format: x.509 SVID or JWT-SVID
TTL: configurable, default 1h
AWS Lambda
Execution role + OIDC federation
Lambda execution roles can be federated into Aembit's policy engine via AWS OIDC provider. The function's role ARN becomes its verifiable identity.
identity source: AWS IAM OIDC provider
format: JWT with ARN claim
cold-start overhead: < 2ms
GitHub Actions
OIDC token per workflow run
GitHub Actions issues a per-run OIDC token containing the workflow, repo, and environment claims. Aembit validates these claims against policy before issuing scoped credentials.
identity source: GitHub OIDC provider
format: JWT with workflow claims
scope: per run, per environment
AI Agent Runtime
Sidecar injection for LangChain / AutoGen
AI agent frameworks don't have native identity primitives. Aembit injects a sidecar alongside agent containers, attaching a per-invocation identity derived from the pod's SPIFFE SVID.
identity source: SPIFFE via sidecar
scope: per agent invocation
audit: per-session call log
Audit trail
Every access logged with full identity context
What a CISO brings to a SOC 2 audit. Not "comprehensive logging" — the actual log entry format.
audit-event.json — sample log entry
{
"event_id": "evt_01hx9k2z3m4n5p6q7r8s9t0u",
"timestamp": "2026-06-14T03:47:22.341Z",
"workload_svid": "spiffe://cluster.local/ns/prod/sa/data-pipeline",
"workload_type": "kubernetes-pod",
"target_service": "internal-data-api.prod.svc.cluster.local",
"policy_matched": "allow:data-pipeline:internal-api:read",
"token_issued": true,
"token_id": "tok_prod_8a3f2c1e",
"ttl_seconds": 900,
"request_method": "GET",
"request_path": "/api/v1/records",
"outcome": "permitted",
"latency_ms": 3.2
}Deployment
Two deployment modes — pick what fits your stack
Sidecar requires zero application code changes. SDK gives fine-grained control when you need it.
Recommended
Sidecar mode
Zero application code changes required
Works with any language or framework
Transparently intercepts all outbound HTTP/S
Enabled via a single Kubernetes annotation
kubernetes-deployment.yaml
metadata:
annotations:
aembit.io/inject: "true"
aembit.io/policy: "prod-data-pipeline"Advanced
SDK mode
Fine-grained per-call control
Access token metadata in application code
Available for Go, Python, and Node.js
Requires application code changes
main.py
import aembit
# get a scoped token for the target service
token = aembit.token("internal-api")
resp = requests.get(url, headers={
"Authorization": f"Bearer {token}"
})