Arcade.dev vs Microsoft Entra Agent ID

Arcade.dev

Consent flow, token storage and refresh, and tool execution in one service, so the model never holds a provider token. The terms of 15 July 2025 call the service an early version provided as is, with no uptime commitment below Enterprise.

Microsoft Entra Agent ID

Agent identities hold no credentials of their own, and Entra refuses high-privilege roles and Graph permissions for them. The token flow is a two-step exchange that Microsoft's own docs call complex and error-prone to implement by hand, and Conditional Access, risk detection and governance for agents need a paid Agent 365 licence.

Arcade.dev

1. Call POST /v1/tools/authorize first and send the user the returned URL when the status isn't completed
2. Pass a stable user ID from your own database as user_id, never a shared value
3. Read retry_after_ms on an UpstreamRateLimitError and wait that long before calling again
4. Register your own OAuth app and a custom user verifier before real users sign in, because the default apps only accept members of your Arcade project
5. Revoke a user's access with DELETE /v1/admin/user_connections/{id}

Microsoft Entra Agent ID

1. Request tokens in two steps. The blueprint gets an exchange token with fmi_path set to the agent identity's client ID, then the agent identity trades it for a resource token
2. Retry with exponential backoff when a create returns 400 Object with id not found straight after creating its parent object
3. Send displayName, agentIdentityBlueprintId and a sponsor reference when creating an agent identity. All three are required
4. Don't use the interactive /authorize flow. Agent identities are confidential clients and can't sign in to a page
5. Keep the sidecar off any public network. Its /AuthorizationHeader endpoint hands out tokens to whoever can reach it