AI infrastructure is now a target, and AI security must adapt

At a glance

What this is: This is Zenity’s analysis of GreyNoise findings showing that exposed AI infrastructure is being actively mapped and probed at scale.

Why it matters: It matters because AI endpoints, proxies, and agent workflows now need the same identity, exposure, and runtime controls that IAM teams already expect for production systems.

👉 Read Zenity's analysis of GreyNoise findings on AI security targeting

Context

AI security is no longer only about model quality or prompt safety. The immediate governance problem is exposure: internet-facing AI endpoints, proxies, and agent workflows are being inventoried by attackers in the same way exposed VPNs and other high-value services were previously mapped.

For IAM and security teams, the question is not whether AI systems will be probed. It is whether those systems have been treated as production identity surfaces with authentication, egress control, logging, and behavioral monitoring before attackers turn reconnaissance into exploitation.

Key questions

Q: How should security teams govern exposed AI endpoints and proxies?

A: Security teams should govern exposed AI endpoints and proxies as production identity surfaces. That means inventorying every route, enforcing authentication, restricting outbound destinations, and logging who can reach the model path. If the proxy can talk to the model, tools, or callback infrastructure, it needs ownership and policy like any other privileged access point.

Q: Why do AI proxies create a governance gap for IAM teams?

A: AI proxies create a governance gap because they can separate the authenticated user from the system that actually reaches the model provider or external services. Once that happens, access decisions, logging, and accountability can drift away from the real control point. IAM teams need to treat the proxy as part of the identity chain, not a neutral transport layer.

Q: How can organisations detect AI reconnaissance before exploitation?

A: Organisations can detect AI reconnaissance by correlating repeated low-noise requests, unusual callback domains, destination resolution, and identity context across telemetry. A single prompt may look harmless, but a pattern of probing across endpoints is a stronger signal. Detection should focus on behavior across layers, not only on obvious exploit strings.

Q: Who should own security decisions for AI infrastructure exposure?

A: Ownership should sit with the teams responsible for identity, platform, and security policy together, because exposed AI infrastructure affects authentication, routing, and runtime behavior at the same time. If no team owns the proxy, egress, and model access path as one control plane, exposure will remain invisible until an attacker maps it first.

Technical breakdown

How server-side request forgery turns AI infrastructure into a beacon

The first campaign used server-side request forgery, or SSRF, to force target systems to make outbound requests to attacker-controlled infrastructure. In AI environments, that can happen through model pull mechanisms or webhook parameters that accept untrusted input and then call external URLs. The risk is not only data leakage. The request path itself becomes an oracle that confirms reachability, trust boundaries, and what outbound destinations a service is willing to touch. Once that behavior is observable, it can be chained into broader probing or staging.

Practical implication: restrict outbound destinations and validate every parameter that can influence model pulls or external callbacks.

Misconfigured AI proxies create an identity gap between users and model access

AI proxies and wrappers often sit between applications and commercial model providers. If they are exposed without strong authentication, they become a hidden identity layer that attackers can enumerate for access paths, alternate routing, or weakly protected APIs. The technical issue is not just exposure. It is that the proxy may inherit trust from the application while bypassing the controls normally applied to user or workload identity. That creates a blind spot where access, usage, and business action are no longer tied to a trustworthy identity signal.

Practical implication: inventory every AI proxy and treat it as a governed identity control point, not a convenience layer.

Behavioral reconnaissance bypasses string-based detections

GreyNoise described low-noise prompts and innocuous queries used to fingerprint endpoints without raising obvious alarms. That matters because AI reconnaissance often looks like normal interaction until you correlate repetition, destination, timing, and callback behavior. Traditional exploit-string detection misses this pattern. What defenders need is context around the request path, the source identity, and the downstream effect of the interaction. In practice, that means telemetry from transcript, tool call, egress, and authentication layers has to be joined before a probe becomes visible as a campaign.

Practical implication: build detections around behavior and correlation, not only known payload signatures.

Threat narrative

Attacker objective: The objective is to build a target list of exploitable AI infrastructure and identify which exposed systems can be leveraged for later access, abuse, or exfiltration.

1. Entry began with internet-wide probing of exposed AI endpoints, proxies, and model access paths to find services that would respond to low-noise requests.
2. Escalation came from abusing SSRF and misconfigured routing so target systems phoned home to attacker-controlled infrastructure and revealed trust boundaries.
3. Impact would be access to exposed AI workflows, downstream credentials, and the ability to stage later exploitation against production AI infrastructure.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

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

