AWS introduced the Security Token Service (STS) in 2008. The idea was straightforward: instead of distributing long-lived IAM access keys, applications would assume roles and receive temporary credentials that automatically expire. It was a significant security improvement for cloud workloads.
Seventeen years later, the same idea hasn't been generalized to the rest of the credential landscape. And now, as AI agents need credentials to call Stripe, Slack, GitHub, and hundreds of other services, the lack of a universal just-in-time credential model is becoming a serious security problem.
What "just-in-time" actually means
Just-in-time (JIT) credential issuance means that credentials are created at the moment they are needed and expire shortly after they are no longer needed. There is no "standing" credential that persists between uses. Every task that requires a credential gets a fresh one.
This is distinct from credential rotation, which replaces long-lived credentials periodically. Rotation reduces the window of exposure after a compromise but doesn't address the fundamental problem: between rotations, the credential is a valid target. JIT issuance eliminates the standing credential entirely — there's nothing to target between tasks.
The properties of a well-designed JIT credential system:
- Scoped: The credential authorizes only the specific operation it was issued for. A read credential cannot write. A Stripe credential cannot access AWS.
- Time-bounded: The credential has a TTL. When it expires, it cannot be used — even if the underlying platform hasn't been notified of a revocation.
- Auditable: Every issuance is logged with the requesting identity, the scope, the TTL, and the task context.
- Revocable: If a credential needs to be invalidated before its TTL expires, it can be.
The existing JIT models worth understanding
AWS STS and IAM roles
The gold standard for cloud credentials. When an EC2 instance or Lambda function needs AWS credentials, it calls AssumeRole and receives temporary keys valid for 15 minutes to 12 hours. The instance metadata service automatically refreshes these before they expire.
This model works because AWS controls both the credential issuer (STS) and the credential consumer (AWS service APIs). Extending it to non-AWS services requires a bridge layer — which is what Agent Nonce provides.
GitHub Actions OIDC
GitHub Actions can now authenticate to AWS, GCP, Azure, and other providers using OIDC tokens rather than stored secrets. The workflow requests a short-lived OIDC token signed by GitHub, exchanges it with the cloud provider for temporary credentials, and uses those credentials for the duration of the job.
This is an excellent pattern that has nearly eliminated the need for long-lived secrets in GitHub Actions. The limitation: it only works for providers that have built OIDC federation support. Stripe, your internal APIs, and most SaaS services haven't.
Vault's dynamic secrets
HashiCorp Vault's dynamic secrets engine can generate short-lived database credentials, cloud credentials, and API tokens on demand. This is powerful and flexible but requires significant infrastructure investment and tight integration between the credential issuer (Vault) and the credential consumer.
What's missing: a universal JIT layer for AI agents
The pattern is clear. The infrastructure is proven. What's been missing is a service that:
- Works with any credential type (AWS, Stripe, GitHub, custom HTTP APIs)
- Has an API designed for agent orchestration patterns rather than human authentication
- Is lightweight enough that requesting a credential per task doesn't add meaningful latency
- Provides the audit trail that security teams need to approve AI agent deployments
Agent orchestration frameworks like LangChain, CrewAI, and AutoGen have tool-use APIs that can naturally accommodate a "request credential, use it, discard it" pattern. What they haven't had is the credential service that sits on the other end of that request.
The architecture in practice
A JIT credential architecture for AI agents looks like this:
┌─────────────────────────────────────────────────────┐
│ Agent Orchestrator │
│ │
│ 1. Plan task: "Read Stripe customers" │
│ 2. Request nonce from Agent Nonce │
│ → nonce.create({ service: "stripe", │
│ scope: "read:customers", │
│ ttl: "5m" }) │
│ 3. Receive nonce: an_4xK9mP... │
│ 4. Pass nonce to agent context for this task only │
│ 5. Agent completes task │
│ 6. Nonce expires automatically │
└─────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────┐
│ Agent Nonce Vault │
│ │
│ Real credentials: sk_live_stripe_... │
│ (agents never see this value) │
│ │
│ Issues: scoped derivative tokens │
│ Logs: every issuance with agent identity │
│ Enforces: scope constraints on all requests │
└─────────────────────────────────────────────────────┘The key property: the real credential never appears in the agent context. The agent only ever sees the nonce, which has a bounded lifetime and a bounded scope. When the conversation is logged, the nonce in the log is already expired.
Handling multi-step tasks
One practical question: what if an agent needs a credential for multiple operations in a sequence? Do you request a new nonce for each step?
The answer depends on the task structure. For a well-understood task — "sync billing data" — you can issue a single nonce scoped to the complete set of required operations with a TTL appropriate for the expected task duration. For open-ended agent autonomy, you issue nonces per-step with minimal TTLs, accepting that the agent will make multiple requests.
The overhead of multiple credential requests is small: a well-implemented JIT system adds single-digit milliseconds per request. The security benefit — each step uses only the credential it needs, and no credential persists across the task boundary — is substantial.
The security team approval path
The reason JIT credentials matter for AI agents isn't just the direct security benefit. It's that they create an approval path for security teams that would otherwise block agent deployments entirely.
Security teams can approve a model where:
- Credentials are scoped to specific operations
- Credentials expire automatically
- Every credential issuance is logged and attributable
- Compromise of an agent context exposes only expired tokens
They cannot approve a model where long-lived production API keys live in system prompts.
JIT credentials aren't just a security improvement — they're the prerequisite for getting security sign-off on the AI agent deployments your team wants to build.