What the agent does off the network

A policy that only works in the office is a suggestion. When a laptop running GuardStance leaves the corporate network, the agent keeps the last policy it received, keeps enforcing it on the device, records what happens, and sends the evidence back once it can reach the policy server again. Protection does not depend on a VPN.

Why the question matters

Most sensitive work no longer happens on the office network. It happens on a train, at a kitchen table, in a hotel, at an airport gate. Any control that lives only at the network edge stops seeing a device the moment it walks out of the building.

Older designs dealt with this by forcing traffic home through a VPN. That helps when the VPN is up. It does nothing while the laptop is offline, when someone is between connections, or when a person turns the VPN off because a video call is struggling. A USB drive does not need a network at all.

So the useful question is simple: what does the control do when it cannot reach anything?

What happens, step by step

The answer has four parts.

The policy is cached. The agent keeps the last policy it received on the device. It does not need to ask anyone what the rules are.

Enforcement continues. The same rules apply to USB drives, printing, the clipboard, uploads and AI prompts. Content is inspected on the device, so a decision does not have to wait for a server.

Events are recorded locally. Each decision is written to the device: what was found, which rule matched, who did it and where the data was going.

Evidence goes home on reconnect. When the laptop can reach the policy server again, the evidence uploads and lands in the same case timeline as everything else. An analyst can then read that person's week in one place.

Three cases worth testing

Claims about offline behavior are easy to make, so it is worth testing them. These are three simple checks for any product, including ours.

Pull the cable. Take a test laptop off every network and try the actions your policy should stop: copy a labeled file to USB, print it, paste it into a local app. The outcome should match what happens in the office, and the user should see the same explanation.

Change the policy while it is away. Publish a new rule while the laptop is offline, then reconnect it. The new rule should arrive, and the events recorded while it was away should appear in the console with their original times.

Stay away for a while. Keep the device off the network for longer than a weekend. Enforcement should not quietly lapse, and the evidence should still arrive complete when it returns.

What the user sees

Off the network, people still need to work, and they still need to know why something stopped. The message they get should be the same one they would see at their desk. If the policy asks for a business reason, the person can give it, and the answer travels back with the evidence.

This matters more than it seems. A control that behaves one way in the office and another way on the road teaches people that the rules depend on where they are sitting. A consistent one teaches the rule.

Where the limits are

Honest answers include limits. An agent on the device can only protect the device it runs on. A personal phone is outside its reach, and a policy published while a laptop is away will not apply until that laptop reconnects. Anything that needs a live lookup, such as a check against a service on the internet, depends on the connection.

None of that is a reason to give up on the laptop. It is a reason to know exactly what your control does, and to plan around it.

The question to ask any vendor

Hybrid work has made off-network behavior a basic requirement, not a feature. So ask directly: what does your agent do with no connection at all? Which channels stay covered? Where is the evidence kept, and how does it get back?

A clear answer tells you the product was designed for how people actually work. A long pause tells you something too.

Read how Endpoint DLP keeps the policy on the device.