When nested agents run on Azure, every LLM request is inspected, any attempt to inject a prompt is blocked, and the full interaction is recorded for audit, dramatically reducing prompt-injection risk.
Nested agents are a pattern where one language‑model‑driven service calls another, often passing user‑supplied text along the chain. In Azure environments this typically looks like an Azure OpenAI endpoint being invoked by a custom API, which then forwards the response to a second OpenAI call that adds context or performs a follow‑up action. The convenience is undeniable: developers can compose sophisticated workflows without writing new model prompts for each step.
Why nested agents amplify prompt‑injection risk
Each hop in the chain is an opportunity for an attacker to slip malicious content into the prompt. A classic injection vector is a user‑controlled field that is concatenated into a system prompt before the next model call. Because the downstream agent trusts the upstream output, the injected text can steer the final response, exfiltrate data, or trigger unwanted actions. When the agents share the same credentials or run in the same container, the boundary between them disappears, making it hard to tell which component originated the malicious content.
Most teams implement this pattern without a dedicated inspection point. The first agent authenticates to Azure OpenAI using a static key stored in the codebase. The second agent reuses the same key, and the network traffic flows directly from one process to the Azure endpoint and back. No logs capture the intermediate prompt, no policy checks intervene, and the entire exchange is invisible to security teams.
What the current setup fixes – and what it leaves open
Introducing identity‑aware authentication, such as Azure AD‑backed OIDC tokens, does limit who can start a request. It also allows you to rotate keys more frequently. However, the request still travels straight to the Azure OpenAI service, bypassing any enforcement layer. The system therefore lacks:
- Real‑time inspection of the prompt before it reaches the model.
- Inline masking of sensitive fields that might appear in the response.
- Just‑in‑time approval for high‑risk operations.
- Immutable session records that auditors can replay.
These gaps mean that even with strong identity, prompt-injection risk remains high because there is no place to enforce guardrails.
hoop.dev as the server‑side enforcement point
hoop.dev is a Layer 7 gateway that sits between your agents and the Azure OpenAI endpoint. It acts as the only data path where traffic can be examined, altered, or blocked. Because every request must pass through the gateway, hoop.dev can apply the missing controls without changing the agents themselves.
In practice, you deploy the hoop.dev gateway inside the same virtual network as your Azure resources. The gateway authenticates users and services via OIDC or SAML, reads group membership, and then forwards the request to Azure OpenAI using its own credential. The agents never see the credential, and the gateway retains full visibility of the payload.
Once in the data path, hoop.dev can:
- Detect known prompt‑injection patterns and reject the request before it reaches the model.
- Mask fields such as passwords or personal identifiers in the model’s response, ensuring downstream agents never receive raw secrets.
- Require a human approver for prompts that exceed a risk threshold, turning a purely automated chain into a controlled workflow.
- Record the entire request and response stream, making replay possible for forensic analysis.
All of these outcomes exist only because hoop.dev occupies the gateway position. The identity configuration alone does not provide them; the enforcement logic lives in the gateway.
Practical steps to reduce prompt‑injection risk with nested agents on Azure
- Deploy the hoop.dev gateway in your Azure virtual network. The quick‑start guide walks you through a Docker‑Compose deployment that includes OIDC authentication out of the box.
- Register each Azure OpenAI endpoint as a connection in hoop.dev. The gateway stores the service credential, so your agents never handle it directly.
- Define a policy that flags any prompt containing user‑supplied text that matches injection signatures. hoop.dev will block those calls and log the event.
- Enable inline masking for fields that may appear in responses, such as API keys or personally identifiable information.
- Configure just‑in‑time approval for high‑risk prompts, for example those that request code execution or data export.
- Review recorded sessions regularly to verify that no unexpected prompt‑injection attempts slipped through.
All configuration details, including policy syntax and masking rules, are covered in the official documentation. Start with the getting‑started guide and then explore the feature reference to fine‑tune your guardrails.
FAQ
Do I need to modify my existing agents to use hoop.dev?
No. Agents continue to use their normal client libraries (for example the Azure OpenAI SDK). The only change is the endpoint address – it now points at the hoop.dev gateway instead of the Azure service directly.
Can hoop.dev protect against sophisticated, multi‑step injection attacks?
Because hoop.dev inspects every request at the protocol layer, it can apply both pattern‑based detection and custom scripts that evaluate the full conversation history. This makes it effective against attacks that span multiple hops.
Is the audit data stored securely?
hoop.dev records each session and can forward the logs to your existing log aggregation pipeline. The records provide a complete audit trail that is useful for compliance reviews.
For a hands‑on start, see the getting‑started guide. The full feature set is described on the learn page, and the source code is available on GitHub.
By placing hoop.dev as the mandatory gateway, organizations can turn an open‑ended prompt-injection risk into a manageable control point, preserving the flexibility of nested agents while protecting downstream systems.
