Do you need just-in-time access for your MCP servers to reach AWS resources only when a legitimate request is present, and then disappear the moment the job finishes?
Most teams ship static IAM keys or long‑lived service‑account credentials into the container image that runs the MCP server. Those secrets stay on the host for the lifetime of the pod, and any compromise of the container instantly grants an attacker unrestricted access to the entire AWS account. Rotating the keys every few weeks reduces exposure, but the process is noisy and still leaves a large attack surface while the server is running.
Even when you move to OIDC‑based authentication for the MCP server, the request still travels straight to the AWS endpoint. The identity token tells AWS who is calling, but there is no intermediate enforcement point that can inspect the API call, require an approval, or mask sensitive response fields. In practice you end up with a “who can call” check but no “what can be done” guardrails, and you lose the ability to produce a reliable audit trail for each invocation.
Why just-in-time access matters for MCP servers on AWS
Just-in-time (JIT) access means granting a credential that lives only for the duration of a single operation. The credential is created after a policy check, used once, and then expires. This model limits the window an attacker can abuse a leaked secret and forces every privileged action to be justified at the moment it occurs. For MCP servers that automate code generation or data extraction, JIT ensures that a burst of activity is always tied to a concrete request and a human or policy decision.
The missing enforcement layer
Without a dedicated gateway, the JIT workflow stops at credential issuance. The server still talks directly to the AWS service, which means any malformed request, accidental data dump, or malicious command bypasses policy checks. You also cannot enforce inline data masking, block dangerous API operations, or record the exact request‑response exchange because the traffic never passes through a point you control.
hoop.dev as the data‑path gateway
hoop.dev is a Layer 7 gateway that sits between the MCP server and the AWS endpoint. It receives the OIDC token, validates the identity, and then decides whether to issue a short‑lived AWS credential. The gateway forwards the request to AWS, inspects the protocol, and applies the controls you configure. Because every packet flows through hoop.dev, it can enforce just‑in‑time issuance, require an approval workflow for high‑risk actions, mask fields such as secret keys in responses, and record the full session for replay.
Key enforcement outcomes
- hoop.dev creates a temporary AWS credential only after the MCP server’s request satisfies the JIT policy.
- hoop.dev blocks API calls that match a deny list before they reach AWS, preventing accidental data loss.
- hoop.dev masks sensitive response attributes, ensuring that downstream logs never contain raw secrets.
- hoop.dev records each request and response, producing an audit trail that can be replayed for investigations.
- hoop.dev routes high‑risk operations to a human approver, adding a manual checkpoint without slowing down routine work.
Implementing just-in-time access with hoop.dev
Start by deploying the hoop.dev gateway in the same network segment where your MCP servers run. The quick‑start guide walks you through a Docker‑Compose deployment that includes OIDC authentication, masking, and guardrails out of the box. Register an AWS connection in the gateway, supplying either a static IAM role that the gateway can assume or the necessary endpoint details. The gateway stores the credential; the MCP server never sees it.
Next, define a JIT policy that ties a specific OIDC group or attribute to the ability to request an AWS credential. The policy can require an approval step for actions that touch production resources. Once the policy is in place, any MCP server that presents a valid token will be routed through hoop.dev, which will create a short‑lived credential, enforce masking, and log the session.
Because the enforcement happens in the data path, removing hoop.dev would immediately eliminate all of the outcomes listed above. The OIDC token alone would still identify the caller, but there would be no place to apply JIT checks, no masking, no command blocking, and no session recording.
Next steps
Review the full getting‑started documentation to launch the gateway, add your AWS connection, and configure a JIT policy that matches your security requirements. The docs also show how to enable approval workflows and inline masking for the most common AWS API calls. When you are ready to see the gateway in action, clone the open‑source repository and follow the deployment instructions.
FAQ
Can I use existing IAM roles with hoop.dev?
Yes. The gateway can be configured to assume a static IAM role that has the minimal permissions required for the MCP server’s workload. hoop.dev then issues short‑lived credentials derived from that role for each request.
What happens to the credential after the request finishes?
hoop.dev discards the temporary credential as soon as the session ends. Because the credential never leaves the gateway, the MCP server never stores it, and the risk of reuse is eliminated.
Do I need to change my MCP server code?
No. The server continues to use its standard AWS SDK or CLI. The only change is that it connects through the hoop.dev endpoint, which transparently injects the short‑lived credential and applies the configured guardrails.
For a hands‑on walkthrough, start with the getting‑started guide and explore the learn section for deeper details on masking and approval flows. The full source and contribution guide live in the GitHub repository.
