PingOne Privilege

Deploying the node sensor

The PingOne Privilege node sensor is an eBPF sensor that observes the AI workloads running in your containers. One sensor runs on each Linux node. A host-based security tool cannot see inside a container because the process namespace is isolated from the host. The sensor observes process execution and network activity at kernel observation points and attributes every finding to the pod or container that produced it.

The sensor discovers the following workloads:

  • AI agents and agent frameworks, recognized from their binaries, runtime catalogues, and startup arguments.

  • Self-hosted model servers listening on conventional inference ports.

  • MCP servers, detected by correlating a process with the port it later listens on.

  • The model endpoints each workload calls, identified from the unencrypted handshake (TLS SNI and JA4, or the HTTP host header). No TLS is terminated and no traffic is decrypted.

  • Workloads with no recognizable name, characterized by the AI SDKs and credential environment variables installed for them.

Deploying the sensor on Kubernetes

On Kubernetes, the sensor runs as a DaemonSet with one pod per node, installed with Helm. The cluster’s OpenID Connect (OIDC) provider issues the sensor’s identity, and PingOne Privilege verifies it.

Before you begin

Ensure you have the following:

  • Helm 3 installed on your workstation.

  • Your cluster’s OIDC issuer URL.

  • A workload identity registered in PingOne Privilege for the sensor. Learn more in Registering non-human identities.

Registering the sensor’s identity

The sensor proves its identity with a short-lived service-account token. You register a workload identity in PingOne Privilege naming the cluster’s issuer and the sensor’s service account. The kubelet mints a token for the registered audience and mounts it in the pod, and the sensor presents it with every report.

To register the identity, follow the Kubernetes option in Registering non-human identities, with the following settings:

  • Token issuer type: Kubernetes - ServiceAccount Token.

  • Issuer (iss): Your cluster’s OIDC issuer URL.

    To get the issuer URL, run the following command:

    $ kubectl get --raw /.well-known/openid-configuration | jq -r .issuer

  • ServiceAccount: Either a new service account, which the sensor installation creates, or an existing one, entering the namespace and serviceaccount exactly as they exist in the cluster.

  • Permissions: A sensor that reports findings only needs the shadowai:write permission.

  • Audience: PingOne Privilege generates the audience at registration. Copy it into the Helm installation’s auth.audience value.

The registered subject must match the deployed namespace and service account exactly. A mismatch is refused rather than mis-attributed.

If your cluster runs SPIFFE with SPIRE, the same chart accepts a SPIFFE identity instead, so the sensor joins the trust domain you already operate. Register the identity with the SPIFFE / SPIRE token source and name it in the Helm installation.

Installing the sensor

To install the PingOne Privilege node sensor, run the following command:

$ helm install procyon-nodesensor \
   oci://public.ecr.aws/v2s2h8i9/procyon-nodesensor-chart --version 0.1.14 \
   --namespace <your-namespace> --set-string clusterID=<your-cluster> \
   --set-string serviceAccount.name=<your-service-account> \
   --set-string auth.audience=<audience-from-console> \
   --set controller.enabled=true \
   --set-string controller.endpoint=<your-privilege-endpoint>:443

The command options are:

  • clusterID=<your-cluster>: A name that identifies your cluster in PingOne Privilege.

  • serviceAccount.name=<your-service-account>: The service account the chart deploys. This must match the registered subject.

  • auth.audience=<audience-from-console>: The audience generated when you registered the identity.

  • controller.endpoint=<your-privilege-endpoint>:443: Your PingOne Privilege controller endpoint.

The chart creates the following:

  • A namespace and service account, or you point the chart at ones you manage.

  • Read-only role-based access control (RBAC): get, list, and watch on pods, services, and endpoint slices.

  • A DaemonSet with one pod per node and the projected service-account token on a memory-backed volume.

  • A security context that is not privileged, with escalation disabled, all capabilities dropped except the two that eBPF needs, and read-only root and /sys filesystems.

The sensor re-reads the projected token file with every report, so token rotation is picked up automatically.

Verifying the deployment

