When machines talk to machines without a human eye, a single compromised credential can let an attacker roam unchecked across your entire stack.
In A2A flows, a non-human identity is the digital representation of a service, script, or AI agent that authenticates to other services. These identities are convenient for automation, but they also become high‑value targets because they often carry broad permissions and are long‑lived.
Non-human identity considerations
Because a non-human identity does not have a person to notice a breach, you must build visibility and controls directly into the communication path. The most common pitfalls include:
- Static credentials. Hard‑coded passwords or API keys in code repositories make rotation painful, so teams leave them unchanged for months.
- Over‑privileged scopes. Service accounts are frequently granted admin‑level access to simplify development, amplifying the blast radius of a compromise.
- Missing audit trails. When a script calls a database or an internal API, the request often bypasses logging, leaving no evidence of who performed which operation.
- No real‑time data protection. Sensitive fields returned by a service (e.g., PII in a JSON payload) travel in clear text to downstream services, increasing exposure risk.
These gaps are not fixed by identity providers alone. An OIDC or SAML token can prove who the caller is, but without a gate that inspects the payload, the token cannot enforce command‑level policies, mask data, or require approval for risky actions.
Why a Layer 7 gateway is the missing piece
To protect non‑human identities, the enforcement point must sit on the data path between the caller and the target service. A Layer 7 gateway can:
- Record every session, creating a retained audit trail that can be stored according to your retention settings.
- Apply inline masking to redact sensitive fields before they reach downstream systems.
- Block or reroute commands that match a risk policy, ensuring that dangerous operations never execute.
- Require just‑in‑time approval for high‑impact actions, turning a static credential into a controlled, auditable request.
Because the gateway terminates the protocol, it can see the full request and response, something that a token‑validation step cannot achieve.
How hoop.dev implements the control surface
hoop.dev is an open‑source Layer 7 access gateway that sits between non‑human identities and the infrastructure they reach. It authenticates callers via OIDC/SAML, then enforces policy on the connection itself. The gateway holds the target credentials, so the calling service never sees them. All of the enforcement outcomes, session recording, inline masking, just‑in‑time approval, and command blocking, are possible only because hoop.dev occupies the data path.
Deploying hoop.dev is straightforward: a Docker Compose quick‑start brings up the gateway and a network‑resident agent that proxies connections to databases, Kubernetes, SSH, HTTP APIs, and more. Once the gateway is running, you register each target resource, define the policies you need, and let your automation use standard clients (psql, curl, kubectl, etc.) through the hoop.dev endpoint. For a step‑by‑step guide, see the getting started documentation. To dive deeper into masking, approval workflows, and audit capabilities, explore the learn section.
Key practices for securing non‑human identities
Even with a gateway in place, you should follow these best practices:
- Rotate credentials regularly. Use the gateway’s ability to store credentials centrally so rotation does not require code changes.
- Apply least‑privilege scopes. Define fine‑grained policies in hoop.dev that limit each service account to the exact resources it needs.
- Enable session replay. When an incident occurs, hoop.dev lets you replay the exact command sequence to understand the impact.
- Mask sensitive data. Configure field‑level masking for PII, secrets, or proprietary data so downstream services only see what they need.
Frequently asked questions
What differentiates a gateway approach from just using OIDC tokens?
OIDC tokens prove identity but do not see the payload. A gateway like hoop.dev sits on the data path, allowing it to enforce policies, mask data, and record every interaction. Without that middle layer, non‑human identities can still perform unrestricted actions.
Can hoop.dev work with existing service accounts?
Yes. You register the existing credentials with the gateway, and hoop.dev proxies connections on their behalf. The service accounts keep their original permissions, but access now requires passing through the gateway’s controls.
Is the audit data stored securely?
hoop.dev records each session, providing a retained audit trail that can be stored according to your retention policy. The storage backend is configurable to meet your security requirements.
By placing a Layer 7 gateway between non‑human identities and the services they call, you gain the visibility and control needed to prevent credential abuse, limit blast radius, and satisfy audit requirements.
Explore the open‑source project on GitHub to get started or contribute.
