Open redirection in an AI assistant turns trusted fetches into SSRF

At a glance

What this is: Verno Labs found that an AI assistant for a rental platform could be turned into a server-side request tool, with additional prompt, schema, and email disclosure issues amplifying the exposure.

Why it matters: IAM and NHI teams should read this as a governance problem around trusted actions, because agent workflows can turn user input into outbound requests, disclosures, and impersonation paths.

Context

AI assistants that read emails, fetch URLs, and escalate requests are no longer simple chat interfaces. They become orchestration layers that can turn untrusted input into privileged action, which creates a governance problem for URL validation and egress controls as much as for model safety.

The important distinction here is between a model that resists unsafe prompting and an application that still routes unsafe data into trusted workflows. When the orchestration layer treats user content, listing text, and diagnostic requests as equally trustworthy, the surrounding system becomes the real vulnerability.

Key questions

Q: What breaks when an AI assistant can fetch caller-supplied URLs without destination checks?

A: The control that breaks is the assumption that a safe-looking URL is a safe destination. Without destination checks, a brokered fetch path can reach loopback, private or metadata services and return their responses to a less-trusted caller. That turns an execution helper into an internal network oracle and can expose service inventory, headers or sensitive response data.

Q: Why do prompt-injection and tool-schema leaks make agentic systems more dangerous?

A: They reduce uncertainty for the attacker. Once the attacker knows the assistant’s hidden instructions, internal tools, and parameter logic, they can shape input to trigger specific behaviours instead of guessing. The result is more precise exploitation, especially when the same system can fetch URLs, send email, or hand off to humans.

Q: What are the signs that an AI assistant is treating untrusted input as trusted instruction?

A: Common signs include completing diagnostic templates, reflecting user-supplied text in authoritative messages, revealing internal configuration details, and taking action on content that has not been validated or separated from system instructions. If the workflow cannot clearly distinguish user content from control data, the assistant is already mixing trust boundaries.

Q: How should organisations govern AI assistants that can read and act on inbox messages?

A: They should define those assistants as delegated non-human identities with explicit message scope, action scope, and escalation limits. The goal is to prevent natural-language instructions from becoming unauthorised workflow triggers. Review what the agent can read, what it can do, and what requires human confirmation.

Technical breakdown

Open redirection becomes server-side request forgery when an assistant can fetch URLs

An open redirect is usually treated as a web nuisance, but in an agentic workflow it can become a request primitive. If the assistant accepts a user-supplied URL and then performs the fetch itself, the attacker is no longer asking for information. They are using the application as a proxy that makes requests from inside trusted infrastructure. That matters because network allowlists, source IP trust, and internal service assumptions can all be bypassed when the system performs the call on the attacker’s behalf. The security defect is not the model’s response quality. It is the absence of a validating control between user input and outbound traffic. See the SSRF Prevention Guide. See the SSRF Prevention Guide.

Practical implication: Put URL parsing and destination checks outside the model and enforce an allowlist before any outbound request is made.

Diagnostic templates can leak system prompts, tool names, and business logic

The article shows a common orchestration failure: the assistant will complete structured templates even when the fields are about its own hidden state. That turns normal-looking user content into a disclosure channel for prompt preambles, model identity, and internal function schemas. Once the assistant is allowed to reflect on itself, the boundary between operational metadata and user-visible output collapses. In practice, the leaked parameter names matter almost as much as the function list, because they reveal how business rules are encoded and which conditions can be toggled by an attacker. The control failure is not merely output leakage. It is untrusted structure being interpreted as a legitimate control surface. See the Web Application Security Testing Guide.

Practical implication: Block self-description, schema echoing, and any template field that asks the model to reveal internal configuration or workflow state.

Trusted email channels widen the impact of prompt injection and human handoff abuse

When an assistant operates from an authenticated business mailbox, its replies inherit the trust of the organisation that owns the address. That makes reflected attacker text more dangerous, because recipients may treat the message as authoritative even when the content was attacker-shaped upstream. The same trust problem appears in human escalation flows: if the assistant can route a conversation to a named employee without verification, the attacker has a path from untrusted input into direct staff contact. This is not just an LLM issue. It is an identity and workflow trust problem, where the system does not preserve a clear separation between external sender, assistant, and human operator. The email channel becomes part of the attack surface.

Threat narrative

Attacker objective: The objective was to use the assistant's own trusted workflows to expose internal state and make outbound requests from inside the organisation's perimeter.