NHI Mgmt Group analysis

AI infrastructure is now a governed identity surface, not just an application layer. Exposed AI endpoints, proxies, and agent workflows can be enumerated the same way attackers once mapped other internet-facing services, but the business impact is deeper because those systems can mediate access to tools, data, and actions. The governance model has to treat the AI path as part of identity control, not as an adjacent technical detail. Practitioners should assume AI exposure is a standing inventory problem, not a one-time hardening task.

Identity does not stay trustworthy once it is separated from the downstream model path. When requests are routed through proxies and wrappers, the original user or workload context can be weakened, obscured, or replaced by whatever the intermediary chooses to expose. That breaks the assumption that the identity seen at the edge is the same identity that governs model access and business action. The implication is that control ownership must move closer to the proxy, routing, and callback layers that actually make access possible.

Behavioral reconnaissance is now part of the attack surface for AI security. Low-noise prompts, callback validation, and SSRF-style requests can look benign unless teams correlate identity, egress, and transcript data. That means AI security programs need a concept akin to identity blast radius for model infrastructure, where the concern is not only who is authenticated but what the authenticated system can be induced to contact or reveal. Practitioners should measure exposure by reachable paths, not only by successful logins.

AI adoption is outpacing manual governance, and that timing gap is itself the failure mode. If teams cannot inventory exposed AI systems fast enough, attackers will complete the map first. The article points to a familiar enterprise pattern: new technology is adopted through proxies and wrappers faster than security policy, monitoring, and ownership can catch up. Practitioners should treat this as a governance lag problem, not a narrow detection problem.

From our research:

• Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption, according to The 2026 Infrastructure Identity Survey.
• The same survey found that 67% of security leaders still rely heavily on static credentials despite the risks they pose to agentic AI deployments.
• For broader identity context, read OWASP NHI Top 10 for the control patterns most likely to fail when AI-driven workflows expand.

What this signals

The operational signal here is not just that attackers can find AI systems. It is that exposed model infrastructure now behaves like any other high-value internet service, which means identity teams need to track it with the same discipline they apply to privileged access and workload exposure.

Identity blast radius: the real risk is no longer only who authenticates, but what an authenticated AI path can be induced to reach, reveal, or trigger. Once that scope is visible, teams can prioritize proxy governance, egress restriction, and behavioral detection instead of treating AI security as a model-only problem.

With 70% of organisations granting AI systems more access than they would give a human employee performing the exact same job, per the 2026 Infrastructure Identity Survey, exposure management has to include privilege design, not just perimeter filtering.

For practitioners

• Inventory every exposed AI endpoint and proxy Map all internet-accessible model routes, wrappers, and API layers, then record who owns them, what they reach, and whether they are authenticated.
• Constrain outbound model pulls and callback destinations Allow only trusted registries and known callback domains, and block systems that can be induced to reach arbitrary external URLs.
• Correlate transcript, identity, and egress telemetry Join request content, source identity, destination resolution, and tool use so low-signal probing can be detected before it becomes exploitation.
• Treat AI proxies as policy enforcement points Apply authentication, rate limits, logging, and ownership requirements at the proxy layer, because that is where hidden access paths are often introduced.

Key takeaways

• AI endpoint reconnaissance is already an operational threat, and exposed proxies are part of the identity problem.
• GreyNoise’s findings show that attackers are using low-noise probing and SSRF-style techniques to map AI infrastructure before exploitation.
• Teams should inventory AI access paths, lock down outbound behavior, and correlate identity with runtime telemetry before attackers do it for them.

Key terms

• AI proxy: An AI proxy is an intermediary service that routes application requests to a model provider or local model endpoint. In practice, it often becomes a hidden control point for authentication, logging, egress, and policy enforcement, which means it must be governed like privileged infrastructure.
• Server-side request forgery: Server-side request forgery is a flaw that lets an attacker cause a server to make outbound requests to destinations they choose. In AI systems, SSRF can expose trust boundaries, confirm reachable services, and create a path from ordinary input handling to external callback abuse.
• Behavioral reconnaissance: Behavioral reconnaissance is the practice of mapping targets through patterns of interaction rather than obvious exploit payloads. For AI systems, it may look like low-noise prompts, repeated endpoint testing, or callback validation, which makes correlation across identity and telemetry essential.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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.

This post draws on content published by Zenity: GreyNoise findings and what they mean for AI security. Read the original.