§ GOVERNANCE
IAM Binding — Workload Identity Federation
Your agents already have an identity in Microsoft Entra ID. Execlave federates it: the workload exchanges its Entra-issued token for a short-lived Execlave credential, so no long-lived Execlave secret ever ships with the agent.
Why federate
Agents are non-human identities, and identity governance teams want them managed where every other identity lives — the corporate IdP. With federation, the agent authenticates to Execlave with the credential Azure already rotates and attests (managed identity or app registration), and receives the same short-lived exe_agt_ credential an operator could issue from the dashboard. Revoke the service principal in Entra and the agent can no longer obtain Execlave credentials — your IAM lifecycle governs the agent's governance-plane access.
Setup
One provider per trusted tenant, one binding per agent. Both ADMIN-only.
# 1 · Trust your Entra tenant (ADMIN)POST /api/v1/identity-providers{ "tenantId": "<tenant GUID>", "audience": "api://execlave-agents" } # 2 · Bind the agent to its workload identity (ADMIN)PUT /api/v1/agents/{agentId}/identity-binding{ "providerId": "<provider id from step 1>", "subject": "<service principal object id (oid)>" }| Field | What it is |
|---|---|
tenantId | Your Entra tenant GUID. Tokens must be issued by this exact tenant — multi-tenant issuers (common/organizations) are rejected. |
audience | The aud claim the workload requests a token for (app ID URI or client id). Must match exactly. |
subject | The workload's service principal object id (oid claim) — immutable in Entra. One agent per (provider, subject). |
The exchange
The workload presents its Entra token; Execlave returns a standard agent credential.
# Azure workload (managed identity or app registration) requests a token# for the audience you configured — no Execlave secret involved.az account get-access-token --resource api://execlave-agents --query accessTokenPOST /api/v1/agent-credentials/exchangeContent-Type: application/json { "token": "<Entra-issued access token>" } # 201 response{ "data": { "credential": "exe_agt_...", # standard short-lived agent credential "expiresAt": "2026-06-11T10:15:00.000Z", "agentId": "c0a8012e-..." }}The returned credential is the same one issued by POST /api/v1/agents/:id/credential — short-lived, revocable by jti, and accepted everywhere agent credentials are (including agent-to-agent delegation). Every successful exchange writes an audit entry with the provider, subject, and credential id.
Security model
- Tokens are verified against the tenant's JWKS (RS256) with exact issuer and audience — the unverified token is used only to route to the right tenant configuration, never for identity.
- The exchange endpoint is unauthenticated by design (the Entra token is the credential) but strictly rate-limited and brute-force guarded; failed exchanges count toward IP lockout like failed API-key auth.
- Every failure returns the same error — the endpoint cannot be used to enumerate tenants, audiences, or agent bindings.
- Fail closed: any verification error, disabled provider, or missing binding rejects the exchange.
Disable a provider (PATCH /api/v1/identity-providers/:id with { "isEnabled": false }) to cut all federated issuance for that tenant immediately; already-issued credentials expire on their own short TTL or can be revoked per-credential.
Relationship to Microsoft Entra Agent ID
Entra answers “who is this agent?”; Execlave answers “what may it do right now, and what did it do?”. Federation connects the two: Entra remains the identity authority, Execlave enforces runtime policy and produces the tamper-evident record. See the Entra Agent ID comparison for the full picture.