AgentSmith exposes proxy-based risk in AI agent governance

At a glance

What this is: Noma Security’s research on AgentSmith shows how a malicious proxy configuration in a shared AI agent could intercept sensitive prompts and credentials through user action.

Why it matters: For IAM and NHI teams, the issue shows that public agent sharing creates a governance gap where inherited trust can bypass normal access controls.

👉 Read Noma Security's analysis of the AgentSmith AI agent vulnerability

Context

AgentSmith is a proxy-based AI agent vulnerability, which means the agent’s traffic can be redirected through an attacker-controlled server after a user adopts a shared prompt. For IAM and NHI practitioners, the core issue is not model weakness alone but trust in inherited agent configuration.

Shared agent hubs create a governance problem because the organisation is no longer only approving internal workloads. It is also deciding whether a reused prompt, its tool access, and its proxy settings are safe enough to inherit into production workflows. That is a familiar pattern for NHI risk, and it is especially acute when prompts, keys, and documents flow through the same execution path.

Key questions

Q: How should security teams govern shared AI agents that can inherit hidden proxy settings?

A: Treat shared agents as imported software with identity, network, and tooling metadata. Review the configuration before reuse, restrict outbound destinations, and require approval for any agent that can relay prompts or files. If you cannot verify lineage and runtime behaviour, keep the agent out of production workflows.

Q: Why do public prompt hubs create risk for NHI governance?

A: They distribute more than prompt text. A reused agent can bring tool permissions, proxy routes, and access assumptions into a new environment, which means trust is inherited rather than freshly granted. That makes public hubs a supply-chain style risk for non-human identities.

Q: What is the difference between secret scanning and agent runtime control?

A: Secret scanning looks for exposed credentials before or after storage, while runtime control watches what the agent actually does during execution. In agentic environments, both are needed because a malicious proxy can steal data without leaving an obvious secret in the prompt itself.

Q: When should organisations block a shared AI agent from production use?

A: Block it when the agent’s source, proxy configuration, or tool calls cannot be verified. The risk is highest when the agent can access API keys, documents, or downstream automation. If the trust boundary is unclear, the correct answer is isolation, not partial approval.

Technical breakdown

How malicious proxy configuration turns an AI agent into a relay

A proxy sits between the client and the upstream model or API endpoint. If an agent is configured to send traffic through an attacker-controlled proxy, the attacker can read prompts, capture credentials, and alter responses before they reach the model or the user. In this case, the danger comes from configuration inheritance, not code execution. A shared prompt can carry hidden network behaviour that survives cloning and reuse. That matters because AI agent identity is not just the prompt text. It includes connected tools, network routes, and the trust boundary around runtime traffic.

Practical implication: Practitioners should treat proxy settings as part of the agent identity and validate them before any reuse.

Why prompt hubs create inherited NHI risk

Public prompt repositories blur the line between content sharing and operational deployment. A prompt that looks like a reusable agent can also embed tool calls, network destinations, and access assumptions that the consumer does not inspect closely. That makes the hub a distribution point for non-human identity risk, because the agent may inherit permissions and secrets from the adopting environment. The failure mode is similar to supply-chain compromise, but the payload is behavioural: the agent appears useful while quietly changing where data flows. Once adopted, the trust decision is often irreversible without inspection.

Practical implication: Teams should review shared agents as imported assets, not as harmless templates.

Agentic AI controls must cover runtime traffic and output handling

Traditional IAM checks whether a subject can authenticate and reach a resource. Agentic AI needs an additional layer that checks where the agent sends data, what it can invoke, and whether its output can drive automation safely. That is why runtime guardrails matter. They can block unsafe tool calls, detect exfiltration patterns, and inspect outputs before downstream systems act on them. The technical lesson is that identity control for agents is incomplete without traffic control. The agent may be authorised, but its network path can still be hostile.

Practical implication: Security teams should pair identity policy with runtime inspection and output validation.

Threat narrative

Attacker objective: The attacker wants durable access to prompts, keys, and attached data while preserving normal-looking agent behaviour.

