AI Agents
Your AI agent needs an identity, not a password
An LLM agent calling external APIs is a workload. It needs to authenticate. But you can't give it a username and password — it spawns dynamically, scales to zero, and runs in parallel instances. Aembit gives each agent invocation a unique, time-bounded identity.
The problem
LangChain today: 3 API keys in .env
Your LangChain agent makes calls to OpenAI, Pinecone, and your internal data service. This is what that looks like today — and what it looks like after Aembit.
Before Aembit
Shared keys, no audit
3 API keys hardcoded in environment variables
Same key shared across 200 concurrent agent instances
No audit trail by agent session — just IP-level logs
One key leak = total exposure across all services
.env (the problem)
# same key for 200 agent instances
OPENAI_API_KEY=sk-proj-abc123...
PINECONE_API_KEY=pcsk-xyz789...
DATA_API_KEY=dat-qrs456...After Aembit
Per-invocation tokens
Each agent invocation gets a unique identity token
Token TTL matches the invocation — expires when agent exits
Full audit log by agent session ID and target API
Zero shared keys — blast radius of any compromise = one invocation
SPIFFE ID issued at runtime
# identity derived from pod/function context
spiffe://cluster.local/ns/prod
/sa/langchain-agent
/invocation/3f8a2c1e
# token issued by Aembit: TTL 900s
# scoped to: openai-api / pinecone / data-apiAuthentication flow
How each agent call is authenticated
1
Agent spawns
Container or function starts. Aembit sidecar intercepts the outbound HTTP call before it leaves the pod.
sidecar: intercept outbound port 443
2
SPIFFE SVID presented
The sidecar retrieves the pod's SPIFFE SVID from the SPIRE workload API and presents it to Aembit's policy engine.
spiffe://cluster.local/ns/prod/sa/agent
3
Scoped token issued
Policy permits. Aembit issues a 15-minute OIDC token scoped to the target API. Token is injected into the Authorization header. Agent code never sees it.
Authorization: Bearer <jwt> exp: +900s