agent-client-security

Agent / Client Security

When your code runs on a machine you do not fully control — a customer's laptop, a remote worker's server, a customer-deployed VM, an IoT device — the threat model flips. The local user can read your binaries, intercept your traffic, modify your config, and lie to your control plane about what they are. The defenses are different from web-server hardening.

Applies to: monitoring agents, RMM tools, CI/CD runners on customer infra, MDM agents, deployment agents, IoT controllers, sync clients, backup agents.

When to invoke

• Shipping a new native agent / endpoint client for the first time
• Designing the installer or update channel for one
• After an incident where a client was tampered with or impersonated
• Auditing an agent product before integrating it (vendor review)
• Reviewing an inherited agent codebase

Pairs with distributed-system-audit for the system view, ios-security for mobile specifics, mcp-security for agent-like LLM tooling.

The threat model — assume the host is hostile (eventually)

For each thing your agent does, assume:

• The local user can read every file the agent writes
• The local user can intercept every network call (their own machine, their own CA store, their own packet capture)
• The local user can modify the agent binary (replace, hook, debugger-attach, decompile)
• The local user can run multiple instances of the agent, or instances of a fake agent claiming to be a real one
• Time on the local machine is what the local user says it is

You cannot prevent all of this. You can ensure:

• The control plane never trusts the local user's claims without verification
• A compromised agent's blast radius is bounded
• Tampering is detectable, even if not preventable
• The credential the agent holds, by itself, cannot do too much

Step 1 — Installer integrity

The first interaction between your software and the customer's machine. If you get this wrong, every subsequent control is moot — the user installed something else thinking it was you.