eBPF Runtime Sensor

The AgentKeeper eBPF Runtime Sensor gives AgentKeeper visibility into AI activity running inside Kubernetes clusters. It is for security and platform teams that need to know which workloads are running AI tools, which workloads are connecting to AI services, and what runtime evidence explains each match.

The sensor is installed in the cluster as a DaemonSet. After it starts sending runtime evidence, AgentKeeper rolls that evidence up into AI Discovery and Inventory so you can review the affected workload, not just a stream of raw events.

Use this connector when Kubernetes workloads may run agents, command-line AI tools, SDK clients, or other software that reaches AI services at runtime.

How It Works

eBPF is a Linux kernel technology that lets approved programs observe runtime activity with low overhead. AgentKeeper uses eBPF to observe process execution and network activity on each Kubernetes Node without changing your application containers.

The sensor looks for runtime signals that match AgentKeeper AI rules. Examples include a process executing a known AI tool or a workload connecting to a known AI service. When a signal matches, the sensor sends AgentKeeper the evidence needed to explain the match.

Evidence can include:

• the matching AgentKeeper rule;
• process name, command, and parent process context;
• Kubernetes namespace, Pod, container, and owner workload when available;
• container runtime identity when Kubernetes metadata is unavailable;
• AI service connection destination and external IP when available.

Each evidence item is enriched with Kubernetes, container, and Node context when that context is available. That context lets AgentKeeper show the affected runtime object instead of only the low-level process or connection event.

AI Discovery

AI Discovery shows discovered runtime workloads. Matching rules are grouped by workload, so a workload that both executes an AI tool and connects to an AI service appears with multiple rule matches.

Use AI Discovery to review the evidence, decide whether the AI usage is expected, and accept the risk for workloads that are approved in your environment.

Review:

• matched AI rules, such as AI program execution or AI API connections;
• the runtime source, shown as OS Runtime;
• the number and type of workloads where the rule was seen;
• evidence details such as process tree, container identity, and connection destination.

Inventory

Inventory -> Workloads shows the full list of AI runtime workloads reported by the sensor. These are infrastructure runtime objects from Kubernetes or container runtime evidence, not workstation devices.

Open a workload detail page to inspect the matching rules, runtime identity, process evidence, and recent observations for that object.

Connector Status

Go to Settings -> Connectors -> eBPF Runtime Sensor to confirm that the connector is enabled and receiving data. The connector page is the quick place to check whether sensor events are arriving before investigating AI Discovery or Inventory.

Installation

The sensor is installed with the AgentKeeper Helm chart published on Artifact Hub.

You need:

• A Kubernetes cluster where you can install DaemonSets, ServiceAccounts, and ClusterRoles.
• Helm 3.
• An AgentKeeper API key.
• The eBPF Runtime Sensor connector enabled in AgentKeeper.

helm repo add agentkeeper https://charts.rad.security/stable/
helm repo update agentkeeper

helm upgrade --install agentkeeper-sensor agentkeeper/agentkeeper-sensor \
  --namespace agentkeeper \
  --create-namespace \
  --set secret.apiKey="<agentkeeper-api-key>"

For available chart options, see the Artifact Hub package or the chart values.yaml.

Existing Secret

If you already manage Kubernetes Secrets outside Helm, create a secret with an api-key key and reference it:

helm upgrade --install agentkeeper-sensor agentkeeper/agentkeeper-sensor \
  --namespace agentkeeper \
  --set secret.create=false \
  --set secret.existingSecretName=my-agentkeeper-secret

Cluster Name

Set a cluster name to make runtime evidence easier to recognize when several clusters report into the same AgentKeeper organization:

helm upgrade --install agentkeeper-sensor agentkeeper/agentkeeper-sensor \
  --namespace agentkeeper \
  --create-namespace \
  --set secret.apiKey="<agentkeeper-api-key>" \
  --set config.clusterName="production-us-west"

Verify

Check that the DaemonSet is running:

kubectl -n agentkeeper get pods -l app.kubernetes.io/name=agentkeeper-sensor

Then confirm the data path in AgentKeeper:

1. Go to Settings -> Connectors -> eBPF Runtime Sensor and confirm recent activity is present.
2. Go to AI Discovery and filter to OS Runtime.
3. Go to Inventory -> Workloads and confirm Nodes, Kubernetes workloads, Pods without owners, or standalone containers appear.

Troubleshooting

Upgrade

helm repo update agentkeeper
helm upgrade agentkeeper-sensor agentkeeper/agentkeeper-sensor \
  --namespace agentkeeper \
  --reuse-values

Uninstall

helm uninstall agentkeeper-sensor --namespace agentkeeper

The uninstall command removes the AgentKeeper Sensor workload. It does not delete the namespace or any secrets you created separately.