What ThreatLocker Web Control is
ThreatLocker Web Control is the module that decides whether a website loads on your work computer. You are probably reading this because a page was blocked or a Request Access prompt appeared. It runs inside the ThreatLocker agent already on your device and checks where a request is going before the browser connects.
This is the endpoint half of web and DNS filtering, one layer of our managed cybersecurity and compliance stack. Most layers deal with what runs; this one takes the destination away first.
What gets filtered
Policy is set by category, not site by site: a list of sites is out of date the day it is written.
- Security categories cover destinations built to cause a problem: phishing and credential-harvesting pages, malware downloads, and the servers malware calls home to. Blocked by default.
- Acceptable-use categories cover what is not dangerous but does not belong on a company device. Where that line sits is your call, not ours.
Categories are set per group, so a team that needs something open can have it without loosening policy for everyone.
What a block looks like
When Web Control stops a page, you get a ThreatLocker notification instead of the site. It names what was blocked and usually offers a Request Access option.
If you do not recognize what set it off, ignore it. We review blocked activity on our side, so a block is the system working, not something to chase.
Requesting access to a site
Request Access sends it to us. Our system triages it and an engineer picks it up without you writing a ticket.
Most come back approved and the page opens. Some need a question first, so say what the site is and why you need it. A few are declined, and the answer comes back on the ticket rather than going quiet.
If you know something is coming, like a vendor portal you are about to start using, send a ticket to support@umbrellaitgroup.com ahead of time and the policy will be ready.
Why web filtering runs on the device
Filtering used to reach your computers through a separate DNS agent that checked destinations at the lookup. That is a sound control and still does that job well.
What changed is the lookup. Browsers now ship their own encrypted lookup settings, so a browser resolving a name privately walks past any policy that only sees lookups. Web Control reads the request itself. Folding that job into the agent your device already runs means one agent to maintain instead of two.
So web and content filtering is enforced on managed devices through ThreatLocker Web Control, the same agent that already handles application allowlisting, with ThreatLocker’s Cyber Heroes team behind exception requests. Requests are actioned within fifteen minutes, around the clock, on every plan. The policy lives on the agent: no separate DNS-filtering service, and no second agent to install.
Related articles
- ThreatLocker Zero-Trust covers the allowlisting side of the same agent: why an app gets blocked.
- Microsoft 365 ATP P2 covers the email side: what gets quarantined, and how to report a message that got through.
- Creating Good Passwords covers how to build passwords that survive a leak, and why reuse turns one breach into many.
The services behind this article
For the service-level view: endpoint protection and EDR covers the antivirus and EDR agent watching what runs on your device; managed detection and response covers the people watching what got past.
Common questions
A site I need for work is blocked. What do I do?
Use the Request Access option on the notification. If it is gone, send a ticket to support@umbrellaitgroup.com with the address.
Why is it still blocked on my home wifi?
Because the policy lives on the computer, not on whichever network you are using. That is deliberate: the protection you have at your desk is the protection you have everywhere.
Is this the same as the app approval prompts?
Same agent, different module. Those prompts are application allowlisting, covered in ThreatLocker Zero-Trust. Web Control only looks at where requests go, and there is nothing to install.
