Zero-Trust for AI Agents: Short-Lived Identity, Just-In-Time Access, Recorded Sessions
Modern AI agents aren’t “just another microservice.” They read mail, open tickets, push code, touch billing, and talk to third-party APIs. Give them static keys and wide roles, and you’ve built a silent super-admin that’s one prompt-injection away from doing damage. The fix isn’t a bigger firewall; it’s zero-trust applied to agents: identity first, privileges when needed, and a complete trail of what happened.
Below is a practical playbook we use in the field.
Why Zero-Trust For Agents (Now)
Two things changed at once: (1) agents gained real powers via tool use, and (2) LLM-specific risks like prompt injection emerged. OWASP’s LLM Top 10 puts Prompt Injection in the #1 spot for a reason—crafted inputs can steer an agent to exfiltrate data or execute unintended actions.
Zero trust gives us the counter-pattern. As NIST SP 800-207 defines it, “zero trust assumes no implicit trust granted to assets or user accounts based solely on their physical or network location.” Keep verifying identity, context, and policy per request.
Principle 1 — Identity First: Short-Lived, Workload-Bound Credentials
Agents should authenticate as workloads, not with long-lived secrets. In practice:
- OIDC federation from CI/agents to your cloud: instead of storing cloud keys, your platform swaps an OIDC token for a short-lived access token scoped to one job. GitHub Actions ships this natively; cloud providers mint tokens that expire automatically.
- Scoped IAM roles per tool (read-only by default). For example, a “support-summaries” role can read specific S3 prefixes but can’t write or list outside them. AWS documents the repo-to-role mapping pattern for OIDC so you can bind a single repository (or agent identity) to a narrow role.
- Dynamic secrets for databases and third-party systems. HashiCorp’s guidance emphasizes an identity-based model—“moving towards identity-based controls as the source of all security.” Keep credentials ephemeral; rotate by design.
This reduces the blast radius: if an agent’s context is compromised, its token dies quickly and cannot be reused elsewhere.
“Identity is the new perimeter.” — Armon Dadgar, Co-founder & CTO, HashiCorp.
Principle 2 — Just-In-Time (JIT) Access With Policy-as-Code
Agents rarely need standing admin rights; they need bursts of permission tied to a specific intent. Concretely:
- Make privileges JIT. Microsoft’s Entra PIM model is succinct: “Eliminate persistent access and enforce time-limited access for critical roles.” In practice, an agent “requests” a role, your policy engine evaluates context (who/what, where, when, why), and—if approved—issues a short window of access.
- Codify decisions with Policy-as-Code. Use OPA/Rego-style rules to bind intents to permissions: “If intent == create-invoice and amount < $2k and customer is active → allow billing-write for 5 minutes; else escalate to human.” Policies live in Git, get reviewed like code, and are testable. (CISA’s maturity model also stresses dynamic policy and per-session access.)
The outcome: fewer standing privileges and clearer reasoning for each elevation.
Principle 3 — Record High-Risk Actions; Keep Logs Tamper-Evident
If an agent can change infrastructure, money, or code, treat that session like a change-controlled operation:
- Session recording & rich audit trails. Platforms like Teleport record commands and create structured events for every session—covering SSH, Kubernetes, DB, and web app access. That makes “who did what, when, and with which identity” answerable in minutes.
- Immutability for forensic truth. Store audit events in an immutable lake—e.g., AWS CloudTrail Lake provides read-only, append-only storage; enable log-file integrity validation so tampering is detectable.
With recordings and immutable logs, incident reviews become replayable sessions, not guesswork.
Principle 4 — Human-In-The-Loop For “High-Risk Intents”
Not every agent action should auto-execute. For certain intents—wire transfers, user deprovisioning, production schema changes—add a second factor: a person.
The NIST AI Risk Management Framework is explicit about human oversight: design “human-AI configurations” so the level of oversight matches the risk. Map which agent tasks must be proposed, which can be auto-approved, and which require a named approver.
Practically, this looks like a lightweight review queue: the agent proposes the action with evidence, a human approves/denies, and the system records both.
Reference Architecture (What We Ship)
1) Identity & Tokenization
- Agent or workflow receives an OIDC JWT from its runner/orchestrator.
- Cloud exchanges it for a short-lived, scoped token (assume-role).
2) Policy & Intent Router
- The agent declares an intent (e.g., “close billing period”).
- Policy-as-Code evaluates: identity, environment, risk score, time, and ticket linkage (e.g., JIRA).
- If low-risk, grant JIT access for N minutes; if high-risk, create an approval task.
3) Safe Tool Adapters
- Each tool (mail, Git, billing, ticketing) has a thin, least-privilege adapter.
- Adapters enforce allow/deny lists and sanitize outputs to reduce prompt-injection paths (e.g., never pass raw external content to privileged tools without validation).
4) Observability & Forensics
- Every privileged session is recorded; every decision and token issuance produces a structured event.
- Events land in an immutable audit lake with integrity validation enabled.
Rollout Plan (6–8 Weeks)
Week 1–2 — Map Real Intents
List the top 10 tasks agents perform that hit production data or money. Tag them by risk and systems touched. Align with CISA’s zero-trust pillars so you’re not guessing where to start.
Week 3–4 — Move to Short-Lived Identity
Turn on OIDC for CI/agents in one environment. Kill long-lived cloud keys; bind a single repo/agent to a narrow IAM role; rotate any remaining shared secrets behind a broker (Vault/Boundary).
Week 5 — Add JIT + Approvals
Stand up a small policy service. Start with 3 intents: deploy-staging, rotate-test-keys, read-only-billing. Require human approval for anything high-risk.
Week 6–8 — Record & Make Logs Immutable
Enable session recording for shell/DB/Kubernetes; enable CloudTrail Lake and integrity validation. Run a tabletop exercise: “agent tries to mass-export PII”—prove your controls stop it and your logs can replay the attempt.
Measure:
- % of agent actions executed with short-lived tokens
- MTTA (time to approval) for high-risk intents
- Standing privileges eliminated
- Mean investigation time using recordings and immutable logs
Pitfalls We See (So You Can Skip Them)
Static keys hidden in “prompt config.” Teams remove hard-coded secrets from code, then accidentally leave them in agent tool configs or prompt templates. Treat prompt stores as sensitive; scan them. (OWASP’s “insecure output handling” is your north star here.)
Over-permissive adapters. A “billing API” wrapper that can do everything will eventually do everything—by mistake. Split read vs. write adapters and bind each to different roles.
Audit logs you can edit. If an attacker can alter or delete logs, you don’t have logs—you have fiction. Use append-only/immutable storage and enable validation.
No human stop-button. Give operators a kill-switch for agent tools and a break-glass flow with strong guardrails (time-boxed, fully recorded).
What Industry Voices Are Saying
“Zero trust assumes no implicit trust … Authentication and authorization are discrete functions before access is established.” — NIST SP 800-207.
“Use just-in-time privileged access. Eliminate persistent access for critical roles.” — Microsoft Entra PIM.
“Identity-based controls [are] the source of all security.” — Armon Dadgar, HashiCorp.
These aren’t slogans; they’re implementable patterns with mature tooling behind them.
A Business Lens From Pynest
“We treat agents like temporary contractors: prove identity, request the least you need for the shortest time, and leave a trail we can replay.” — Andrew Romanyuk, Co-Founder & SVP Growth, Pynest.
On recent projects we saw three fast wins: (1) cutting standing admin roles by >80% after moving CI/agents to OIDC-minted tokens; (2) reducing approval time for risky operations to under 6 minutes with concise intent summaries; (3) taking post-incident analysis from hours of log-grepping to a 10-minute replay thanks to session recordings (SSH/K8s/DB). (Approach aligned with CISA’s ZT maturity model and NIST AI RMF oversight guidance.)
