MCP clients do not need cloud credentials. Put identity at the gateway.
HEMA exposes internal knowledge to Kiro, Claude and other MCP clients through Microsoft Entra ID without distributing AWS credentials. The reusable control is a separate external gateway with existing group-based authorisation.
HEMA opened its internal AI assistant to Kiro, Claude and other MCP clients without putting AWS credentials on developer machines. In an AWS case study published 23 September, the Dutch retailer routes those clients through a dedicated Amazon Bedrock AgentCore Gateway authenticated with Microsoft Entra ID.
The interesting part is not MCP connectivity. It is where HEMA draws the identity boundary. Its internal HAL agent keeps an IAM-authenticated gateway, while external MCP clients get a second gateway using Entra-issued JWTs. The two surfaces share only read-only knowledge bases.
One gateway per trust boundary is a security property
AgentCore Gateway supports one inbound authentication type, so HEMA could not simply expose the internal IAM gateway externally. That constraint forced a useful separation: external clients authenticate through Entra, while the internal agent keeps its AWS identity path.
An OAuth proxy in front of the external gateway reconciles MCP authentication with Entra ID. It serves discovery metadata, rewrites the requested scope, proxies the bearer token and emulates MCP dynamic client registration with a fixed pre-provisioned client ID. Users see a browser login and automatic token refresh rather than a cloud access key.
The durable MCP boundary is an identity gateway, not a credential copied into every client.
Read-only access earns the write path
HEMA has deliberately limited the external surface to read-only knowledge today. Access control follows existing Active Directory groups, and the knowledge-search Lambda is scoped by IAM to named knowledge-base resources and its source-document bucket.
That matters because HEMA plans to expose operational actions next, including AWS account provisioning. The company argues that existing Entra authentication and group authorisation can secure those tools too. That is a starting point, not proof that every future action is safe.
Make MCP onboarding an identity exercise
For platform teams, the deployment pattern is concrete. Keep internal agent identities separate from human-facing MCP identities. Terminate external authentication at a gateway. Reuse enterprise groups for authorisation. Start with read-only tools, then add write actions only after their scopes, approvals and audit events are explicit.
Most importantly, do not solve MCP adoption by handing each IDE or desktop agent a long-lived cloud credential. HEMA's architecture shows that the client can remain outside the AWS credential boundary while still reaching governed enterprise tools. That is the control worth copying.
Sources
Written by the Devence Lab research team.
