Aembit answers whether the human and agent may call. Steward governs how the call reaches the resource.
Use Aembit to govern the human and AI agent, then Steward to carry the authorised operation into supported AD/Windows resources.
Aembit and Steward solve adjacent identity problems. Aembit can place policy around the human, AI agent and MCP capability. Steward is designed for the downstream enterprise-resource boundary where existing Windows/AD permissions should remain authoritative.
Reference flow
AI client → Aembit MCP Identity Gateway → Steward → local STDIO MCP backend → supported AD resource as the authorised user.
How Steward trusts Aembit
Steward supports OIDC/JWKS issuer blocks with exact issuer and audience checks, key selection by kid, rotating JWKS keys and a configurable agent claim. The current verifier is RSA/RS256, so an Aembit-issued token for Steward must use RS256 and assert the AD UPN in the configured human claim.
BrainStorm can also sit upstream
BrainStorm supports standard MCP OAuth discovery, PKCE, dynamic client registration where available, per-session grants and refresh. That allows a BrainStorm → Aembit → Steward route as well as direct BrainStorm → Steward operation.