When every A2A integration is governed by up‑to‑date access reviews, teams can prove that only the right services talk to each other, and any deviation is instantly visible.
In many organisations, service‑to‑service communication is built on static credentials that are copied into environment files, Docker images or secret stores. Those secrets often live for months, are shared across multiple pipelines, and rarely change. No one regularly asks whether a particular service still needs that permission, and no audit trail shows who invoked which endpoint and when. The result is a sprawling web of standing access that can be exploited if a single secret leaks.
Introducing a formal access‑review process is a step forward. Teams start to inventory which services should call which APIs and schedule periodic sign‑offs. However, the review itself does not stop a compromised service from using an existing secret to reach the target directly. The request still travels straight to the backend, bypassing any real gate that could enforce the latest policy, record the transaction, or hide sensitive fields.
Why access reviews matter for A2A
Access reviews create a documented decision point: a human (or automated policy engine) confirms that Service A is allowed to call Service B. This decision reduces the attack surface by ensuring unnecessary permissions are revoked. It also satisfies compliance auditors who expect evidence that each privileged connection has been examined within a defined window.
Even with a solid review cadence, the enforcement gap remains. The review outcome lives in a spreadsheet or IAM policy, but the data path that carries the request is uncontrolled. If a secret is stolen, the attacker can still reach the backend, and the organization loses visibility into the exploit.
The missing enforcement layer
Setup components such as OIDC identity providers, service accounts and least‑privilege IAM roles decide who may start a request. They are essential for authentication and for defining the scope of a token, but they do not inspect the traffic itself. Because enforcement is not placed in the data path, there is no guarantee that a request complies with the latest access‑review decision at the moment it is made.
Without a gateway that sits between the caller and the target, the only place to enforce policy would be inside the service itself. That approach is fragile: each service would need custom code to check the review status, and any bug would re‑introduce blind spots. A centralized data‑path enforcement point provides a single, auditable surface for all A2A traffic.
hoop.dev as the data‑path gateway for A2A
hoop.dev is a Layer 7 gateway that proxies A2A connections. It sits on the network edge, receives the request after authentication, and then forwards it to the target service. Because the request passes through hoop.dev, the gateway can apply the latest access‑review verdict in real time.
When a service initiates a call, hoop.dev checks the current review state. If the review has not been approved, hoop.dev can pause the request and route it to a human approver, or automatically block it. This just‑in‑time approval ensures that stale permissions never get exercised.
Every session that traverses hoop.dev is recorded. hoop.dev stores a replayable log that includes the identity of the caller, the target endpoint, and the exact payload. Auditors can retrieve that evidence to prove that each A2A interaction was authorized at the time it occurred.
For responses that contain sensitive data, such as personally identifiable information or internal keys, hoop.dev can mask those fields before they reach the caller. The masking happens inline, so the downstream service never sees the redacted data and the upstream service never receives the raw secret.
Because the gateway holds the credential used to reach the backend, the calling service never sees the actual password or token. This “the agent never sees the credential” property reduces the blast radius of a secret leak.
All of these enforcement outcomes, just‑in‑time approval, session recording, inline masking and credential shielding, exist only because hoop.dev occupies the data path. Removing the gateway would instantly eliminate the audit trail and the ability to enforce the latest review decision.
To get started, follow the getting started guide and explore the feature overview for detailed policy examples. The open‑source repository is available on GitHub: Explore the open‑source code on GitHub.
FAQ
- Do I need to change my existing service code? No. hoop.dev works with standard client libraries (HTTP, gRPC, database drivers, etc.). The service points its endpoint to the gateway and continues to use its usual protocol.
- Can I still use my existing identity provider? Yes. hoop.dev acts as a relying party for OIDC or SAML providers, so you keep your current IdP and simply configure the gateway to trust it.
- What evidence does hoop.dev provide for auditors? hoop.dev records each session, captures any approval decision, and can mask sensitive fields in responses; the resulting logs can be exported for audit purposes.
