In an ideal world every automated job, CI runner, or server‑to‑server script that touches AWS resources leaves an immutable audit trail that ties the action back to a distinct identity. Security teams can answer who ran a query, which pod updated a secret, and exactly when a change occurred without hunting through logs or guessing which credential was used.
Most organizations fall short of that ideal. They create a single IAM role for all build pipelines, store its access key in a shared secret store, and hand the key to dozens of services. The role has broad permissions, and the key is checked into repositories or copied between environments. When a pipeline fails or a rogue container is compromised, there is no way to tell which component performed the offending call because the same credential was used everywhere. The audit trail ends up a flat list of API calls with no attribution to the originating non‑human entity.
Non‑human identity, service accounts, CI tokens, or machine identities, was introduced to give each automated actor a unique principal. That change makes it possible to grant the minimum set of permissions needed for a specific job. However, simply issuing a distinct token does not automatically create a useful audit trail. The request still travels directly from the service to the AWS control plane. Without a control point that records the request, masks sensitive response fields, or requires an approval for risky operations, the audit trail remains incomplete and the organization cannot enforce policy at the moment of access.
Why the audit trail still breaks
The core problem is the lack of a data‑path enforcement layer. The setup, OIDC providers, federated identities, and least‑privilege IAM policies, decides who the request is and whether it may start. It is necessary, but it does not guarantee visibility or protection. When a service account calls the AWS API, the call bypasses any intermediate guardrails. The request reaches the target directly, and the only evidence collected is whatever AWS CloudTrail records, which often lacks context such as the originating host, the exact command line, or masked payloads.
Because the enforcement point is missing, the organization cannot:
- Capture a full audit trail that includes request metadata beyond what CloudTrail provides.
- Apply inline masking to prevent secrets from appearing in logs.
- Require just‑in‑time approval for privileged actions like deleting a production database.
- Block dangerous commands before they reach the service.
All of these capabilities must live in the data path, where the request can be inspected and controlled.
Introducing a gateway in the data path
To close the gap, organizations need an identity‑aware proxy that sits between non‑human identities and AWS services. That proxy must verify the token, enforce policy, record every interaction, and forward only approved traffic. hoop.dev provides exactly that architectural layer.