Privileged access management tools answer one question: who gets the keys. They handle credential rotation, session recording, and approval workflows. A developer requests production database access. An approver clicks yes. The PAM tool rotates the credential, opens a session, and logs the access grant.
What happens next is invisible to most PAM implementations.
The developer opens a shell. They run psql to connect to the database. Standard activity. Then they execute /tmp/exfil.sh, a script that dumps customer records to an external S3 bucket. The PAM tool logged the session start time and the credential used. It has no visibility into the process execution, file access, or network connection that followed.
This is the gap between access control and privileged access monitoring. PAM tools excel at the former. They fail at the latter.
What PAM Tools Actually Monitor
PAM platforms track authentication events and session metadata. When a privileged user requests access, the system logs who requested it, who approved it, what credential was issued, and when the session started. Some solutions include session recording, capturing keystrokes or screen output.
Session recording creates forensic evidence. After an incident, you can replay the session and see what commands were typed. This works for post-incident analysis. It does not work for real-time threat detection.
The recording shows text in a terminal. It does not show the syscalls executed by that text. When an operator runs kubectl exec -it pod-name -- /bin/bash, the PAM tool sees the kubectl command. It does not see the processes spawned inside the container, the files accessed within the pod's filesystem, or the network connections opened from that shell.
PAM operates at the application layer. It sees what the user types into approved tools. It does not see what the kernel executes on behalf of those tools.
The Kernel Layer: Where Privileged Activity Actually Happens
Every action a privileged user takes translates into kernel syscalls. Opening a file becomes openat(). Spawning a process becomes execve(). Establishing a network connection becomes connect(). These syscalls execute regardless of whether the user is running an approved PAM session or a rogue script.
Traditional monitoring tools operate above this layer. EDR agents hook into user-space libraries. SIEM systems ingest logs from applications. Neither captures the full syscall stream that constitutes actual privileged behavior.
A sysadmin with legitimate sudo access runs a Python script at 2 AM. The script uses requests.get() to download a binary from a personal GitHub repository, writes it to /usr/local/bin/, sets execute permissions, and runs it. Application-layer logs show a Python process. They do not show the HTTP connection to github.com, the file write to a system directory, the chmod operation, or the subsequent process execution.
The kernel sees all of this. Every file operation, every network socket, every process spawn passes through the kernel's syscall interface. Monitoring at this layer captures privileged activity as it actually occurs, not as it appears in application logs.
Behavioral Baselines for Privileged Access Monitoring
Logging syscalls produces data. Converting that data into detection requires baselines.
Effective privileged access monitoring builds behavioral profiles across three dimensions: individual users, organizational roles, and infrastructure clusters. A single anomaly in one dimension may be noise. An anomaly that appears simultaneously across all three is a signal.
A database administrator typically runs queries during business hours. The user profile expects psql execution between 9 AM and 6 PM. The DBA role profile expects file reads from /var/lib/postgresql/ and network connections to internal database ports. The infrastructure cluster profile expects these patterns on database servers, not application nodes.
At 11 PM, this DBA account runs nc (netcat) from an application server, establishing an outbound connection to an IP in a foreign country. This violates the user baseline (wrong time), the role baseline (wrong tool), and the infrastructure baseline (wrong server type). All three dimensions show anomalies simultaneously.
Traditional PAM tools see a valid session from a credentialed user. Kernel-level monitoring sees a confluence of behavioral deviations that indicates compromised credentials or insider threat activity.
Detection Latency and False Positive Rates
Behavioral monitoring creates two operational challenges: how fast it detects real threats and how many false alarms it generates.
Detection latency measures the time between an anomalous syscall and an alert. In production environments running 1 million queries per second, kernel-level monitoring achieves average detection latency of 0.098 seconds, with worst-case latency of 2.48 seconds. This is fast enough to catch an attacker before significant data leaves the network.
False positive rates drop as baselines mature. In the first seven days of monitoring, expect a false positive rate around 0.69% as the system learns normal behavior. At 30 days, this falls to 0.42%. At 180 days, it reaches 0.18%. Organizations deploying privileged access monitoring should plan for a learning period where security teams validate alerts and tune baselines.
The performance cost of kernel-level monitoring is minimal. CPU overhead averages 0.1% at high query volumes. Latency impact is negative, around -5.26% on average, meaning requests actually complete slightly faster due to kernel optimizations. Memory footprint averages 30.9MB per agent.
eBPF as the Monitoring Mechanism
Extended Berkeley Packet Filter (eBPF) provides the technical foundation for kernel-level privileged access monitoring. eBPF programs attach to kernel tracepoints and syscall boundaries, capturing execution events without requiring kernel modules or system reboots.
Unlike loadable kernel modules, eBPF programs pass through a verifier that guarantees they cannot crash the kernel. They run in a sandboxed environment with bounded execution time and memory access. This makes them safe to deploy in production without extensive testing cycles.
CO-RE (Compile Once, Run Everywhere) and BTF (BPF Type Format) capabilities allow a single eBPF program to run across different kernel versions without recompilation. An agent deployed on a fleet running kernels from 4.14 to 6.2 uses the same bytecode, adapting to kernel structure differences at runtime.
For Kubernetes environments, agents deploy as DaemonSets, running one pod per node to capture all container activity. For VM-based infrastructure, they deploy as systemd services. Both approaches capture syscalls before any application-layer encryption, seeing network activity in plaintext at the socket level.
This is not hypothetical. Organizations running these agents in production maintain the performance and false positive metrics cited above while achieving visibility that PAM tools cannot provide.
Complementing Existing Security Controls
Kernel-level monitoring does not replace PAM. It fills a specific gap in the privileged access monitoring stack.
PAM tools control access. They enforce approval workflows, rotate credentials, and ensure that privileged sessions use designated tools. These functions remain essential. An organization should not abandon PAM in favor of behavioral monitoring.
But PAM tools assume that authorized users will only take authorized actions. This assumption breaks down under two conditions: credential compromise and insider threats. When an attacker uses stolen credentials or a legitimate user goes rogue, PAM tools provide no defense.
Kernel-level monitoring detects the behavioral deviation that occurs when authorization is misused. It sees the unusual process execution, the unexpected file access, the anomalous network connection. It correlates these deviations across user, role, and infrastructure dimensions to distinguish between legitimate edge cases and actual threats.
The two systems work in tandem. PAM controls who gets privileged access. Kernel monitoring validates that privileged access is used appropriately. Together, they close the loop on privileged access monitoring, from authentication through actual behavior.
Most security organizations have coverage across cloud, endpoint, email, and network layers. The kernel layer represents the 5% they do not have. For privileged users operating at the syscall boundary, that 5% is where threats become breaches.