How mShield Works | Package Policy Enforcement at Install Time

Between your team and the registry

mShield evaluates package requests routed through it from developer workstations and CI runners. Existing internal repositories can remain part of your setup.

The control point

Developers & CIUse familiar package manager commands.

mShieldIdentify the package and apply your policies.

Package registryServe the artifact when policy allows it.

Only requests routed through mShield are covered. Existing local caches and other download paths are outside this flow.

SaaS or on-prem: choose where mShield runs

The deployment model determines who operates mShield. The routing mode determines how package requests reach it.

Managed by CloudKitty

SaaS

Use a hosted mShield endpoint. We operate the service; your team configures clients and manages package policies.

Your developers & CImShield SaaS
CloudKitty-operated serviceUpstream registry

Client configuration
Point package managers at your mShield endpoint.
DNS mode is not available in SaaS.

Operated in your infrastructure

On-prem

Run mShield in your own environment. Your team manages the infrastructure, network access, and service operations.

Your developers & CImShield on-prem
Inside your infrastructureUpstream registry

Client configuration or DNS mode
Point clients at mShield, or route supported registry domains through it using internal DNS.

DNS mode is on-prem only. Your team configures internal DNS, routing, and the certificate trust required for HTTPS registry traffic. Package manager registry URLs can stay unchanged; network and trust setup are still required.

Agree the hosting location, access requirements, and decision-record storage before provisioning. See deployment guidance for setup options.

One request. A clear decision.

Identify the package
Read the package name, version, and ecosystem from the request.
Evaluate your policies
Check vulnerability thresholds, known malicious releases, license rules, and custom conditions.

Policy outcomes

Does the request satisfy your policy?The configured enforcement action determines what happens next.

Allow → downloadForward the request to the registry. Warning mode also allows the request and records the policy finding.

Block → explainRefuse the request and record the reason. The blocked artifact is not served through mShield.

Both paths produce a decision record for operators to review.

A blocked install comes with a next step

The install fails when mShield refuses a package request. Where the package manager exposes the response, the developer sees the reason and a link to the block details.

Blocked package details with the policy reason, advisory, suggested upgrade, and an option to request an exclusion. — Example block details. Available actions depend on the package and deployment settings.

From refusal to resolution

Read the reasonOpen the short-lived link for this blocked request; no dashboard login is needed.

Choose a next stepUse a suggested version when available, or request an exclusion with a reason.

Review & retryAn operator reviews the exclusion. Retry after changing the version or receiving approval.

Approved exclusions are scoped, recorded, and expire. A request for an exclusion does not itself unblock the package.

Deployments can disable the details link. Operators can still investigate the decision in the dashboard.

A record your team can investigate

Review allowed and blocked requests in the dashboard: the package, requester information, policy, and outcome. Use warning-mode findings to assess a new rule before enabling blocking.

Integration

A decision before the download.

Between your team and the registry

SaaS or on-prem: choose where mShield runs

SaaS

On-prem

One request. A clear decision.

A blocked install comes with a next step

A record your team can investigate

Next

npm

PyPI

vs. an SCA scanner

See whether package policy fits your build.