Are you trusting your AI agents to Azure with the same static credentials you hand to a human operator, or have you moved to a non-human identity model? The answer determines how much control you really have over what the agent can do, and how you can prove that control to auditors.
Azure supports managed identities and service principals that are issued by Azure AD. Each token is bound to a specific application or workload, and the token’s claims describe exactly which resources the workload may access. Because the token is short‑lived and can be scoped to a single Azure resource, the risk of credential leakage is dramatically reduced.
Shared service accounts are long‑lived usernames and passwords (or keys) that multiple processes can reuse. They are easy to provision: a single secret is stored in a vault and distributed to every automation that needs it. For teams that have not yet adopted Azure AD‑based identities, shared accounts provide a quick way to get AI agents talking to databases, storage, or Kubernetes without re‑architecting authentication flows.
When an AI agent authenticates with a non-human identity, the platform validates the token and then enforces the permissions before any request reaches the target service.
When each approach falls short
Non-human identity is sufficient when the AI workload is well‑defined, the required permissions are narrow, and the organization enforces strict token issuance policies. However, identity alone does not give you visibility into what the agent actually typed, nor does it let you block a dangerous command in real time. If an attacker compromises the workload’s runtime, they inherit the same scoped token and can still issue any allowed API call.
Shared service accounts appear to work when you need to grant the same broad set of permissions to many agents quickly. The downside is that the same secret lives on every host, making it a single point of failure. If the secret is exposed, an attacker can impersonate any agent that uses it, and there is no built‑in audit of which command caused the breach.
Risk profile of AI agents
AI agents often generate queries or commands on the fly, based on user prompts or automated workflows. That dynamism means a static credential can be abused in ways the original developer never imagined. A non-human identity limits the blast radius by constraining the agent to a predefined Azure role, but it does not stop the agent from issuing a destructive command that the role permits.
Conversely, a shared service account gives the agent unrestricted access to everything the account can reach. The lack of context makes it impossible to differentiate a legitimate automated task from a malicious one.
Adding enforceable controls with a gateway
Both approaches rely on Azure AD (or a similar identity provider) to decide who is making the request. That setup step is essential, but it does not enforce policy on the traffic itself. The enforcement must happen in the data path, where the request travels to the target service.
hoop.dev provides that data‑path enforcement. It sits as a Layer 7 gateway between the AI agent and Azure resources. The gateway receives the identity token, validates it, and then inspects each protocol message before it reaches the backend.
How hoop.dev fits the architecture
The identity provider (Azure AD) issues a token that identifies the agent. hoop.dev validates the token and extracts the group or role information. From that point onward, every request passes through hoop.dev’s proxy, which is the only place where guardrails can be applied.
Enforcement outcomes hoop.dev provides
- Session recording – every command and response is captured for replay and audit.
- Inline data masking – sensitive fields in responses are redacted in real time.
- Just‑in‑time approval – risky operations are routed to a human approver before execution.
- Command blocking – disallowed statements are rejected before they reach the target.
- Audit trail – a log of who did what, when, and why.
Because hoop.dev is the sole gateway, these outcomes exist only because the enforcement sits in the data path. Removing hoop.dev would eliminate the recording, masking, approval, and blocking capabilities, even though the Azure AD token would still identify the agent.
Operational considerations
When you adopt non-human identity, you still need to manage token rotation and expiration. hoop.dev can be configured to refresh credentials automatically, keeping the gateway’s connection to Azure up‑to‑date without human intervention.
If you continue to use shared service accounts, hoop.dev reduces exposure by storing the secret inside the gateway configuration instead of on every host. The gateway becomes the single point of secret management, which simplifies rotation and revocation.
Choosing the right model for your organization
Start by mapping the AI workload’s required permissions. If they can be expressed as a narrow Azure role, move to a managed identity – that gives you the strongest identity guarantee.
If the workload needs broader access that cannot be split cleanly, you may have to keep a shared service account, but you should still place hoop.dev in front of it to gain visibility and control.
In both cases, the combination of Azure AD for identity and hoop.dev for data‑path enforcement creates a defense‑in‑depth stack: identity decides who can ask, the gateway decides what they may actually do.
Getting started
Deploy the gateway near your Azure resources using the Docker Compose quick‑start, configure the Azure connection with the appropriate managed identity or service principal, and enable the guardrails you need. The getting‑started guide walks you through the deployment steps, and the learn section explains how to tune masking and approval policies.
FAQ
Do I still need Azure AD roles if I use hoop.dev?
Yes. Azure AD decides which token the agent receives. hoop.dev then enforces what the agent can do with that token.
Can hoop.dev work with existing shared service accounts?
It can. hoop.dev will proxy the connection, but the shared secret will be stored in the gateway configuration, not on the agent, reducing the exposure surface.
What happens if an AI agent tries to exfiltrate data?
hoop.dev can mask the sensitive fields in the response and, if the operation matches a high‑risk pattern, require a human approver before the data leaves the gateway.
Explore the open‑source repository on GitHub to see the code, contribute, or customize the policies for your environment.
