Identity & Security

Agentfleet's core security position: an agent never holds standing credentials. Every step of every run executes under a short-lived token that records exactly who delegated, who acted, where the token is valid, and — optionally — which task and purpose the session serves.

The delegated token

Before a step runs, Agentfleet performs an RFC 8693 token exchange with the identity provider:

• The subject token is the initiating user's access token — the delegating principal.
• The acting party is the agent, authenticating with a secretless private_key_jwt assertion signed by its per-agent key (held in a key vault; the platform never sees private key material).
• The request is narrowed to the step's resource (audience) and the step's tool scope.

The issued token carries:

Claim	Meaning
sub	The user the work is done for.
act.sub	The agent that acted.
aud	The one resource the token is valid at.
tenant	The owning tenant.
task_id	The task this session was composed for — when supplied as a run input.
purpose	The declared purpose of the session — when supplied as a run input.

Downstream resources can therefore audit "agent X, delegated by user Y, for task Z, under purpose P" on every call.

Least privilege, by construction

• Scope: only the step's tool scope is requested. The identity provider intersects the request against what both the user and the agent are allowed — a step can narrow access, never widen it.
• Audience: the token is valid only at the step's resource. It cannot be replayed elsewhere.
• Lifetime: tokens are minted per step and are short-lived. There is no transparent mid-call refresh; a fresh exchange happens on the next step.
• Just-in-time access: the agent's client is granted access to the resource only for the duration of the exchange, then revoked — the agent never retains standing access to anything.

Purpose-bound sessions (fail-closed)

Resources that enforce purpose-based policy require a purpose claim. If a run is queued without a purpose input, no purpose claim is requested — and a purposed resource rejects the session at the door. This is deliberate: forgetting to declare a purpose fails closed, while resources that don't require purpose run unchanged.

Secretless clients

Neither the platform nor its agents use client secrets:

• Agents authenticate with private_key_jwt assertions (60-second lifetime), signed via the key vault's crypto API using managed identity.
• Per-agent keys support zero-downtime rotation with overlapping validity.

What this means in practice

• A leaked token is useful for seconds, at one resource, under one scope — and names its wielder.
• A compromised agent cannot act without a fresh user delegation.
• Every downstream audit line has a complete answer to "who, on whose behalf, for what."