An AI‑driven code‑generation job runs nightly in a CI pipeline and pushes changes directly to an AWS account. The team replaced the developer’s personal access key with a non-human identity, thinking that alone would secure the automation. Yet the job still authenticates with a hard‑coded token that grants full S3, DynamoDB, and Lambda permissions, and the pipeline never logs which commit triggered a write. When the job misbehaves, the only evidence is a stray object in a bucket.
Using non-human identity for the AI agent is the first step toward secure automation. Switching the job to a dedicated service account seems like a quick fix. The service account receives an IAM role with a narrower policy, and the CI system injects the role’s temporary token at runtime. The token is still handed straight to the AWS SDK, which talks to the AWS control plane without any intervening check. The job now runs with a tighter scope, but the organization still lacks a way to see exactly what API calls were made, to block dangerous operations, or to hide secrets that might be returned in responses.
What the organization really needs is a control point that sits on the data path between the AI agent and AWS. That point must be able to enforce policies, capture evidence, and apply real‑time transformations while still allowing the agent to use its non-human identity.
Why non-human identity alone is not enough
Non-human identity solves the credential‑sprawl problem. By issuing a unique IAM role per agent, you reduce the blast radius of a compromised secret. However, the role is still presented directly to AWS, which means:
- There is no independent audit of each request. AWS logs who called what, but the logs are not tied back to the originating CI job without additional correlation.
- Dangerous API calls such as DeleteBucket or PutSecretValue cannot be intercepted or required to go through an approval workflow.
- Sensitive response fields, such as secret values returned by GetSecretValue, are sent back to the agent in clear text.
- The agent has full visibility into the credentials it uses, which defeats the purpose of a “never see the secret” model.
All of these gaps remain as long as the request travels directly to AWS. The enforcement outcomes that matter for security and compliance live only where the request is inspected.
Introducing a data‑path gateway
hoop.dev provides the required data‑path gateway. It sits between the AI coding agent and any AWS service that the agent accesses. The gateway receives the agent’s OIDC token, validates the non-human identity, and then proxies the request to AWS using its own short‑lived credential that matches the agent’s policy.
Because hoop.dev is the only point that can see the traffic, it can enforce the following outcomes:
- Just‑in‑time credential issuance. hoop.dev issues a temporary AWS credential that expires the moment the session ends, ensuring no long‑lived secrets linger.
- Approval workflows. Before a privileged call such as DeleteBucket is forwarded, hoop.dev routes the request to a human approver. The operation proceeds only after explicit consent.
- Inline data masking. When a response contains fields marked as sensitive, hoop.dev redacts those values before they reach the AI agent, preventing accidental leakage into logs or downstream systems.
- Command‑level blocking. hoop.dev can reject a disallowed API call outright, returning an error to the agent without ever touching the target service.
- Session recording and replay. Every request and response is captured by hoop.dev, creating an immutable audit trail that can be replayed for incident investigations.
All of these controls are applied in the data path, meaning they exist only because hoop.dev sits between the identity and the AWS endpoint.
How the architecture fits together
The overall flow looks like this:
- Setup. The AI agent is registered as a non-human identity in your identity provider (Okta, Azure AD, Google Workspace, etc.). The provider issues an OIDC token that contains the agent’s group membership.
- The data path. The agent connects to hoop.dev using its standard AWS SDK or CLI. hoop.dev validates the token, maps the agent’s groups to an AWS role, and establishes a short‑lived credential on behalf of the agent.
- Enforcement outcomes. As the request travels through hoop.dev, the gateway applies approval checks, masks any sensitive fields in the response, records the full session, and blocks disallowed operations.
This separation makes it clear which component is responsible for which security guarantee. The identity provider decides who the request is, hoop.dev decides whether the request may proceed, and the enforcement outcomes exist only because hoop.dev is in the data path.
Getting started with hoop.dev for AWS
To try this pattern, follow the getting‑started guide. It walks you through deploying the gateway with Docker Compose, configuring an OIDC connection, and registering an AWS connection that uses an IAM role. The guide also shows how to enable session recording and inline masking for AWS responses.
For deeper details on the feature set, such as how approval workflows are defined or how masking rules are written, see the learn section. The documentation explains the policy model without exposing any code snippets, and it points you to the exact configuration files you need to edit.
FAQ
Do I still need IAM policies on the AWS side?
Yes. hoop.dev uses an IAM role that is scoped to the minimal permissions required for the AI agent’s workload. The gateway enforces additional controls that IAM alone cannot provide, such as real‑time masking and approval.
Can I use hoop.dev with other cloud providers?
The gateway supports any of the listed targets, including Kubernetes, SSH, and database services. The same architectural pattern, non-human identity plus a data‑path gateway, applies across all supported connections.
How does hoop.dev keep the agent from seeing the AWS secret?
hoop.dev never exposes the short‑lived AWS credential to the agent. The credential is used internally by the gateway to sign the request, and the agent only sees the result of the operation after hoop.dev has applied any masking or blocking.
Ready to see the code? Explore the open‑source repository on GitHub and start building a secure, auditable pipeline for your AI coding agents.
