SECURITY POLICY ENFORCEMENT
Your security policy,
applied at install time.
Define the risk and CVE thresholds your organization is willing to accept. PexLens evaluates every package request against them and blocks what fails — before the software reaches an endpoint.
Request a Demo- Your thresholds — risk score and CVE severity
- Applied everywhere — endpoints, builds, mirrors
- Fully recorded — every decision, every time
THE PROBLEM
Most security policy lives in a document.
Organizations write down what may be installed - the acceptable risk, the CVE severity limit, the approved sources. Then a developer runs an install command, and none of it is in the way.
UNENFORCED
Rules nobody can apply
A threshold that is not checked at install time is a preference, not a control.
INCONSISTENT
Different answers per team
The same package is approved in one project and refused in another, with no record of why.
UNPROVABLE
Nothing to show an auditor
Without a decision log there is no evidence that the policy was ever applied.
HOW IT WORKS
From written policy to enforced decision
01
Define
Set the risk score and CVE severity your organization will accept, and the registries requests may resolve from.
02
Evaluate
Each package request is scored against PexLens intelligence — code, behaviour, dependencies and known vulnerabilities.
03
Decide
The verdict follows your policy, not a vendor default: allow the download, warn the developer, or refuse it outright.
04
Record
Every decision is written to the console with the package, version, reason, device, project and requester.
One policy, applied consistently. The same thresholds govern developer machines, build servers and internal mirrors.
WHAT YOU CAN DEFINE
The controls in your hands
Every control can be set for the whole organization, then tightened or relaxed for a team or a single project.
01
Risk score threshold
The score at which a package is refused, and the band where the developer is warned instead.
02
CVE severity limit
Which known-vulnerability severities are unacceptable, including those inherited through dependencies.
03
Approved registries
The sources a request may resolve from, so packages cannot arrive from somewhere unapproved.
04
Extension policy
The same thresholds applied to browser and developer-environment extensions, not only packages.
05
Exceptions
Time-boxed approval for a named package and version, expiring automatically without follow-up.
06
Unresolved verdicts
What happens when a verdict cannot be produced in time - allow and flag, or hold until it can.
THE DECISION ENGINE
Three outcomes, all of them yours
The engine does not decide what is acceptable. It applies what you decided, to every request, the same way.
ALLOW
Within policy
The package is served straight through. Developers keep their existing commands and notice nothing.
[email protected] · 12/100 ALLOWED
WARN
Above the line, below the limit
The download proceeds, the reason is returned inline, and the finding is logged for the owning team to triage.
[email protected] · 58/100 WARNED
BLOCK
Outside policy
The request is refused before the download completes, and the finding is recorded against device, project and requester.
[email protected] · 91/100 BLOCKED
FROM DETECTION TO ACTION
Enforcement does not end at the verdict
When a request fails policy, the organization can respond immediately — automatically, and with a person in the loop.
AUTOMATED
Blocking
The install is refused at the moment of request, with the failing rule returned to the developer.
REAL TIME
Notification
Security and the owning team are alerted with the package, the device and the reason attached.
ADMINISTRATOR LED
Remediation
Administrators act across the fleet — adjust the rule, grant an exception, or remove what already landed.
DEFINE POLICIES FOR YOUR ORGANIZATION
Control based on your organization needs
Configure precise risk parameters for different departments. Set permissive policies for local research teams and highly strict enforcement on production deployment pipelines.
POLICY YOU CAN PROVE
Turn your security policy into a control.
Bring your thresholds to a live session and watch PexLens apply them to real package requests — allowing, warning and blocking exactly as you defined.
No agent rollout required to evaluate.
FAQ
Policy enforcement: common questions
What is security policy enforcement for packages?
It means applying your organisation’s rules, such as blocked licences, maximum risk scores or banned publishers, automatically when a package or extension is requested.
Can PexLens enforce AI usage policies?
Yes. The same policy engine can allow, warn on or block AI tools and AI-related components, and AI Guard applies policy to prompts and responses.
Can I override a decision for a specific package?
Yes. The Team plan and above include package allow and block overrides, so you can approve a package your policy would block, or block one it would allow.
Can policies be managed centrally across teams?
Yes. Centralized organization policies are included from the Team plan, and the Business plan adds advanced global enforcement.
How do we enforce an AI security policy?
Combine an approved-tools list and training with technical controls: AI Guard to inspect, redact or block sensitive data in prompts, PexLens policies for AI-related extensions and packages, and logging so you can audit usage.
Can organizations define their own security policies?
Yes. Organizations can define their own security requirements, including risk and CVE thresholds, and PexLens applies those policies when evaluating package requests.
What happens when a request breaks policy?
PexLens returns a block or alert decision with the reason, and records it for audit.
Related