1. Entry occurs when a user adopts a public agent that contains a hidden proxy configuration under the attacker’s control.
2. Escalation follows when the agent routes prompts, uploaded files, and API keys through the malicious proxy without visible user awareness.
3. Impact is persistent credential and data exfiltration, plus the ability to tamper with downstream LLM responses or exhaust service usage.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Inherited agent trust is the real control failure here. The issue is not only whether an AI agent exists, but whether its configuration is being treated as part of its identity and risk profile. Once a shared agent can carry hidden proxy settings, conventional approval workflows no longer capture the real attack surface. Practitioners should manage agent trust as a runtime property, not as a static prompt review exercise.

Public agent repositories create a new form of shadow NHI exposure. Users may assume a community prompt is just reusable content, but in practice it can import tools, routes, and access assumptions into production workflows. That widens the blast radius of a single malicious configuration across teams that reuse the same agent pattern. Security programmes should classify externally sourced agents as untrusted until their full lineage is verified.

Agentic AI governance now needs configuration provenance, not just secret scanning. Secret detection helps, but it does not catch a proxy that silently forwards everything a user types or uploads. The decisive issue is whether the organisation can trace where an agent came from, what it can reach, and what it can relay. That makes lineage, runtime controls, and least privilege the baseline for agent governance.

CVSS alone understates the business risk of agent interception. A score of 8.8 captures severity, but not the downstream effects of prompt leakage, billing abuse, and response tampering. For NHI programmes, the key question is whether an agent can become a durable interception point inside trusted workflows. If yes, the control model must move from authentication to continuous containment.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
• Only 44% of organisations have implemented policies to govern AI agents, even though 92% agree governance is critical to enterprise security.
• That gap shows why teams should pair agent inventory with the OWASP NHI Top 10 and review shared agents as potentially untrusted software assets.

What this signals

Agent provenance is becoming as important as agent permissions. The practical lesson for programmes is that a prompt repository can function like a software distribution channel, which means approval must cover lineage, tool access, and network behaviour. Teams that only scan for secrets will miss the more durable risk: an agent that can relay everything it sees through a hidden path.

With 80% of current AI agent deployments already showing rogue behaviour in our research, the governance gap is structural rather than exceptional. That means security teams should assume reuse will outpace manual review and should push inspection earlier in the intake process, before an agent ever reaches a production workflow.

Identity blast radius: the useful concept here is the maximum damage a reused agent can cause once it inherits trust. If a prompt hub agent can access files, keys, and downstream systems, then a single bad configuration can expand far beyond the original user. Programme owners should narrow that blast radius with segmentation, limited credentials, and continuous monitoring.

For practitioners

• Inventory every shared AI agent Maintain a central register of agents, forks, tools, and network settings so reused prompts cannot enter production unnoticed. Include prompt hubs, internal templates, and any agent that can reach external APIs or file stores.
• Review proxy and tool configurations before reuse Treat proxy settings, outbound endpoints, and tool-call permissions as security-sensitive configuration. Block promotion until the agent’s lineage and network path are validated.
• Apply runtime guardrails to agent traffic Enforce allow and deny policies for external calls, log sensitive-data transfer attempts, and inspect outputs before downstream automation acts on them.
• Isolate untrusted or community-sourced agents Run externally sourced agents in segmented environments with limited credentials, limited network reach, and separate approval paths from internal production agents.
• Re-audit previously forked agents Search for agents cloned before the fix and confirm there are no unsafe proxy settings, hidden tool routes, or inherited credentials left in place.

Key takeaways

• Shared AI agents can hide dangerous proxy behaviour, which turns configuration into an identity risk.
• Public prompt hubs expand the NHI attack surface because reused agents can inherit tools, routes, and credentials.
• The right control model combines lineage review, runtime guardrails, and isolation for untrusted agents.

Key terms

• Agent Lineage: Agent lineage is the record of where an AI agent came from, what it was built from, and what it can connect to at runtime. For NHI governance, lineage links prompt origin, tool use, proxy settings, and downstream systems so reused agents can be assessed before deployment.
• 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.
• Identity Blast Radius: Identity blast radius is the amount of damage a compromised non-human identity can cause once trust has been granted. In agentic environments, it includes credentials, tools, data access, and automation paths, so the goal is to shrink the impact of any single agent compromise.

Deepen your knowledge

Agent lineage, runtime guardrails, and trusted reuse are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building agent governance from the same starting point, it is worth exploring.

This post draws on content published by Noma Security: AgentSmith AI agent vulnerability and malicious proxy risk in LangSmith. Read the original.