Explore Harness' ARTEX API traffic hunt across seven customer environments and learn how endpoint, identity, and response correlation reveals potential threats.
ARTEX is an AI-powered penetration testing framework that uses agents to investigate targets, select security tools, and carry out testing tasks. It can connect reconnaissance, vulnerability discovery, and exploitation into a workflow with less manual intervention. These capabilities support authorized security assessments and can also be abused by attackers to automate parts of an intrusion.
Harness hunted for ARTEX across customer API traffic and found three very different patterns: a recurring crawl of public pages, a brief burst across API routes from multiple observed addresses, and a handful of requests to an endpoint that lists users.
In a 30 day review ending November 10, 2026, we found more than 1,300 matching API spans across seven customer environments.
A tool name helps you find traffic, but judging the risk means seeing into the application itself. Which endpoints did the client reach? Did it authenticate? What did the application allow?
One caveat before the details. These clients named themselves ARTEX in their User Agent, and anyone can put anything in a User Agent. What we can say is that the traffic carried the name. Tying it to the framework would take more than that.
What we searched for
We looked for variants of "artex" in the User Agent, such as artex-probe and artexbot/1.0, and for norma/0.4 on the web-fetch client. The same "artex" check covers the other client names tied to the framework, including enrichment, audit, read-only, and verify clients.
We counted a request when "artex" started a word, and when "norma" started a word. A search for those letters anywhere in the string brings back shop names, device ids, and ordinary words such as "klartext", so those were set aside. We also looked for disguised spellings, such as art3x, a4tex, and the URL encoded form.
The infrastructure check covered nine source addresses, with both 178.16.54.129 and 178.15.54.129 included. We also checked 17 further source addresses, including 134.122.137.132 and 204.194.51.54.
The framework also drives ordinary clients, including Nmap, Playwright, and headless Chromium. Those are some of the most common automation on the internet, so we only kept them when a single client sent at least 200 requests across at least 20 routes within six hours. Ordinary curl, wget, and Python HTTP clients were left out. There is far too much of that traffic for the name alone to mean anything.
A few exact versions have shown up with the framework, so we checked them: curl/7.88.1, python-requests/2.34.2, Python-urllib/3.12, Boto3/1.43.112, Boto3/1.43.113, and aws-cli/1.46.1. Mozilla/5.0 (Spa-api-recon) is the client on one of its reconnaissance scripts, so that was included too. On the request path, we looked for /opt/artex, a task folder the agents create, and for "artex" next to union, a SQL fragment that carries the name.
What we observed
We searched stored API spans across 12 production deployments. Incidental matches in unrelated hostnames, device identifiers, and embedded strings were excluded from the count above. The examples below leave out customer identities, exact routes, and source addresses.
Recurring public page visits alongside a separate API burst
In one customer environment, a client repeatedly visited largely the same set of public pages. Several visits followed a similar daily cadence even as the observed source addresses changed. Responses included successful page loads and redirects, which fits scheduled crawling.
The same environment also saw a separate burst across three public API routes over approximately 40 minutes. Requests came from multiple observed addresses and got a mix of 200 and 400 responses.
The timing and route selection overlapped, so we reviewed those requests together. Establishing common ownership would take further correlation. A successful response on a public API also has to be read against what that endpoint is meant to expose.
Denied requests to a user listing endpoint
In another customer environment, three requests reached an API endpoint that lists users. All three returned 401 responses.
With only three requests, this example is easy to miss if you investigate by request counts. The endpoint is what makes it worth a look. The next step is to check the surrounding activity for successful authentication, related identities, or access to other sensitive routes.
Those responses tell us how the three requests ended. They don't tell us about the broader session, which needs more context.
A concentrated burst worth a closer look
The largest matching client produced 630 spans in roughly 70 minutes, nearly half the matching volume in the dataset.
That makes it a good lead. In the initial pass we had no endpoint or response details for this burst, so we don't know what it attempted or what happened. Volume and duration alone aren't enough to call it exploitation.
Why correlation matters
We also checked whether addresses in the examples above sent HeadlessChrome or Playwright User Agents.
Some did, across the month. Shared hosting and proxy infrastructure can carry unrelated clients, so an address overlap needs careful reading. Stronger evidence would be a common authenticated identity, session, or related request sequence within a narrow window.
Several clients also labeled their activity as testing, auditing, or read only access. Those labels are claims made by the sender, and confirming authorized testing means checking them against the customer's own records.
Recommended actions for API defenders
- Expand hunts beyond tool names. Look for unusual endpoint traversal, repeated access attempts, and unexpected authenticated actions across all User Agents, and compare them with normal behavior for the affected APIs.
- Prioritize sensitive endpoints and verified outcomes. Examine routes involving users, credentials, permissions, or sensitive data. Correlate responses with identity and application audit records to see what access occurred and whether anything changed.
- Reconstruct sessions before attributing activity. Connect requests using timing, identity, session context, and request structure. Validate known security testing, and account for shared infrastructure when assessing source addresses.
- Apply controls to the behavior you can establish. Review authentication and authorization enforcement on sensitive routes. Where abuse is confirmed, scope blocking or rate controls to the observed activity and monitor the application outcome.
From a traffic label to an investigation
The main lesson from this hunt is how little the name told us. A daily crawl, a short burst, three denied requests to a user listing, and a larger burst we could not yet explain all carried it, and each needed a different follow-up.
API telemetry is what makes that sorting possible. Once a request is tied to its endpoint, its identity, and what the application did with it, a team can decide what to chase, even without knowing for certain which tool sent it.
