Least-privilege access for MCP servers on AWS

How can you grant an AI-driven MCP server just enough rights to run on AWS while still enforcing least-privilege access?

Most teams hand a static IAM user or role to the MCP service, bake the credentials into the container image, and hope the permissions are narrow enough. In practice the credential is shared across environments, never rotated, and any compromise gives an attacker unrestricted access to the entire AWS account. Auditors see a single IAM entity with broad policies, but they cannot tell which request originated from the MCP server, what data was returned, or whether a risky command was blocked.

Why the current model fails to deliver least-privilege access

The problem is two-fold. First, the identity that the MCP server presents is static; it does not change per request, so the principle of least-privilege cannot be enforced at the moment of use. Second, the request travels directly to the AWS endpoint. The gateway that could inspect the API call, enforce a policy, or record the interaction simply does not exist. The result is a blind path: the server can read or write any resource the static role permits, no approval workflow intervenes, no command is examined, and no audit trail is kept beyond the AWS CloudTrail entry that does not attribute the action to a specific engineer or policy decision.

What we need is a control surface that sits between the MCP server and AWS, where a policy engine can evaluate each request, apply the least-privilege principle dynamically, and capture evidence for compliance.

Implementing least-privilege access with hoop.dev

hoop.dev provides exactly that control surface. It is a Layer 7 gateway that proxies every connection the MCP server makes to AWS services. The MCP server authenticates to hoop.dev using OIDC or SAML, so the gateway knows the caller’s identity and group membership. hoop.dev then uses a short-lived, service-specific credential to talk to the AWS API on behalf of the caller. Because the gateway owns the credential, the original static key never leaves the network edge.

When a request arrives, hoop.dev evaluates the policy attached to the caller’s identity. If the request exceeds the allowed scope, hoop.dev blocks the operation before it reaches AWS. If the request is borderline, such as accessing a sensitive S3 bucket or invoking a privileged Lambda, it can route the request to a human approver for just-in-time consent. Once approved, the request proceeds and hoop.dev records the full session, including request parameters and response payloads. Sensitive fields in the response are masked inline, ensuring that downstream logs never expose secrets.

Because hoop.dev sits in the data path, every enforcement outcome, blocking, approval, masking, and recording, originates from hoop.dev. Removing hoop.dev would instantly eliminate those guarantees, leaving the static credential and unmonitored traffic in place.

Key architectural steps

• Deploy the hoop.dev gateway in the same VPC as the MCP servers. The deployment uses a Docker Compose file for a quick start, or a Helm chart for production clusters.
• Configure an AWS connection in hoop.dev. The gateway stores the IAM role that has the minimal set of permissions required for the MCP workload.
• Register the MCP server as a client in hoop.dev’s identity provider configuration. The server receives an OIDC token that hoop.dev validates on each request.
• Define a least-privilege policy that maps the MCP server’s identity to the allowed AWS actions. Policies can require just-in-time approval for privileged calls.
• Enable session recording and inline masking in the gateway settings so that every interaction is captured and sensitive data is redacted automatically.

All of these steps are described in the getting‑started guide. The guide walks you through the deployment model, the identity configuration, and the policy definition without exposing any code snippets. For deeper details on masking, approval workflows, and audit‑log formats, consult the learn section of the documentation.

Frequently asked questions

Does hoop.dev replace existing IAM roles?

No. hoop.dev uses an IAM role internally to talk to AWS, but the role is owned by the gateway, not by the MCP server. The server never sees the role’s credentials.

How does hoop.dev handle credential rotation?

The gateway automatically refreshes its service credentials according to the IAM role’s policy. Because the MCP server never holds the credentials, rotation is transparent to the workload.

Can I audit who approved a privileged request?

Yes. Every approval decision is recorded as part of the session log. hoop.dev stores the approver’s identity, the request details, and the timestamp, providing clear evidence for any audit.

By placing hoop.dev in front of your MCP servers, you turn a static, over-privileged connection into a dynamic, policy-driven workflow that enforces least-privilege access, records every interaction, and masks sensitive data on the fly.

Explore the source and contribute on GitHub