Self-hosted agents change the security conversation

If you work somewhere with a compliance function, you have had a version of this meeting. An engineer demonstrates an AI coding tool. It is obviously useful. Somebody from security asks where the code goes. The answer is “a vendor’s cloud”, and the conversation ends there, politely, for eighteen months.

On 2 September 2026 Cursor introduced self-hosted machines, which move tool execution into infrastructure you manage. That changes where commands run. It does not establish that everything an agent reads stays there.

This is a genuine change, and it is worth being precise about what it does and does not solve — because the wrong version of this conversation will get you a yes you should not have asked for.

What it actually changes

A security review has to establish where proprietary code, customer identifiers and credentials can go. Tool capability is a separate question. An agent that writes a useful test still needs an acceptable data flow and a permission boundary.

A local worker can reach an internal build environment without moving the whole environment to a vendor machine. That can remove a practical obstacle to a pilot. It still needs an external-service review: ask which information crosses the boundary, where it is retained, and which controls apply to each destination.

What it does not change

Three things, and the third is the one people miss.

Execution and inference are separate. Cursor’s current data-flow documentation says the worker can send file contents, terminal output, diffs, screenshots and local MCP results to Cursor; artifacts can also be uploaded. Local credentials and the full checkout staying on disk do not prevent a command from printing sensitive material into an output that leaves the machine.

You now own an operational surface. Machines inside your network that run agent tool calls are machines somebody has to patch, monitor, size and eventually decommission. That cost is real and it lands on a team that did not ask for it. It is usually worth paying; it is not free, and it should appear in whoever’s budget owns it before the pilot rather than after.

Authority matters alongside confidentiality. An agent with network access and credentials can affect the systems that account can reach. Self-hosting does not settle either question. Review what information it may disclose and what actions it may take; neither boundary can substitute for the other.

The questions that actually matter now

Review residency, disclosure and authority together. These are the questions I would want answered in writing before a pilot touches anything that matters.

What identity does the agent act as? Shared developer credentials can make agent actions difficult to distinguish from manual work. Prefer a dedicated, narrowly scoped identity where the integration supports one, and verify that the logs identify the actor, action and affected resource. Do not assume an account name alone provides a usable audit trail.

What is the blast radius of a single bad decision? Read access to a repository is one thing. Ability to run arbitrary shell commands on a machine that can reach production is quite another. Write the boundary down as a list of systems, not as a principle.

What happens unattended? Cursor’s cloud agents can pick up work in response to events, hold a goal until it is met, and run long sessions; the Projects feature lets a coordinator watch a Slack channel or run on a schedule and act without being prompted. Anything that acts without a person present is a system with an external trigger, and it needs the controls a system gets — not the controls an editor plugin gets.

How is it turned off? Every genuinely useful automation eventually needs to be stopped in a hurry. Knowing who can do that, at three in the morning, without a vendor ticket, is the difference between an incident and an outage.

How to run the review so it finishes

The failure mode in regulated organizations is not saying no. It is never quite finishing the conversation — a review that stays open until the enthusiasm has drained out of everyone involved.

Two things prevent that. First, scope the request narrowly enough to actually approve. “Approve AI coding tools” is not a decision anybody can make. “Approve this tool, self-hosted, for these four repositories, read plus branch-write, no production credentials, for ninety days, reviewed at the end” is a decision somebody can make on a Tuesday.

Second, name who decides and by when, at the start. Security reviews that drift are almost never drifting on the technical merits; they are drifting because no single person owns the yes.

What a pilot proposal should contain

One page. If it runs longer, it will be read by fewer people and approved by none of them.

The systems, by name. Which repositories, which environments, which services the agent may reach. A list, not a category. “Non-production” is a category and it always turns out to include one thing that talks to production.

The identity and its permissions. What account the agent acts as, what that account can do, and who granted it. If the answer is a shared service account that four other things already use, say so — that is a finding, and better in your own proposal than in someone else’s audit.

What runs unattended, and what does not. Draw the line explicitly. A reasonable starting position: the agent may read anything in scope, may open a pull request, and may not merge, deploy, or touch anything carrying production credentials without a person.

The logging. What is recorded, where it goes, how long it is kept, and who can read it. If you cannot reconstruct what the agent did last Tuesday, you do not have a pilot, you have an experiment on yourself.

The end date and the review. Ninety days, with a named person who decides whether it continues. A pilot with no end date is a deployment that skipped the approval.

The part that is genuinely harder in healthcare

If you work with clinical systems, inspect the provenance of test fixtures before using them. A non-production label is not evidence that records are safe to disclose. For a self-hosted agent, trace the path from a file through tool output, model context, stored artifacts and shared notes. Use synthetic fixtures for the initial pilot and involve the organization’s privacy and security owners before introducing sensitive data.

Before enabling anything with a shared memory, find out what is actually in your non-production data. The honest answer is often uncomfortable, and it is much better discovered by you than by a regulator. This is the same exercise as tracing where records actually live, and it tends to produce the same surprise.

What I would do this quarter

If AI tooling has been blocked on security at your organization, this is the moment to reopen it — not with a request for blanket approval, but with a narrow, time-boxed, written proposal that names the systems, the identity, the boundary and the off switch.

And if it has not been blocked, and engineers are already using these tools on their own machines with personal accounts, then the residency question was answered a while ago without you. That is worth knowing too, and it is a better reason to run the review now than any feature announcement.

Published September 2026. Execution and disclosure claims reviewed 10 October 2026 against Cursor’s launch note, self-hosted machine documentation, privacy guidance and Projects announcement. The pilot controls are DWKD recommendations, not a compliance certification.

Try this

Choose one proposed agent workflow and trace a synthetic file through tool output, model context, stored artifacts and shared notes. Record the destinations, retention controls, acting identity and permitted actions. Compare those findings with the security requirement before asking for approval.