Announcing LimaCharlie Application Control: Decide What Runs on Every Endpoint

LimaCharlie Application Control is available now. It decides which programs may run on your Windows and macOS endpoints, and the LimaCharlie sensor enforces that decision at the moment a program starts. You write an allowlist or a blocklist, watch what it would block, and turn on blocking when the reports go quiet. Every decision the sensor makes becomes an event, the same as all other telemetry in LimaCharlie.

Allowlisting has been its own project

Application allowlisting appears in CIS Controls v8, the Australian Essential Eight, and NIST SP 800-53, because a program that never starts cannot do damage. It often arrives as a separate tool, with another agent on every machine and another console to watch. Its block events stay in that console, away from the endpoint telemetry that explains them.

The rollout is the hard part. A policy that blocks on day one can stop a payroll tool or a self-updating browser, and the security team is left approving exceptions one ticket at a time. For MSSPs, that work repeats for every client.

Every decision is an event

Application Control runs in the sensor that already collects your endpoint telemetry, so the execution decision and the telemetry come from one place. A block, or a would-be block, arrives as an event carrying what you need to judge it: the file path and hash, the signer, the rule that matched, the parent process, and the user.

Because those are ordinary events, detection and response rules (D&R rules) can act on them. A rule can report every would-be block so you can group them by signer, or raise a detection when a program is blocked on a server that should never run anything new. Repeats of the same verdict within five minutes fold into one summary event with a count, so one noisy program does not flood your detections.

How LimaCharlie Application Control works

Write a policy and its rules

A policy says which sensors it covers, by operating system and by tag, and each sensor follows the first enabled policy that matches it. The policy's stance sets the default answer. An allowlist denies any program that no rule allows, and a blocklist allows any program that no rule denies. Software signed by Microsoft or Apple can be trusted as well, so the operating system keeps working.

Rules allow or deny one thing: a publisher's signature, a file path, a single file by its SHA-256 hash, or a macOS signing identifier. A signer rule keeps matching when software updates itself, so it is the one to prefer. A deny rule always wins.

Start in a mode that cannot block

Each policy has a mode. Audit reports what the policy would block and blocks nothing. Rehearsal runs the full blocking path and then allows the program anyway, which makes it the last check before enforcing. Enforcing blocks.

In the console, Observations lists the programs your policies have judged, marked Would block or Blocked. Allow turns an observation into an allow rule, shows you the rule before it is written, and warns you when a signer rule would trust a lot of software. A readiness card counts what a policy would block if you enforced it today.

Roll out by tag

Tags make the rollout gradual. A broad policy audits every machine, a pilot group rehearses under one tag, and a smaller group enforces under another. Moving a machine from one stage to the next is a tag change, and stepping back is a tag change too.

Keep self-updating software working

Under an allowlist, an updater can unpack helpers that carry no signature. A trusted installer rule names the updater, and the sensor then trusts the processes it starts and the files it writes. The sensor records those files by digest, so a copy keeps the trust and a modified file loses it.

Install software without switching the policy off

Install mode gives one host, or a selection of hosts, a window of one hour up to a week where Application Control only reports. You install or update the software, review what ran, and the host returns to its normal policy when the window ends.

Respond during an incident

Wherever the console shows a file hash, Block with Application Control creates a deny rule for that exact file. It takes effect on sensors whose policy is enforcing. Lock down host contains a machine during an incident: programs the lockdown policy refuses are stopped and new ones are blocked, while the host keeps its network connection so you can keep investigating it. A D&R rule can request lockdown automatically by adding a tag.

Tell people why

When a program is blocked, the person at the keyboard can get a desktop notice that says so, with an optional tray icon that keeps a history of blocks. They learn what happened from the machine itself before they open a ticket.

Export evidence for an assessor

Export compliance evidence collects your policies, rules, enforcement coverage, and observations into one archive with a PDF report and CSV files. The report states capability coverage plainly. Program execution on Windows and macOS is controlled, which partially covers CIS Controls v8 2.5, the Essential Eight application control strategy, and NIST SP 800-53 CM-7(5). Scripts, DLLs, and MSI packages are outside its control, and the report says so.

Manage everything as code

Policies and rules are Config Hive records. The API, the LimaCharlie CLI, and Git Sync manage them the same way they manage the rest of your deployment, and two permissions decide who can read them and who can change them. An AI agent working through the CLI reaches Application Control with the same permissions as any other caller, alongside the EDR telemetry, Cloud Security, Code Security, and Email Security it already operates.

Built for service providers

For MSSPs and MDR providers, each client runs as its own LimaCharlie organization with its own policies, rules, and audit trail. Package a baseline of publisher rules and a staged set of policies as code, deploy it to every client organization, and adjust per client with rules scoped to that client's policies.

Application Control arrives through the sensor you already deploy for endpoint coverage, on sensor version 5.4.0 or later. Onboarding a client to allowlisting becomes a subscription and a policy, and the client's block events land in the same detections and cases your analysts already work.

Where it fits in your stack

Application Control judges a program when it starts, on Windows and macOS. Linux is not supported. It controls executables, and it does not control scripts, libraries, or MSI packages, so it sits alongside your detection and response rules and your EDR telemetry as one control among several. Subscribing to the extension changes nothing on an endpoint until a policy matches it.

Pricing and availability

Security tools are being repriced, because AI makes almost any single tool practical to rebuild. What is left to pay for is the convenience of someone else running the infrastructure and the integration of every capability on one system. LimaCharlie builds each capability on shared infrastructure, which is why Application Control is listed at $0.40 per sensor on our pricing page, billed through your existing LimaCharlie account.

Application Control is available now for Windows and macOS. Subscribe to the Application Control extension in the Add-Ons marketplace, then create your first policy in Audit.

Get started with Application Control

• Create your free LimaCharlie account

• Application Control documentation

• Policy reference and staged rollout examples

• Rule reference

• Get a demo