A Privacy Toggle Is Not a Security Control

This incident involved one vendor, but the underlying issue applies more broadly to coding agents.

Coding agents need meaningful access to be useful. They read repositories, run shell commands, inspect build output, use credentials available in the development environment, and communicate with remote services. From a security perspective, that makes them privileged integrations.

The question is not whether agents need access. It is how much access they receive, what they transmit, and what evidence the customer can retain independently.

A client-side setting can document a vendor's intended behavior. It does not, by itself, show what data was sent, retained, or used downstream. Important boundaries need support from controls the customer can inspect or enforce, such as network logs, egress policy, scoped credentials, local session records, and clear retention terms.

This is a supply-chain concern. A third-party tool can reach more data than a developer expects to expose for a particular task. It is also becoming an ordinary operational problem. In DigitalOcean's February 2026 Currents survey, 34% of respondents said managing security across their AI tools was already a top challenge.

The way the Grok Build issue came to light is instructive. It was not discovered through a settings page, compliance report, or vendor disclosure. A researcher measured the traffic and compared what the task appeared to require with what the client actually transmitted.

The mismatch was the evidence.

Client setting: "Improve the model" turned off.

Server behavior: Repository upload continued.

Takeaway: A training opt-out and a data-transfer control are not necessarily the same thing.

Before an agent touches a production repository, teams should get specific answers about its access and data handling.

Can the tool access only the files required for a task, or can it read the full repository and its history? Can it package or upload Git objects? What data leaves the machine, where is it sent, and how long is it retained? Does a training opt-out also apply to telemetry, debugging traces, crash reports, and support data?

Teams should also ask what audit records are available and whether they can export or retain those records themselves.

A settings page is useful documentation. It is not independent evidence that a boundary is being enforced.

Controls that matter should not depend entirely on a vendor's interface.

Use scoped and short-lived credentials. Keep secrets out of tracked files and repository history. Restrict outbound traffic where practical. Run higher-risk tools in isolated environments. Monitor for unexpected data movement.

These controls require more work than selecting a checkbox, but they are visible to the team responsible for the risk.

Many teams can review the code an agent changed but have a weaker record of the activity surrounding those changes.

Which repositories did the agent access? Which files did it read? Which commands and tools did it run? Which credentials were available in the environment? What changed during the session?

A session record is not a packet capture. It may not reveal an upload initiated inside a vendor-controlled binary. Network telemetry is still required to establish what left the machine.

A session record does provide another important part of the evidence. It can show which agents ran, what they could access, what actions they took, and which systems or credentials may have been within reach. Combined with network logs and egress controls, that can make incident scoping substantially faster.

When the only detailed activity record lives with the vendor, an investigation depends on that vendor's retention policies, product behavior, and willingness to provide access. Keeping an independent record gives engineering and security teams a stronger starting point.

Removing a secret from the current branch does not remove it from Git history.

If a tool may have uploaded a repository bundle, rotate any credentials that were present in the repository or its history, including credentials believed to have been deleted. Review access logs where available and invalidate tokens that may have been within reach.

The better long-term approach is to prevent secrets from entering tracked files in the first place and to limit the scope and lifetime of any credential available to an agent.

AgentPM is built around the idea that teams using coding agents should own a record of agent activity.

The AgentPM collector runs on your machines and captures agent sessions, including what agents read, the commands and tools they used, the changes they made, and the context of the work. It turns that activity into a searchable record for engineering and security teams.

That record complements network monitoring rather than replacing it. AgentPM does not make a vendor-controlled client trustworthy, and session data alone may not expose a hidden network transfer. What it can provide is a customer-controlled account of the activity around the event.

When a vendor issue is disclosed, teams can use that record to identify the affected sessions, repositories, files, and credentials. They can begin scoping the incident from evidence they already hold rather than relying entirely on the vendor's account.

The Grok Build issue was uncovered through independent observation. Teams should not need to reconstruct every agent session from memory when something goes wrong. A durable record of agent activity should be a normal part of operating these tools.

Coding agents are becoming a routine part of software development, often with repository, shell, and credential access. That access should come with the same expectations applied to other privileged systems: clear scope, enforceable boundaries, and evidence the organization can retain.

Privacy settings still matter. They should not be the only evidence a team has.