$ kubectl -n <your-namespace> rollout status ds/procyon-nodesensor
$ kubectl -n <your-namespace> logs -l app.kubernetes.io/name=procyon-nodesensor-chart --tail=20

Deploying the sensor on a Docker host

On a Docker host there are no pods, so the sensor attributes each workload to its container. The container name is used wherever a pod’s namespace would go. A rule naming ollama-prod matches the container called ollama-prod; nothing in the policy model changes.

Before you begin

  • A supported Linux Docker host.

  • Your PingOne Privilege controller endpoint.

  • A workload identity registered in PingOne Privilege for the sensor. Learn more in Registering non-human identities.

Registering the host identity

A Docker host has no issuer such as the Kubernetes kubelet, so the host holds a signing key and issues its own tokens. The public half of the key is registered on the identity, which makes the tokens verifiable. Each host receives its own key, created readable only by its owner.

The audience does not exist until you register the identity: create the key first, receive the audience from the console after registration, and then start the sensor with it.

  1. On the Docker host, create the signing key and generate the registration values by running the following command:

    $ docker run --rm -v /etc/procyon:/etc/procyon \
public.ecr.aws/v2s2h8i9/procyon-nodesensor -mint-jwks -cluster <your-cluster>

    Result:

    If a signing key doesn’t exist, the command creates one and returns the Issuer, Subject, and JWKS information to use for NHI configuration.

  2. To register the identity, follow Registering non-human identities, with the following settings:

    • Token issuer type: Docker Host - Self-Signed Token.

    • Paste the Issuer (iss), Subject (sub), and JWKS URL generated from the Docker command.

    • Permissions: A sensor that reports findings only needs the shadowai:write permission.

    • Audience: PingOne Privilege generates the audience at registration. Copy it into the sensor container’s -mint-audience flag.

Running the sensor container

$ docker run -d --name procyon-nodesensor --restart=always \
   --pid=host --cgroupns=host \
   --cap-drop=ALL --cap-add=BPF --cap-add=PERFMON --cap-add=KILL \
   --cap-add=NET_ADMIN --cap-add=SYS_PTRACE --cap-add=SYS_ADMIN \
   --security-opt apparmor=unconfined \
   -v /sys:/sys:ro \
   -v /var/lib/docker/containers:/var/lib/docker/containers:ro \
   -v /etc/procyon:/etc/procyon:ro \
   <registry>/procyon-nodesensor:latest \
     -docker -node "$(hostname)" -cluster <host-label> \
     -controller <your-privilege-endpoint>:8610 \
     -mint-audience <audience-from-console>

The command flags are:

  • -docker: Runs the sensor on a Docker host rather than in a cluster.

  • -node <hostname>: The host name of the node running the sensor.

  • -cluster <host-label>: A label that identifies this host in PingOne Privilege.

  • -controller <your-privilege-endpoint>:8610: Your PingOne Privilege controller endpoint.

  • -mint-audience <audience-from-console>: The audience returned when you registered the identity.

The container mounts give the sensor a read-only view of the host’s system state, container metadata, and its own configuration directory.

Hosts with a stricter policy can run the sensor without the following capabilities. The sensor still discovers and reports, and it reports what it has given up.

Capability Needed for Cost of dropping it

NET_ADMIN

The outbound connection filter.

A rule that denies a connection terminates the workload instead.

SYS_PTRACE

Reading another process’s details.

You lose idle-workload detection and binary-path classification.

SYS_ADMIN

Entering a workload’s network namespace.

The sensor cannot probe servers on networks it cannot otherwise route to.

AppArmor unconfined

Making the two preceding capabilities effective.

On AppArmor hosts the capabilities are held, but the reads are still refused.
The sensor identifies listening servers by connecting to them. If the sensor does not share a network with the workloads it monitors, those servers cannot be identified by name. Execution and destinations are still detected, but name-based identification is weaker. Connect the sensor to the workload network or run it on the host network, and the sensor logs the condition explicitly.

Next steps

After the sensor reports, review the workloads it discovers on the AI Security > NHI Agents dashboard. Learn more in Discover and manage NHI agents.