TL;DR: A CVSS 8.8 flaw in LangSmith’s Prompt Hub let a malicious proxy configuration intercept prompts, files, and API keys when users chose a shared agent, according to Noma Security’s research. The case shows that agent reuse, not just model access, creates an NHI governance problem that needs inventory, runtime controls, and review.
At a glance
What this is: Noma Security’s AgentSmith analysis shows how a malicious proxy embedded in a shared AI agent could intercept prompts, files and API keys through LangSmith Prompt Hub.
Why it matters: It matters because AI agent governance now has to account for inherited behaviour, proxy trust and runtime data movement, not only who can log in or who owns the prompt.
Context
AgentSmith is a proxy-based AI agent vulnerability: a malicious proxy configuration can sit between a user and the model, intercepting data that the user thought was flowing directly to the agent. In this case, the issue centred on shared agent reuse inside LangSmith Prompt Hub, where a copied or adopted agent could carry hidden network behaviour with it.
For identity teams, the governance gap is not limited to prompts or model access. When an agent is reused from a public hub, the inherited configuration becomes part of the identity boundary, including where data is sent, which tools are reachable, and whether sensitive inputs can be observed outside the intended workflow.
Noma Security says the flaw was limited to users who explicitly ran a malicious public prompt, and LangChain patched the issue and added warnings. That makes the starting position typical for a modern agent marketplace: collaboration features create distribution speed, but they also create a trust boundary that is easy to misread.
Key questions
Q: What breaks when a shared AI agent hides a malicious proxy configuration?
A: The trust model breaks because the user is reviewing the prompt while the proxy controls the data path. That lets prompts, files, credentials and model outputs leave the intended boundary without obvious signs. Security teams should treat proxy settings as part of the agent’s identity and verify them before reuse.
Q: Why do malicious proxies create more risk in AI agent workflows than in standard app workflows?
A: AI agents often reuse packaged behaviour across teams, so one hidden proxy can be copied into many environments. That combines data interception with inherited trust and makes the exposure persistent across forks. The result is a wider blast radius than a single compromised session normally creates.
Q: How can security teams tell whether a reused agent has unsafe inherited settings?
A: Look for changes in outbound endpoints, tool access, proxy relays, warning suppression and any configuration that was not explicitly approved for the current environment. If the agent arrived from a public hub or another team, it should be treated as untrusted until those inherited settings are confirmed.
Q: Should organisations approve shared AI agents the same way they approve internal prompts?
A: No. A shared agent can carry runtime behaviour, transport settings and downstream access that are not visible in the prompt itself. Approval needs to cover lineage, data paths and execution context, otherwise the organisation is certifying content while ignoring the mechanism that moves the data.
Technical breakdown
How malicious proxies intercept agent traffic
A proxy in this context is an intermediary that relays requests and responses between the user, the agent runtime and downstream APIs. If an attacker can control that proxy configuration, they can observe or alter prompts, uploaded files and API-bound traffic without changing the visible agent interface. That is especially dangerous in agent hubs where configuration is cloned or forked, because the hidden transport path survives reuse. The technical failure is not only payload theft. It is that the agent’s communication channel becomes attacker-controlled while still appearing normal to the user.
Practical implication: Inspect inherited proxy settings as part of agent onboarding, not only agent code or prompts.
Why shared agent reuse expands the trust boundary
Shared agents are not just reusable prompts. They are packaged behaviour, including tool permissions, outbound destinations and hidden dependencies that travel with the agent when it is forked or copied. In a public hub model, the consumer often trusts the agent’s label and description while ignoring the underlying configuration lineage. That creates a governance blind spot: the control surface is broader than the visible prompt. The real question is whether the reused agent is still acting within the organisation’s approved identity and data paths.
Practical implication: Treat cloned agents as inherited software artefacts that require configuration review before first use.
Why proxy-based attacks matter for AI agent governance
Agent governance has to cover runtime trust, not just model selection or prompt review. If a proxy can silently redirect traffic, then confidentiality, integrity and availability are all at risk in the same control plane. The attack can steal credentials, manipulate responses and create ongoing surveillance through repeated use of the same shared agent. That makes agent governance closer to workload identity governance than to simple application administration. The important mechanism is the persistence of hidden behaviour across reuse, which turns one unsafe configuration into a repeatable exposure.
Practical implication: Bind runtime controls, lineage tracking and tool restrictions to the agent before it is allowed into production workflows.
Threat narrative
Attacker objective: The attacker aims to harvest sensitive inputs and reusable API credentials, then use that access to monitor, manipulate or drain the victim’s AI environment.
- Entry occurs when a user adopts or forks a public AI agent that already contains a malicious proxy configuration.
- Credential and data access follow as the proxy intercepts prompts, documents, images, voice inputs and API keys in transit.
- Impact expands when the stolen API key is reused for unauthorized access, data download, quota exhaustion or downstream manipulation of LLM outputs.
Breaches seen in the wild
- CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
- Spain's first AI agent data breach 2026: Spain's AEPD logged its first breach notification attributed to an attacker's AI agent, which altered personal data and accessed invoices.
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
Proxy trust is now part of AI agent identity. Agent reuse in public hubs is not a harmless convenience feature because the proxy path can carry hidden authority alongside the prompt. Once a shared agent can redirect traffic, the organisation is no longer evaluating only model behaviour. The practitioner implication is that agent identity and transport lineage must be reviewed together.
Agent governance fails when configuration is inherited without inspection. The security model for cloned agents assumes the visible prompt is the object being trusted, but the attack shows that transport settings travel too. That creates an inherited proxy trust gap: the user believes they are adopting logic, while they are also adopting a covert data path. The implication is that agent inventory has to include configuration lineage, not only names and owners.
Runtime inspection matters more than static approval for shared agents. A pre-approved prompt can still become unsafe if a proxy redirects data after adoption. That means governance controls based only on review at publication time are incomplete for agent marketplaces. The practitioner implication is to treat runtime behaviour as the enforcement point, especially where agents are forked or reused across teams.
This incident validates the need for agent-specific blast-radius controls. A malicious proxy can expose prompts, credentials and downstream API usage from a single shared artefact, which compresses the blast radius into the reuse chain. For NHI governance, that is the same old lifecycle problem in a new form: the consumer inherits a non-human execution path that was never fully re-authorised. The implication is that ownership, offboarding and revocation must follow the agent wherever it is copied.
Shared agent ecosystems create supply-chain style identity risk. Prompt hubs behave like distribution channels for executable behaviour, not just content repositories. That makes them subject to the same caution applied to third-party NHIs and dependency trust. The practitioner implication is to bring agent marketplaces under the same governance discipline used for external integrations, because the risk is in the packaged behaviour, not the brand name.
From our research library:
- 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to the 2026 Infrastructure Identity Survey.
- Read next: Agentic AI Identity Guide
What this signals
Inherited proxy trust gap: agent marketplaces create a new governance pattern where the visible artefact is not the whole identity boundary. If the transport layer is not inspected, a reused agent can carry covert reach into prompts, files and API traffic. Teams need controls that follow the agent through cloning, forking and re-deployment.
Runtime behaviour now matters as much as publication-time review. A prompt that looked safe when shared can become unsafe when a hidden proxy is attached, which means approval decisions made at the repository level are not enough for operational use.
Shared agents should be governed like third-party execution components, with lineage, outbound destination review and recertification tied to each reuse event.
For practitioners
- Inventory every shared agent and forked agent Track origin, owner, tool access, outbound endpoints and proxy configuration for each agent before it is allowed into operational use.
- Block unreviewed proxy configurations Require explicit approval for any custom proxy, relay or forwarding setting that can observe prompts, files or API traffic.
- Inspect forked agents before reuse Re-open any previously cloned agent and verify that inherited settings still match the intended data path and authorised tools.
- Bind runtime guardrails to agent execution Apply allow and deny rules for external calls, file handling and response sanitization so hidden transport changes do not bypass policy.
- Treat public agent hubs as third-party supply chain inputs Classify community prompts and shared agents as external artefacts that need lineage, validation and periodic recertification.
Key takeaways
- Shared AI agents can conceal transport-layer trust issues that are invisible if teams only review prompts.
- The issue is not just credential theft. It is that the inherited proxy path can intercept prompts, files, model responses and API keys at runtime.
- Governance needs lineage, runtime inspection and proxy control, because reuse can turn one unsafe configuration into repeated exposure.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST AI RMF sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | Shared public agents with hidden proxy settings create third-party trust risk in the reuse chain. |
| NHI-04 — Insecure Authentication | The proxy intercepts traffic that users believe is travelling through an approved agent channel. | |
| NHI-10 — Human Use of NHI | Users adopted a shared agent without seeing the hidden non-human behaviour embedded in it. | |
| Recommendation — Review third-party agent lineage and block reuse until inherited settings are validated. Enforce approved authentication paths and reject agents that alter the trusted transport boundary. Require users to verify non-human behaviour before interacting with shared agents. | ||
| OWASP Agentic AI Top 10 | ASI02 — Tool Misuse | The malicious proxy misuses agent tooling to redirect and exfiltrate runtime data. |
| Recommendation — Constrain agent tool use so proxy-like forwarding cannot occur without explicit approval. | ||
| NIST AI RMF | GOVERN — AI Governance and Accountability | The article is about governance failure around shared AI agent trust and accountability. |
| Recommendation — Assign governance ownership for agent reuse, lineage and runtime trust decisions. | ||
Key terms
- Malicious Proxy Configuration: A malicious proxy configuration is a hidden network route that redirects an agent’s traffic through an attacker-controlled endpoint. It can expose prompts, credentials, and uploaded data without obvious user-visible failure, which makes it a configuration-driven interception risk rather than a model flaw.
- Agent Action Lineage: The trace that connects an AI agent's session, approval source, tool invocation, and resulting outcome. It is the minimum evidence needed to explain what the agent did and whether the behaviour stayed within delegated access and policy boundaries.
- Device Trust Boundary: The device trust boundary is the point where an endpoint is considered sufficiently verified to access systems, data, or services. It defines the security line between trusted and untrusted device states, based on posture, identity, integrity, and policy. In practice, it governs whether a device can authenticate, connect, or receive sensitive access.
- Configuration Inheritance Risk: Configuration inheritance risk is the chance that a centrally defined policy or template will propagate a mistake across many environments at once. It is the trade-off for standardisation: consistency improves, but so does blast radius if the inherited control is incomplete, overly broad, or incorrectly scoped.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on June 1, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org