Harmonic Security

PLT-005 · formerly ARC-001

Support network-based AI traffic detection where the architecture requires it

.md .json

Acceptance criteria

Integrate with SASE or network controls, identify AI hosts and protocols, and state whether the implementation is passive or inline.

Why it matters

Some architectures need network-level coverage, and the difference between passive and inline matters.

How to verify

The vendor shows the network integration and states whether it is passive or inline.

OWASP adoption context

Shadow, vendor-embedded and platform-integrated AI can create network-visible traffic; whether network inspection is appropriate depends on the architecture.

Framework mappings

  • AI host and protocol identification adds network and external-service monitoring evidence and informs network-protection design. Passive versus inline coverage identifies the architecture; it does not prove enforced access restrictions, segmentation or secure network configuration.

  • Supported protocols, integration points and passive/inline boundaries help document controls for AI components and associated dependencies. The architecture description must be tied to actual deployed coverage.

  • Network coverage and deployment dependencies inform the computing-resource record for the AI system. An integration claim is not evidence that those resources are adequate or securely operated.

  • Observed AI hosts and protocols supply network-activity signals for security monitoring. Demonstrate traffic results and missed paths; passive visibility does not establish network enforcement, segmentation or secure configuration.

  • Observed AI hosts and protocols support network monitoring; observable external AI service traffic can also inform service-provider monitoring. Passive detection does not protect a network from unauthorized access, so show the traffic actually observed and the remaining gaps.