Local-first agents are often sold on privacy. Your data stays on your machine. No cloud middleman reads your prompts. The agent can talk to nearby agents without routing every request through a centralized platform.
That privacy story has a security inversion: the same properties that make local-first agents feel safer to users can make them look suspicious to enterprise security teams.
The feature that gets you blocked
Unobservable peer-to-peer chatter between processes on an internal network is not a new pattern for defenders. Security teams already have a category for internal systems that talk to each other outside normal controls, especially when identity is weak and payloads are opaque. In the wrong context, it looks exactly like lateral movement.
When an agent on one host opens a connection to an agent on another host, authenticates weakly or not at all, and exchanges instructions that no governance layer can inspect, benign intent may not matter. The traffic has the shape of something security tooling is trained to distrust.
A traditional network gateway cannot automatically inspect every intra-subnet agent exchange. In many environments, that visibility requires host-level telemetry, EDR or XDR integration, a zero-trust mesh, service identity, or some other control plane close enough to the workload to observe what is happening. Enterprise security will ask whether the agent is legible to whatever enforcement layer exists. Which box handles enforcement is a secondary question.
The Shadow IT pattern, repeated
Employees adopted Dropbox, Slack, and other unsanctioned SaaS tools because the official tools were slow and the shadow tools worked. IT rarely responded by celebrating the productivity gains. The usual sequence was blocking, investigation, and eventually sanctioned equivalents with SSO, audit logs, admin controls, and retention policies.
A2A can follow the same path. The first wave of agent adoption inside enterprises is likely to be bottom-up, because useful tools spread through teams before procurement catches up. A later governance response is plausible, especially once agents start moving data, invoking tools, or coordinating across machines.
The agents most likely to survive that response are the ones that can show their work: clean audit trails, policy hooks, workload identity, and records a security team can use during an investigation. Usefulness alone does not clear that bar.
The governance layer may arrive through gateways, data platforms, endpoint controls, or service meshes. The specific product path matters less than the control surface. As enterprises build AI governance layers, local agents that bypass those layers risk being classified as unsanctioned infrastructure.
Concrete shape of the problem
Consider three patterns a security control plane could flag:
- An agent initiates connections to peers without presenting a verifiable workload identity. To a policy engine, this can look like an unauthenticated process moving laterally.
- Agent-to-agent payloads are opaque to inspection. If the control layer cannot see what instruction crossed the wire, it cannot prove the action was authorized, so denial or quarantine becomes easier to justify.
- There is no exportable record of who asked the agent to do what. Without an audit trail, the agent cannot be cleared during an investigation, so it may be treated like unknown software rather than approved automation.
None of these require the agent to be malicious. They only require it to be illegible. Illegibility is the failure mode.
The defensible claim
The claim is narrow: a local-first architecture without an observability and policy export layer is at risk in enterprise environments. Invisible systems are hard to approve, hard to investigate, and easy to block.
The security surface has moved beyond the prompt window. Prompt injection is still a real threat model, but unsanctioned agent traffic is a different problem. It asks different questions: Which workload is this? Who authorized the action? What policy applied? What crossed the wire? Can the record survive an incident review?
What this implies for builders
If you ship local-first agents, the observability port is not an enterprise checkbox to add later. It may determine whether an enterprise can run your agent at all.
Build for legibility now:
- Workload identity that an enforcement layer can attest, and that meshes, EDR, gateways, or governance systems can consume.
- Audit records that show who asked the agent to do what, when, and through which policy path.
- Policy hooks that let a security team express "this agent may do X but not Y" in its own tooling.
- Deployment modes that respect environments where inspection happens at the host, service mesh, endpoint agent, or gateway rather than assuming one universal enforcement point.
The enterprise winner will be the agent that makes local execution accountable. "Your data stays local" is a privacy claim, not an accountability one. Conflating them is how local-first turns into rogue traffic.