Many engineers assume that an MCP server can simply inherit an AWS account’s IAM role through the oidc/sso token it receives from the identity provider. In reality the token only proves who the server is; it does not grant the server any privileged network path to AWS without exposing static credentials.
In most teams the first solution is to bake long‑lived AWS access keys into the MCP server’s configuration, share those keys across multiple services, and rely on the fact that the keys are “good enough.” This approach creates three hidden problems. First, the keys live in clear text on disk or in environment variables, making them easy targets for accidental exposure. Second, every service that holds the key can use it for any operation, far beyond the original intent, inflating the blast radius of a breach. Third, there is no central audit of what commands were run, no way to block dangerous actions, and no inline protection for sensitive data that might be returned from AWS APIs.
Introducing oidc/sso into the picture solves the identity problem. The MCP server can now authenticate to a central SSO provider, receive a signed token, and prove its group membership before any request is allowed. This step eliminates the need for per‑service passwords and gives the organization a single source of truth for who is allowed to start a connection. However, the token alone does not change the data path. The request still travels directly from the MCP server to the AWS endpoint, bypassing any enforcement point. Without a gateway, there is no place to enforce just‑in‑time access, require human approval for risky operations, mask sensitive fields in responses, or record the session for later replay.
Why oidc/sso alone isn’t enough
The strength of oidc/sso lies in authentication and basic authorization. It tells the AWS service that the caller belongs to a particular group, but it does not provide runtime guardrails. When an MCP server issues a request to, for example, the AWS CLI or an SDK, the call is sent straight to the AWS control plane. At that moment the organization loses visibility into the exact command, the parameters used, and the data returned. If a compromised server issues a destructive command, the damage is already done before any alert can fire.
Furthermore, oidc/sso does not give you the ability to mask confidential identifiers that might be returned from AWS, such as secret ARNs or database passwords. It also cannot enforce a policy that says “only a senior engineer may terminate an EC2 instance, and only after a manager approves the request.” Those controls must sit on the data path, not merely in the identity layer.
Introducing hoop.dev as the enforcement layer
hoop.dev is a Layer 7 gateway that sits between the MCP server and AWS. It consumes the oidc/sso token to verify the caller’s identity, then proxies the request to the AWS endpoint. Because the proxy is the only point where traffic passes, hoop.dev can apply a suite of guardrails in real time.
- Just‑in‑time access: hoop.dev can grant a short‑lived credential to AWS only for the duration of an approved session, eliminating the need for static keys.
- Approval workflows: risky operations such as deleting resources or modifying IAM policies can be routed to an approver before the request is forwarded.
- Inline data masking: response fields that match configured patterns (for example, secret values) are redacted before they reach the MCP server.
- Session recording: every command and response is logged by hoop.dev, providing a reliable audit trail that can be used for investigations or compliance reporting.
All of these outcomes are possible only because hoop.dev occupies the data path. The identity layer (oidc/sso) decides who may start a connection, but hoop.dev is the place where the policy is enforced and evidence is generated.