Is your Azure environment truly enforcing least privilege, or are agents silently masquerading as privileged identities?
Understanding agent impersonation
Most organizations protect Azure resources by assigning narrow RBAC roles to service principals, managed identities, or Azure AD applications. The idea is simple: give each identity only the permissions it needs to do its job, and nothing more. In practice, the code that runs on a build server, a CI/CD pipeline, or a background daemon talks to Azure using a token obtained from Azure AD. That token is then presented to Azure Resource Manager (ARM) or a specific service such as Azure Key Vault.
When an attacker compromises the host that runs the agent, they inherit the agent’s ability to request tokens from Azure AD. Because the agent already possesses a credential that can call the Instance Metadata Service or the Azure AD token endpoint, it can ask for a token representing any identity that the host is allowed to request. In many deployments the host is granted the Managed Identity Operator role, which effectively lets the agent acquire tokens for other managed identities. The result is an impersonation chain: a low‑privilege service principal is used as a stepping stone to obtain a high‑privilege token, and the attacker can now act with rights far beyond the original assignment.
This pattern is not limited to managed identities. A compromised Azure DevOps agent can reuse the personal access token it stores to request fresh OAuth tokens for other scopes, or a compromised Kubernetes pod can reach out to the Azure CLI on the node and invoke the Azure login command using the system‑assigned identity. The underlying issue is that the token request happens inside the compromised process, bypassing any external control point.
Why least privilege alone is insufficient
The initial setup, defining roles, configuring OIDC‑based authentication, and restricting token scopes, decides who can start a request. That is the setup layer. It is necessary because without a clear identity model Azure cannot enforce any policy. However, it does not guarantee that the request will be safe once it leaves the agent.
When the agent sends a request directly to Azure’s control plane, the request travels over the network unmediated. No audit log is captured at the moment of execution, no inline data masking occurs, and no just‑in‑time approval step can intervene. The request reaches the target resource with the full set of permissions encoded in the token, even if those permissions were obtained through impersonation. In short, the enforcement point is missing.
Placing enforcement in the data path
This is where a Layer 7 gateway becomes essential. By inserting a gateway between the agent and Azure’s APIs, every API call can be inspected, authorized, and recorded before it reaches the target. The gateway operates at the protocol level, understands the Azure REST calls, and can enforce policies such as:
- Require a human approval for any role‑assignment write operation.
- Block attempts to read secrets from Azure Key Vault unless the request originates from a pre‑approved workflow.
- Mask sensitive fields, like connection strings, in responses that are streamed back to the client.
- Record each request and response for replay and audit, providing a complete evidence trail.
Because the gateway holds the credential needed to talk to Azure, the agent never sees the secret. Even if the agent is compromised, it can only forward traffic through the gateway, and the gateway will apply the policies that embody true least‑privilege enforcement.
How hoop.dev implements this model
hoop.dev provides exactly the data‑path gateway described above. It sits between identities (including service accounts, managed identities, and AI agents) and Azure resources. The gateway validates OIDC tokens, reads group membership, and then applies fine‑grained policies before forwarding the request. By doing so, hoop.dev turns a simple token‑based connection into a controlled, auditable session that respects least privilege even in the face of agent compromise.
Key capabilities that enable this include:
- Just‑in‑time access: Permissions are granted only for the duration of a session and can be scoped to a single API call.
- Approval workflows: High‑risk operations trigger a manual approval step before the gateway forwards the request.
- Session recording: Every request and response is logged, allowing replay for forensic analysis.
- Inline data masking: Sensitive fields are redacted in real time, preventing accidental leakage.
All of these outcomes rely on hoop.dev being present in the data path; without it, the setup alone cannot provide the same guarantees.
Getting started
To evaluate this approach in your Azure environment, start with the getting‑started guide. The guide walks you through deploying the gateway, registering Azure connections, and configuring OIDC authentication. For deeper insight into policy definitions and guardrail features, see the learn section of the documentation.
FAQ
Does hoop.dev replace Azure RBAC?
No. Azure RBAC remains the source of truth for what each identity is allowed to do. hoop.dev enforces those permissions at the gateway, adds approval steps, and records every action.
Can a compromised agent still obtain a token from Azure AD?
The agent can request a token, but hoop.dev will evaluate the token against its policies before allowing any API call. If the request exceeds the allowed scope, the gateway blocks it or requires approval.
Is session data stored securely?
Session logs are written to a storage backend that you configure. hoop.dev does not expose the raw credentials to the client, and you can apply your own encryption or retention policies to the log store.
By moving enforcement out of the agent and into a dedicated gateway, you close the gap that lets impersonation erode least privilege. For the full source code and contribution guidelines, visit the GitHub repository.
