How GreyArm detects agents without reading your data

A tool that watches for AI agents has an obvious problem to solve: it must look closely enough to notice what agents do, without becoming a surveillance tool itself. We designed GreyArm around a simple principle. Observe behaviour, not content. This article explains what that means in practice.

The principle: metadata, not messages

Almost everything that matters about an agent is visible from the outside. Which program is running, what started it, which services it connects to, how much it sends, which ports it listens on. None of that requires opening your files, reading your prompts or decrypting your traffic. GreyArm uses those signals and nothing deeper.

What the sensor collects

The GreyArm sensor is a desktop app that runs on each computer you want to watch. On a regular schedule it takes a snapshot of:

• Processes: name, executable path, command line and parent process, so we can reconstruct which program started which.
• Network connections: which process has a connection to which remote address and port, and roughly how much data has moved.
• Hostname resolution: on Windows, the operating system’s DNS cache tells us which names were recently looked up; elsewhere, addresses are resolved against our catalogue of AI services.
• Listening ports: which processes accept connections, and on which addresses.
• Neighbouring devices: the local ARP or neighbour table, which shows other devices on the same network.

For each detected agent binary, the sensor also records a SHA-256 hash and the code-signing publisher where one exists. That lets you tell a signed release of a known tool from an unsigned copy with the same name.

What it deliberately does not collect

• The contents of your files.
• Your prompts, chats or AI responses.
• The contents of network traffic. GreyArm does not intercept or decrypt TLS.
• Keystrokes, screenshots or browsing history.

When a finding mentions credential material, it is because a process opened a file in a location known to hold credentials, not because GreyArm read the file.

From raw signals to findings

A snapshot of processes and sockets is noisy. Turning it into something useful happens in a few steps, all inside our detection engine.

1. Resolve and match services

Each remote address is mapped to a hostname where possible and matched against a catalogue of AI services: model providers, AI coding services, AI search and browsing services, and others. This tells us which processes are talking to AI.

2. Recognise agents

Processes are compared with agent signatures: known command-line agents, editor extensions, desktop assistants, automation frameworks, local model runtimes and MCP servers. Helper processes that belong to the same tool are collapsed together, so one agent shows up as one entry rather than twelve.

3. Apply rules

A small set of transparent rules looks for behaviour worth your attention. Each has a stable identifier so you can refer to it:

• An agent you blocked is running again.
• An unapproved agent connected to an AI service.
• One process talking to several different AI providers.
• An AI-connected agent spawned a shell, or accessed credential material.
• Large uploads to an AI service, a possible sign of data leaving.
• A browser being driven programmatically.
• An agent seen for the first time on this computer.
• A local model runtime listening on a network-reachable address.
• A device’s AI lookup blocked by the DNS shield.

4. Score the risk

Each agent receives a risk score from 0 to 100, built from what it is and what it did: whether it is approved, whether it touched a shell or credentials, how much it uploaded, how many providers it uses. The score is a way to sort attention, not a verdict.

What you do with a finding

Every agent can be approved, watched or contained. Approving tells GreyArm the agent is expected, so routine activity stops raising alerts. Containment offers a range of responses: ending the process, blocking it at the firewall, preventing it from relaunching or, as a last resort, isolating the computer from the network. Containment actions run with elevated privileges only after an explicit operating-system prompt on the computer itself, so nothing changes silently.

Keeping the noise down

A detection tool that shouts all day gets ignored, so a lot of GreyArm’s design is about staying quiet when things are normal. Approved agents no longer raise "unapproved" findings. Helper processes are folded into the tool they belong to. The first-sighting rule fires once per agent per computer, not every scan. And the risk score lets the console sort the few findings that matter above the many that are routine. The aim is that when GreyArm does raise something, it is worth thirty seconds of your attention.

What leaves your computer

The local console works entirely on your computer. If you choose to link the sensor to a GreyArm account, it sends snapshots of the same metadata described above so you can see several computers in one place, and so actions you take in the web console can be delivered back to the sensor. Content was never collected, so it cannot be uploaded.

Honest limits

Behavioural detection has edges, and it is better to know them:

• A brand-new tool may not match a signature yet. It will still appear if it talks to a known AI service.
• Traffic through a VPN, proxy or encrypted DNS may hide the destination hostname. The process and its connection are still visible.
• Activity that never touches the network and never starts a process, such as a model inside a game engine, is outside what the sensor sees.

We publish rule identifiers and descriptions so that every finding can be explained. If GreyArm flags something, you should always be able to see why.