Why RiskyPlugins and PrivateStores Have Separate Jobs

RiskyPlugins answers questions about third-party extensions. PrivateStores is intended to control which extensions an organisation distributes. I’m keeping the two products separate because a security finding and an approval decision have different owners.

A scanner can identify a suspicious update. It cannot decide how much disruption a team should accept to block it, or whether an exception is justified for a particular workflow.

What RiskyPlugins contributes

The public service gathers extension metadata and scans downloaded artifacts. A review can use the resulting findings alongside version history and publisher information. The website supports manual investigation; the API and MCP service support other callers.

Its job is to make the evidence inspectable. If a finding is a false positive, I want to correct it without rewriting an organisation's policy. If an analysis is incomplete, the product needs to say so.

An organisation may use that evidence to approve an extension. Another may reject the same version because it grants access their staff do not need. Both decisions can be reasonable under different constraints.

What I want PrivateStores to control

The private-store plan covers approval workflows and controlled distribution. That includes holding an update for review, preserving an approved artifact and recording who allowed it. These are product goals; the deployed feature set must be checked before relying on any particular control.

Consider an editor extension used by a development team. Version A is approved. Version B arrives with an unexpected executable. RiskyPlugins should expose the change and supporting findings. The organisation's distribution policy should determine whether B is held and which approved version remains available.

An exception needs a reason, an owner and an expiry. That record belongs with the organisation's controls, even if the external risk assessment changes later.

Why I want the boundary to stay explicit

Public analysis has to improve its coverage and correct mistakes. A distribution service has to enforce tenant policy consistently and preserve an audit trail. Combining the two decisions too tightly would let a score change become an unreviewed rollout decision.

A clear interface lets a customer use RiskyPlugins with existing controls. It also leaves room for PrivateStores to accept evidence from another source. Neither product should require the customer to treat one scanner as infallible.

That division matters for agent tooling too. A reviewed MCP package can still connect to a remote service whose behaviour changes. Approval has to cover the access being granted and the conditions for reviewing it again.

The commercial question is whether teams will pay to use these capabilities. I expect different buyers to value the research and the distribution controls differently. Keeping the products separate gives me a way to test that without pretending the entire plan is already delivered.