How do security teams detect when an agent is using public infrastructure as a relay?

What a relay looks like in the chain, not just at the destination

Detection starts by treating the relay as a path problem. A normal request path should be narrow and explainable, so security teams look for extra hops, unfamiliar intermediaries, or infrastructure that appears only to forward traffic instead of serving the task directly. In practice, that means tracing how the request moved, not just where it ended up.

Public relays often show up as scanners, page carriers, proxy workers, or browser-based intermediaries that sit between the initiating agent and the final target. Those services may be legitimate in isolation, but they become suspicious when they appear in a workflow that should not need them. The most useful question is whether the chain contains infrastructure that has no normal business reason to exist for that action.

When the relay is hidden inside ordinary web traffic, the same principle still applies: identify the unexpected middle system, then verify whether it was required for routing, rendering, fetching, or reuse of a session. If the answer is no, the relay itself becomes the signal.

Signals that separate a relay from ordinary infrastructure

The best indicators are structural. A relay often creates a mismatch between the task and the path, such as a browser session where no browser should be needed, a proxy worker where direct service access should exist, or a page carrier where the target should have been contacted directly. Those mismatches matter more than a single destination IP or domain.

Security teams should also watch for repeated routing through public cloud or hosted infrastructure that changes quickly, because relay services are often transient by design. That does not make every cloud hop malicious, but it does mean analysts should ask whether the intermediate system belongs in the approved architecture or only in the attacker’s delivery chain.

A useful detection pattern is correlation across layers: request headers, DNS lookups, session reuse, user-agent behavior, and timing. A relay usually leaves inconsistencies between those layers, especially when one component is doing the fetching while another is doing the apparent interaction. AI Agent Observability, Audit and Incident Response Guide is useful here because attribution depends on having enough telemetry to reconstruct the chain end to end.

How to confirm attribution and reduce false positives

Once an intermediate service is suspected, the next step is to validate whether it was acting as an authorized dependency or as an unneeded relay. That usually means comparing the observed path with the expected architecture, checking whether the service has a defined role, and confirming whether the same request can be satisfied without that middle layer.

Teams should be careful not to overread every proxy or automated fetcher as malicious. The differentiator is necessity. If the workflow should complete directly, and an intermediate service appears only when the agent runs, then the relay likely matters. If the service is part of a known control plane, content delivery path, or sanctioned automation layer, it may be normal and should be documented as such.

Attribution improves when you retain the full sequence, including the first observable hop, not just the last public endpoint. That lets analysts distinguish a direct action from an action that was relayed through a third party, which is often the difference between seeing the agent and seeing the infrastructure it borrowed.

Risk and Threat Considerations

Public relays can hide the real source of automation, blur accountability, and let an agent borrow trust from infrastructure that security teams do not fully control. That increases the chance of missed detection, incorrect attribution, and delayed containment when the relay is being used to stage scanning, access, or exfiltration.

Failure mechanism: An attacker or misconfigured agent inserts a public intermediary into the request path, so defenders see only the relay and lose the original actor, session, or tool invocation unless they trace the chain across logs and network telemetry.

Impact: Monitoring may undercount the true source of activity, block the wrong endpoint, or miss follow-on actions that continue through the relay. In a compromise, that can extend dwell time and make remediation slower because the visible traffic is not the same as the controlling entity.

Practitioner Guidance

What to verify: Confirm whether each intermediate service is required by design, recorded in the asset or workflow inventory, and able to be tied to a named business purpose. If the hop cannot be explained, treat it as a lead for investigation, not as background noise.

What to measure: Track the rate of requests that introduce unexpected intermediaries, especially when the same agent or workflow sometimes runs direct and sometimes relays through public infrastructure. A rising pattern usually signals routing drift, evasive behavior, or an emerging dependency that has not been governed.

Practitioner takeaway: The key judgment is whether the middle system is a legitimate dependency or evidence that the agent is borrowing infrastructure to conceal or reshape its path. If you cannot explain the relay, you should assume it matters until the full chain proves otherwise.

Related resources from NHI Mgmt Group

• How do security teams detect ORB-style relay infrastructure in logs?
• Why are NHIs a critical concern for security teams?
• What is the impact of using hard-coded credentials on security?
• What steps should security teams take to prevent Shadow AI risks?