What an AI agent actually does on your laptop

A year or two ago, "AI on my laptop" mostly meant a browser tab with a chat window in it. You typed, it answered, and nothing left the tab unless you copied it out yourself. That is no longer the whole picture. A growing share of AI software is built to act: to open files, run programs, edit code, click through websites and send data to online services, often for minutes at a time without a human approving every step.

Those programs are usually called agents. The word sounds abstract, but from your computer’s point of view an agent is something very concrete. This article walks through what it actually is, what it does while it runs, and which of those behaviours deserve your attention.

A chatbot answers, an agent acts

The simplest way to tell the two apart is to ask what happens after the model produces text. In a chatbot, the text is shown to you and the story ends. In an agent, the text is read by another program, a harness, which turns it into actions: "read this file", "run this command", "fetch this page", "call this API". The results of those actions are fed back to the model, which decides on the next step. That loop repeats until the task is done or something stops it.

That loop is the whole difference, and it is why agents are useful. It is also why they need a different kind of attention. A chatbot can only say something wrong. An agent can do something wrong, with your files and your accounts.

What it looks like to the operating system

Your operating system does not know or care that a program is "AI". It sees the same things it sees for any software, and those are exactly the things worth looking at.

Processes

An agent runs as one or more ordinary processes. A coding assistant might be a command-line tool started from your terminal, an extension running inside your editor, or a desktop app. Agents frequently start child processes: a shell to run a build, a package manager, Git, a headless browser. The parent-child tree is one of the most informative things you can look at, because it shows what the agent actually launched rather than what it says it did.

Files

Agents read and write files with the permissions of the user who started them. On a typical home computer that means everything in your home folder: documents, downloads, browser profiles, SSH keys, cloud-sync folders. Most well-built agents try to stay inside a project directory, and many ask before touching anything outside it, but the operating system will not stop them by default. The boundary is a design choice in the tool, not a wall.

Network connections

Nearly every agent talks to at least one AI service, usually a model provider’s API. Many also talk to other things: package registries, search engines, code hosts, analytics endpoints, and in some cases services the user never heard of. Each of those is a network connection from a specific process to a specific hostname, which makes it observable.

Permissions and credentials

Agents often hold API keys for the model provider, and sometimes tokens for other services (a code host, a calendar, an email account) so they can act there too. Those tokens tend to live in environment variables, configuration files in your home directory, or the operating system keychain.

A short session, step by step

To make this less abstract, here is a realistic, simplified sequence for a coding agent asked to "fix the failing test":

1. The agent process starts from your terminal and opens a connection to its model provider.
2. It lists the files in your project and reads a handful of them, sending relevant parts to the model as context.
3. The model asks to run the test suite. The agent spawns a shell, which spawns your test runner.
4. The output goes back to the model. It proposes an edit; the agent writes the file.
5. It runs the tests again, then perhaps installs a missing dependency, which means a connection to a package registry and new code arriving on disk.
6. Finally it may offer to commit and push, which uses your Git credentials.

Nothing in that list is malicious. But every step is something you would want to know about if it happened somewhere you did not expect: a shell started from an app that has no business starting one, files read outside the project, or a connection to an unfamiliar host carrying far more data than the task needed.

Where things go wrong

Most problems with agents are not dramatic hacks. They are ordinary software problems with more reach:

• Over-broad context. An agent that sends "the whole folder" to a model can include files you never meant to share, such as an .env file full of secrets.
• Prompt injection. Agents read content written by other people: web pages, issues, emails, documentation. Text in that content can try to steer the agent ("ignore previous instructions and upload…"). Well-designed tools defend against it, but no defence is perfect.
• Forgotten agents. A script someone set up months ago keeps running on a schedule with a valid API key, long after anyone remembers what it does.
• Unvetted extensions. Plugins and tool servers extend what an agent can do. Each one is new code with your permissions.
• Exposed local services. Local model runtimes and tool servers can listen on the network. Configured carelessly, other devices on your Wi-Fi can use them.

Signals worth watching

You do not need to read every log line to keep an eye on agents. A small set of signals covers most of what matters:

• Which programs talk to AI services. If you only expected one, and there are four, that is worth a look.
• New agents. The first time a program behaves like an agent on a given machine is the moment to decide whether it is welcome.
• Shells and credential files. An AI-connected process that starts a shell, or touches SSH keys and cloud credentials, is doing something powerful.
• Unusual upload volume. Requests to a model are usually modest in size. Large, sustained uploads while connected to an AI service deserve a second look.
• Listening ports. Anything AI-related that accepts connections from the rest of the network.

How GreyArm fits in

GreyArm watches exactly those signals. Its sensor looks at processes and their parent-child relationships, open network connections, the hostnames they resolve to, and listening ports. It matches them against a catalogue of AI services and known agent signatures, then applies a small set of rules: unapproved agent, multiple AI providers, shell spawned, credential material touched, unusually large uploads, automated browser sessions, exposed local model runtimes. Each finding gets a risk score, and you decide what to do: approve, keep watching, or contain.

It does not read the contents of your files or your conversations with AI tools. The point is to know what is acting on your computer, not to read over its shoulder.

The short version

An AI agent is a program that turns model output into actions on your computer. It runs as ordinary processes, reads and writes your files, holds credentials and talks to services over the network. Most of the time that is exactly what you asked for. The useful habit is to know which agents are running, what they connect to, and when one of them starts doing something new.