I've been conducting a deeper security audit of our Absolute Secure Access deployment, and a pattern has emerged that makes the marketing claims of "absolute" control ring increasingly hollow. The core issue is agent behavior on our endpoints, specifically the tendency for authorized processes to spawn child or sub-processes that operate outside the defined policy and network routing rules. We've seen scenarios where a permitted update utility spawns a background downloader that then attempts to exfiltrate data over a direct internet connection, bypassing the secure tunnel entirely, because the child process wasn't inheriting the correct network namespace or security context.
The vendor documentation is predictably silent on this, focusing instead on the simple allow/deny lists for initial parent processes. My concern is that this creates a massive, often invisible, attack surface. If a legitimate agent process can be exploited, or simply designed poorly, its spawned children become a beachhead inside the perimeter. The implicit trust model seems to be that if the parent is good, everything it creates is also good, which is a security principle we abandoned in operating system design decades ago.
I want to understand if there is a practical method, within the Absolute Secure Access framework, to enforce strict control over process lineage. Specifically:
* Can agent policies be configured to enforce something akin to a mandatory sandbox or job object that prevents any spawned process from accessing network resources outside the defined secure tunnel?
* Is there any form of inheritance rule for network routing, or is it a simple binary state attached only to the explicitly listed parent process executable?
* Has anyone successfully used the agent's own configuration or integrated with the host OS's native controls (e.g., Windows Defender Application Control, AppLocker, or Linux seccomp/bpf) to create a chain of trust that the Absolute agent itself will respect and enforce?
The alternative, which I'm already exploring, is to bypass the agent's limited functionality and implement system-level controls that cage every process associated with the agent, but that defeats the purpose of paying for a unified solution. It seems we're buying a policy engine that lacks the fundamental understanding of process isolation required for actual zero-trust networking.
Just my two cents
Skeptic by default
Ah, the classic "implicit trust" model. It's less a security principle and more a persistent vendor hope that nobody looks under the hood.
You've hit on the core failure of most agent-based perimeter tech. They treat the endpoint like a flat network where process lineage equals trust. In the real world, a permitted parent can be coerced, hijacked, or just poorly coded. The child process inherits none of the enforcement context because the agent never hooks deep enough into the kernel to enforce inheritance or impose network namespace isolation.
Have you checked if the agent is even attempting to set something like Linux `prctl(PR_SET_SECCOMP)` or Windows job objects to restrict child process creation? I'd bet the postmortem on that exfiltration attempt would show the agent's filters only applied to the initial PID, and everything after was invisible.
- Nina
Exactly. That kernel-level hook is the linchpin they're missing. Even if they attempted a `prctl` call, it's often a superficial flag set early in the process lifecycle that's easily stripped by the child. The real mechanism needed is a seccomp-BPF filter or a Linux Security Module (like AppArmor) policy that the agent installs and maintains, which can enforce rules across `fork` and `execve`. Without that, you're right - the enforcement evaporates.
I've seen this fail in container runtimes, too, where a privileged parent inside the container can escape network and seccomp profiles by forking. The solution there was user namespaces plus deep process tracking. These agents are essentially trying to be poor-man's containers without committing to the full kernel abstraction.
You're spot on with the poor-man's container analogy. That exact architectural compromise is what makes these endpoint agents so brittle in practice. They're trying to enforce a security boundary without owning the full isolation stack, so any process that knows how to manipulate its own runtime environment can slip through.
This is why I've always been skeptical of agents that don't integrate with or defer to the existing platform security modules. Forcing an AppArmor or SELinux policy from a user-space agent, as you suggest, is the only way to get consistent inheritance. Even then, I've seen legacy applications throw errors or behave unpredictably when a spawned child suddenly finds itself in a restricted context it wasn't coded for, which leads to support tickets blaming the agent instead of the app.
It seems like vendors are caught between a rock and a hard place: deep integration is complex and platform-specific, but shallow hooks are fundamentally insecure. Your container runtime example proves the solution exists, but they're unwilling to go that far on a general endpoint.
Support is a product, not a department.
SELinux integration is a nightmare to maintain at scale with user-space agents. You mention platform-specific complexity, but the real issue is policy drift. The agent writes a policy, then something else - a package update, an admin - tweaks the system policy. Now you have conflicts and broken states the agent can't even detect.
Containers work because they own the entire isolation stack. An agent trying to backseat-drive LSMs doesn't. It's just another fragile configuration management layer, and a privileged one at that.
Legacy apps breaking is the only correct outcome. It tells you the app was doing something it shouldn't. Blaming the agent for that is missing the point entirely.
Don't panic, have a rollback plan.