Putting access controls around Cursor: audit trails for AI coding agents (on AWS)

How can you be sure an AI coding agent isn’t silently reading or writing data on your AWS workloads, and that audit trails capture every action?

Many teams treat Cursor, the AI‑powered coding assistant, as just another client. They grant the service a static IAM role, embed the credentials in a CI pipeline, and let the agent connect directly to databases, S3 buckets, or Lambda functions. The connection is long‑lived, the permissions are broad, and the logs that AWS emits are coarse‑grained – they show that the role was used, not which line of generated code triggered a query or a file write. In practice this means a developer can ask the AI to refactor a function, and the resulting data‑plane actions disappear into the background without any per‑request visibility.

This lack of granularity becomes a compliance headache. Auditors ask for evidence that every AI‑driven operation is traceable, that no secret was exfiltrated, and that any unexpected command can be investigated. The current setup fixes the obvious problem – the agent can reach the target – but it leaves the critical controls missing: there is no audit trail that ties a specific AI suggestion to the exact API call, no real‑time review of risky actions, and no replay capability for post‑mortem analysis.

Why audit trails matter for AI‑driven development

Audit trails give you a forensic record. They let you answer questions such as:

• Which user prompted the AI, and what was the exact prompt?
• What database query or infrastructure command did the AI generate?
• Did the operation touch a secret, and was the secret masked in the response?

Without a dedicated layer that inspects each request, these answers are unavailable or buried in noisy cloud‑provider logs. The gap is not a shortcoming of IAM or OIDC; it is the absence of a data‑path enforcement point where every packet can be examined, approved, or recorded.

Introducing hoop.dev as the enforcement layer

hoop.dev is a Layer 7 gateway that sits between the Cursor AI agent and your AWS resources. It authenticates users and service accounts via OIDC or SAML, then proxies the connection through a network‑resident agent that never exposes the underlying credentials. Because the gateway is the only place the traffic passes, hoop.dev can enforce the controls you need.

When a request arrives, hoop.dev:

• Records each session, creating a complete audit trail that links the AI prompt to the exact API call.
• Applies inline masking to any response that contains sensitive fields, ensuring secrets never leave the gateway in clear text.
• Requires just‑in‑time approval for commands that match a risky pattern, pausing execution until a human reviewer signs off.
• Blocks disallowed commands before they reach the target, preventing accidental destructive actions.
• Provides replay capability so you can watch a recorded session and verify what the AI actually did.

All of these outcomes exist because hoop.dev sits in the data path. The initial identity verification (the Setup) decides who may start a request, but the enforcement – audit trails, masking, approval – happens exclusively inside the gateway.

Architectural flow for Cursor on AWS

1. Setup: You configure an OIDC provider (for example, Azure AD or Okta) and assign a minimal IAM role to hoop.dev’s internal service identity. The role grants only the permissions required for the specific AWS resources the AI will touch.

2. Connection registration: In the hoop.dev console you register the target AWS service – a RDS PostgreSQL instance, an S3 bucket, or a Lambda endpoint – and attach the IAM role. The gateway stores the credential; the Cursor agent never sees it.

3. Request flow: The AI agent issues a request through the standard client (e.g., the AWS CLI or a database driver). The request is intercepted by hoop.dev, which validates the OIDC token, checks policy, and then forwards it to the AWS service.

4. Enforcement: During forwarding, hoop.dev records the request, applies any masking rules, and, if the request matches a high‑risk policy, pauses for approval. Once approved, the request reaches the service and the response follows the same path back through hoop.dev, where it can be masked again before delivery.

This pattern guarantees that every interaction is captured in an audit trail, regardless of how the AI agent is invoked.

Getting started

To try this yourself, start with the getting‑started guide. It walks you through deploying the gateway, configuring OIDC, and registering an AWS target. The documentation also explains how to define masking policies and approval workflows that are relevant to AI‑generated code.

For deeper insight into policy design, the learn section contains examples of audit‑trail configuration, just‑in‑time approval rules, and session replay usage.

All of the source code and deployment manifests are available in the public repository. Explore the hoop.dev GitHub repo to see how the gateway is built and to contribute improvements.

FAQ

Does hoop.dev replace AWS CloudTrail?

No. CloudTrail records actions at the service level, but it does not capture the exact request payload generated by an AI agent. hoop.dev records the full session, linking the AI prompt to the underlying API call, which complements CloudTrail for a complete audit picture.

Can I use hoop.dev with existing Cursor deployments?

Yes. hoop.dev works as a transparent proxy, so you keep your existing Cursor client configuration. You only need to point the client at the gateway endpoint and ensure the OIDC token is valid for the gateway.

Is there any performance impact?

hoop.dev adds a small, predictable latency because each request passes through an additional network hop. The benefit of fine‑grained audit trails and real‑time policy enforcement typically outweighs the overhead for most development workflows.