When a newly‑trained LLM‑driven coding agent is granted a service account key and allowed to push resources directly into an AWS account, the first thing it does is spin up a handful of EC2 instances to run tests. Within minutes the agent has created security groups, opened ports, and attached policies that give it read‑write access to S3 buckets that store production data. No human ever saw the commands, and the cloud‑trail logs only show a successful API call from a credential that was never reviewed.
Why approval workflows matter for AI agents
AI‑generated code runs fast, but it also runs without the contextual judgment a human engineer provides. An unchecked agent can create privileged resources, expose data, or trigger cost spikes before anyone notices. Traditional IAM policies can limit what a service account can do, yet they cannot enforce a step where a security reviewer must sign off on a risky operation. Without a checkpoint, the organization loses visibility into who approved what, and the audit trail becomes a simple list of successful calls.
Current practice and its gaps
Most teams hand the agent a static access key that is stored in CI pipelines. The key is often scoped to a broad set of actions because developers need flexibility during experimentation. The key never rotates automatically, and there is no mechanism to pause a request for human review. As a result, the system lacks real‑time guardrails, and any misbehaving request proceeds unchecked.
Architectural building blocks needed
The first step is to replace the static key with a non‑human identity that is federated through an OIDC provider such as Okta or Azure AD. The identity is assigned a minimal IAM role that only permits the actions required for the agent’s current task. This setup defines who the request is and whether it may start, but it does not provide any enforcement once the request reaches AWS. The agent still talks directly to the AWS API endpoint, and no component in the path can intervene to ask for approval or record the session.
Placing the gateway in the data path
To close the gap, the connection must be routed through a Layer 7 gateway that sits between the agent and the AWS service endpoints. This gateway inspects each API call, can pause execution for a human decision, and records the entire interaction for later replay. The gateway is the only place where enforcement can happen because it controls the traffic flow and holds the credential that the agent would otherwise use.
How hoop.dev enables approval workflows for AWS
hoop.dev implements the required gateway. The agent authenticates to hoop.dev with its OIDC token; hoop.dev validates the token and extracts the group membership that determines the agent’s baseline permissions. When the agent attempts an AWS API call that matches a policy rule marked for review, such as creating or modifying IAM roles, opening inbound ports, or altering bucket ACLs, hoop.dev intercepts the request and triggers an approval workflow. A designated approver receives a notification, reviews the exact command, and either authorizes or rejects it. Until approval is granted, the request does not reach the AWS endpoint.
Because hoop.dev holds the AWS credential, the agent never sees the secret. The gateway also records every request and response, providing a replayable session log that auditors can examine. Inline masking can be applied to any sensitive fields returned by AWS, ensuring that downstream logs do not expose secrets. All of these enforcement outcomes, approval, recording, masking, exist only because hoop.dev sits in the data path.
Next steps
Start by reviewing the getting‑started guide to deploy the gateway in your environment. The documentation explains how to configure OIDC federation, define least‑privilege IAM roles for AI agents, and create policy rules that require approval. For deeper insight into the feature set, explore the feature documentation. When you are ready to inspect the source code or contribute improvements, visit the open‑source repository at github.com/hoophq/hoop.
FAQ
- Do I need to change my existing IAM roles? You keep your existing roles, but you grant the gateway a credential that can act on their behalf. The agent’s OIDC identity is mapped to a minimal role, and hoop.dev enforces the additional approval layer.
- Can approval workflows be automated for low‑risk actions? Yes. Policy rules can specify which API calls require manual sign‑off and which are auto‑approved based on risk level, keeping the workflow fast for routine tasks.
- What happens to audit data after a session ends? hoop.dev stores a replayable log of the entire session. The log can be exported to your SIEM or retained in a compliant storage bucket for the period required by your governance framework.
