A common misconception is that AI‑driven MCP servers can be left to run unattended on AWS because the underlying cloud permissions are assumed to be sufficient. In reality, without approval workflows each request can execute arbitrary code, expose sensitive data, and expand the blast radius of a compromised service.
Most teams provision an MCP server with a static IAM role that grants broad read and write privileges to the underlying data stores. The role is attached once, the server starts, and developers or automated agents begin issuing queries directly against the database. No per‑request check exists, no audit trail is captured, and no human can intervene when a risky operation is about to run. The result is a blind spot where privileged actions occur without visibility or control.
Why approval workflows are essential for MCP servers on AWS
Introducing a non‑human identity for the MCP server is the first step toward least‑privilege access. By issuing a short‑lived service account token from an OIDC provider, the server proves who it is before any connection is allowed. This token can be scoped to read‑only queries, limited tables, or specific API actions. However, the token alone does not stop a malicious or erroneous request from reaching the database. The request still travels straight to the target, bypassing any real‑time review, masking, or recording.
The missing piece is a control surface that sits on the data path. A gateway positioned between the MCP server and the AWS resource can inspect each protocol message, enforce policy, and trigger an approval workflow when a request crosses a defined risk threshold. Without such a gateway, the setup described above remains vulnerable: the server can still run destructive commands, and the organization lacks evidence for compliance or incident response.
How hoop.dev becomes the enforcement point
hoop.dev acts as a Layer 7 gateway that proxies the connection from the MCP server to the AWS target. The gateway runs a network‑resident agent inside the same VPC as the database, so the server never sees the underlying credentials. When the MCP server initiates a request, hoop.dev validates the OIDC token, extracts group membership, and then evaluates the request against approval policies. If the request matches a high‑risk pattern, such as a write to a production table or a bulk export, hoop.dev pauses the operation and routes it to a human approver. The approver can grant or deny the request in real time, and hoop.dev records the decision alongside the full session transcript.
Because hoop.dev sits in the data path, every enforcement outcome is enforced by hoop.dev itself. The gateway masks sensitive fields in query responses, blocks commands that violate policy, and records the entire interaction for replay. The approval workflow is therefore not a separate service; it is an intrinsic capability of hoop.dev’s gateway layer.
Architectural steps to enable approval workflows
- Deploy the hoop.dev gateway using the provided Docker Compose quick‑start or a Kubernetes manifest. The deployment includes an OIDC configuration that points at your identity provider.
- Register the AWS resource (for example, an RDS PostgreSQL instance) as a connection in hoop.dev. The gateway stores the IAM role or static credentials, keeping them hidden from the MCP server.
- Configure the MCP server to authenticate via OIDC, obtaining a short‑lived token that represents its service identity.
- Define approval policies in hoop.dev’s policy model. Specify which query patterns or API calls require human sign‑off, and designate approvers based on group membership.
- When the MCP server sends a request, hoop.dev evaluates the policy, triggers the approval workflow if needed, masks any sensitive data in the response, and records the session for audit.
All of these steps are described in the getting‑started guide. The guide walks you through deploying the gateway, linking an OIDC provider, and creating a connection to an AWS database. For deeper insight into how approval workflows integrate with other security controls, see the learn section on the hoop.dev site.
FAQ
What happens if an approval request is denied?
hoop.dev aborts the operation and returns an error to the MCP server. The denial, along with the full request payload and the identity of the approver, is logged as part of the session record.
Can approval workflows be applied to read‑only queries?
Yes. Policies can target specific tables, columns, or query sizes. Even a read that extracts large amounts of data can be gated for review, ensuring that data exfiltration attempts are caught before execution.
Do I need to modify my MCP server code to use hoop.dev?
No. The server simply points its client library (for example, the PostgreSQL driver) at the hoop.dev endpoint. All enforcement happens transparently in the gateway.
With hoop.dev handling the data‑path enforcement, you gain real‑time approval workflows, session replay, and inline masking for every request your AWS‑hosted MCP server makes. This architecture closes the gap left by static IAM roles and provides the audit evidence needed for security reviews.
Ready to try it yourself? Explore the open‑source repository on GitHub and start building approval‑driven pipelines for your AI services today.
