How do you let an automated MCP server, using a non-human identity, talk to AWS without handing it a static access key?
Most teams start by creating a dedicated IAM user, generating a long-lived secret, and embedding that secret in CI pipelines or configuration files. The secret travels across build agents, lands on disks, and often ends up in logs. When a breach occurs, every service that ever used that credential becomes a vector for lateral movement. Auditors also ask for proof that the service only performed the actions it was supposed to, but the raw AWS API logs give no context about who or what triggered each call.
Switching to a non-human identity, an OIDC-backed service account or a SAML-asserted principal, removes the need for long-lived keys. The service now receives a short-lived token from the corporate identity provider, and the token tells AWS who the caller is. This solves credential rotation, but it does not close the other gaps: the request still goes straight to the AWS control plane, there is no gate that can inspect the request, no way to require an approval before a risky operation, and no built-in audit trail that ties the API call back to the originating service.
Why the data path must host the enforcement for non-human identity
To make a non-human identity useful you need three layers. The first layer, the setup, establishes the identity source, configure your IdP to issue tokens for the MCP server, grant the corresponding IAM role the minimal permissions, and make sure the role can be assumed only by the token holder. This step decides who the request is, but on its own it cannot enforce policy.
The second layer, the data path, is the only place you can actually examine the traffic before it reaches AWS. By placing a Layer 7 gateway between the MCP server and the AWS APIs, you gain a single, immutable surface where every request can be inspected, approved, masked, or blocked.
The third layer, the enforcement outcomes, are the concrete security guarantees you need: a recorded session for every API call, just-in-time approval for privileged actions, real-time masking of sensitive fields in responses, and the ability to reject commands that violate policy. Those outcomes exist only because the gateway sits in the data path.
hoop.dev as the gateway for MCP-to-AWS traffic
hoop.dev fulfills the data-path requirement. You deploy the gateway close to your AWS resources, either as a Docker Compose container for a quick start or as a Kubernetes pod for production. The gateway holds the AWS credentials that the MCP server would otherwise need, and it authenticates the server with the same OIDC token flow you already use for humans.
When the MCP server initiates a connection, it talks to hoop.dev just like it would talk to the AWS endpoint. hoop.dev validates the token, maps the token’s groups to the appropriate IAM role, and then proxies the request to AWS. Because the request passes through hoop.dev, the gateway can enforce policies in real time. For example, if the MCP server tries to delete an S3 bucket that is marked as critical, hoop.dev can pause the request and route it to an approver. If the request contains a secret value in the response, hoop.dev can mask that field before it reaches the server.
All interactions are recorded. hoop.dev stores a replay-able log of each session, linking the OIDC identity to the exact AWS API calls that were made. This log satisfies audit requirements without needing to pull raw CloudTrail data and manually correlate it to service accounts.
Putting the pieces together
- Setup: Register your IdP as an OIDC provider for hoop.dev, create a service-account client for the MCP server, and grant the minimal IAM role that the gateway will assume on behalf of the server.
- Data path: Deploy hoop.dev, configure a connection definition that points to the AWS service you want to reach (for example, the S3 API or the EC2 DescribeInstances call), and bind the connection to the service-account client.
- Enforcement outcomes: Define policies that require approval for destructive actions, specify fields to mask in responses, and enable session recording. Once the policies are in place, every request from the MCP server flows through hoop.dev, where the policies are applied automatically.
Because hoop.dev is the only component that can see both the identity token and the raw AWS request, it is the only place you can reliably enforce these controls. Removing hoop.dev would return you to the original state where the MCP server holds static credentials and no guardrails exist.
Next steps
Start with the getting-started guide to spin up a local gateway and register an AWS connection. The guide walks you through configuring OIDC, defining the service-account client, and writing your first policy. When you are ready to explore the full feature set, policy language, approval workflows, and session replay, visit the learn page for deeper examples.
All of the configuration lives in the open-source repository, so you can inspect the code, contribute improvements, or fork it for a fully self-hosted deployment. The repository is available at github.com/hoophq/hoop.
FAQ
- Does hoop.dev expose AWS credentials to the MCP server? No. The gateway holds the credentials internally and presents only the short-lived OIDC token to the server. The server never sees the long-term secret.
- Can I use my existing OIDC provider (Okta, Azure AD, Google Workspace) with this setup? Yes. hoop.dev acts as a relying party for any OIDC-compatible provider, so you can reuse the same identity source you already use for human engineers.
- What happens if a policy requires approval but no approver is available? hoop.dev can be configured to either reject the request outright or queue it for later review. The decision point is part of the policy definition.