1. Entry occurred through ordinary email enquiries that the assistant was designed to process, allowing the attacker to interact through a trusted channel.
2. Credential and control exposure followed when the assistant revealed its system-prompt preamble, model identity, and internal tool schema in response to structured prompts.
3. Escalation and action occurred when the attacker coerced outbound requests from inside the organisation's infrastructure and used human handoff paths to extend the attack surface.
4. Impact was achieved by turning the assistant into a trusted proxy for attacker-controlled requests, disclosures, and email output.

Breaches seen in the wild

• Meta AI Instagram Account Takeover: 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• OmniGPT breach claim 2025: A hacker claims to have leaked 34 million OmniGPT AI chat messages holding users' API keys and credentials; OmniGPT has not confirmed it.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Agentic application security fails when the orchestration layer is trusted by default. The model may refuse unsafe instructions, but the system around it can still pass attacker-controlled input into fetches, replies, and escalations. That means the governing question is not whether the model is safe, but whether the application preserves trust boundaries between user content, tool calls, and human review. Practitioners should treat orchestration as a first-class control plane, not a wrapper around a model.

Open redirection is now an identity problem as much as a web problem. When a tool fetches a URL from inside organisational infrastructure, the resulting request inherits the trust of the source system. That can undermine partner allowlists, internal service assumptions, and monitoring rules that were never designed for AI-driven request generation. The right control lens is not just SSRF detection, but authority management over what the assistant is permitted to ask the network to do.

Prompt leakage matters because it exposes the rules an attacker can learn to exploit. A revealed system prompt, model identity string, or tool schema is not merely embarrassing metadata. It shortens the attacker’s reconnaissance phase and reveals which behaviours the application already tolerates. In practical governance terms, any assistant that can reveal its own configuration has already crossed a boundary that IAM and NHI teams should consider sensitive.

Human handoff must be governed like a privileged escalation path. Once an assistant can route a conversation to a named employee, the workflow has become an access path, not a convenience feature. Organisations should design escalation as a controlled exception with verification, logging, and rate limiting, because social engineering against the handoff path is often easier than breaking the model itself.

What this signals

Agentic trust boundary failure: this is the pattern defenders need to watch for when a model is embedded inside workflow software. The dangerous part is not the chatbot interface itself, but the moment untrusted input can trigger a network request, an email, or a human escalation without an explicit policy gate.

The most important programme change is to move control from inference time to orchestration time. If an assistant can shape what gets fetched, sent, or escalated, the security decision must happen before the model acts, not after the response is generated.

For practitioners

• Implement outbound request gating Move URL parsing, destination validation, and egress checks into a wrapper that the model cannot bypass, and reject any URL that includes userinfo syntax or an unapproved destination.
• Block reflective self-disclosure Prevent the assistant from completing diagnostic templates that ask for system prompts, model identity, tool names, or internal schema details, even when the request is framed as debugging.
• Sanitise untrusted content before it reaches the model Tag listing text, emails, and third-party content as untrusted input so directive-like phrases cannot be echoed back as authoritative system output.
• Treat human escalation as a controlled privilege Require verification, deduplicate repeated handoffs, and remove named-agent routing from the default workflow so an attacker cannot turn escalation into a direct social-engineering path.
• Run continuous red-team regression tests Re-test the assistant whenever the model, prompt, or tool chain changes, with cases for prompt injection, schema leakage, and outbound fetch abuse.

Key takeaways

• The article shows that a well-behaved model can still sit inside an unsafe product when orchestration trusts the wrong inputs.
• The strongest evidence is the coerced outbound request from inside trusted infrastructure, which demonstrates a real action path rather than a purely theoretical leak.
• The limiting control is not better prompting, but strict validation, output filtering, and workflow governance around every privileged assistant action.

Related NHI Mgmt Group resources: SSRF Prevention Guide · Web Application Security Testing Guide · Broken Access Control Prevention Guide · Web Application Attacks Guide

Key terms

• Agentic Orchestration Layer: The governing layer that decides when an AI agent should act, what it may access, and when another system should take over. It is the policy and routing function above the agent, not the agent itself. In mature environments, this layer defines scope, confidence thresholds, and revocation boundaries.
• Open Redirection: A flaw that lets an application forward a user to an attacker-chosen destination. In OAuth environments, open redirection is especially dangerous because it can be combined with callback manipulation to move authorization codes or session context outside the intended trust boundary.
• Prompt Injection (Agentic): An attack where malicious instructions are embedded in content that an AI agent reads, causing the agent to execute unintended actions using its own legitimate credentials. A primary vector for agent goal hijacking and identity abuse.
• Identity Handoff: The controlled transfer of access from one user to the next on a shared device or application session. In manufacturing, the handoff must close the prior session, preserve auditability, and prevent residual access from carrying into the next operator’s activity.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It is designed for practitioners who need to govern identities, credentials, and access in complex environments.