How can security teams tell whether an agent marketplace is becoming unsafe?

When an agent marketplace stops behaving like a catalog and starts behaving like a distribution channel

An unsafe marketplace usually shows up first in the operating model, not the UI. The warning signs are a rapid rise in installs with shallow review, secrets appearing in places the platform does not govern, and agents gaining access to multiple tools without narrow task boundaries. At that point, the marketplace is distributing authority, not just extensions.

Once installation speed outruns review, the platform is no longer acting like a curated intake point. Security teams should treat that as a control-design problem: the issue is not merely how many items exist, but whether each item is being evaluated against what it can read, call, and persist with after deployment.

A second signal is whether the platform normalises credential storage outside managed secret systems. If developers or operators are expected to paste API keys, refresh tokens, or session material into plugin settings, memory, or local config, the marketplace is creating hidden persistence for access. That turns each add-on into a possible credential holder with its own lifecycle risk.

A third signal is scope creep across business tools. A marketplace becomes materially unsafe when a single agent can reach email, ticketing, chat, data stores, and admin consoles under broad consent, because compromise of one extension can become compromise of many workflows. The platform should make tool scope visible and constrained at install time, not discovered later in incident response.

What changes when review, secret handling, and tool scope are weak

The practical distinction is between software distribution and delegated authority. A normal extension model can be contained if permissions are narrow, credentials are centrally governed, and access is easy to revoke. An unsafe marketplace collapses those boundaries by turning each new skill into a reusable access path that may outlive the business need that justified it.

Security teams should also watch for weak offboarding behaviour. If uninstalling an agent does not clearly revoke tokens, remove stored secrets, and invalidate connected sessions, then the marketplace is leaving behind standing access. That creates a hidden population of dormant but still capable integrations.

For agent ecosystems, the relevant comparison is AI Agent Authorisation Guide style least-privilege control, not simple app installation. The more a marketplace allows broad default consent, the more its risk profile resembles identity delegation than software curation.

The same issue is visible in deeper platform design. MCP Security Guide is relevant here because tool gateways, token passthrough, and local credentials can make a marketplace look benign while quietly expanding runtime access.

How to judge whether the unsafe pattern is emerging in practice

Use observable control failures rather than vendor claims. If you cannot answer which permissions each installed agent has, where its secrets live, and how quickly access can be removed, the marketplace is already too opaque for confident use. Security teams should favour marketplaces that expose the authorisation boundary explicitly and support per-action or per-skill approvals.

AI Agent Observability, Audit and Incident Response Guide is useful because unsafe marketplaces eventually become detection problems. If you cannot attribute actions to the installed skill and see when credentials are used, you cannot distinguish normal autonomy from abusive behaviour.

Review the install path as a governance signal. A platform that encourages one-click publishing, broad default permissions, and vague ownership is optimising for adoption, not safety. A safer model forces the publisher to declare the tool scope, the secret dependency, and the expected revocation path before the agent is widely deployed.

Risk and Threat Considerations

An unsafe marketplace increases blast radius because one malicious or overprivileged skill can become a gateway to multiple systems. The most serious failure is not just malicious code, but normal-looking integrations that quietly accumulate credentials and broad access until a single compromise can spread laterally across business tools.

Failure mechanism: Fast installation, unmanaged secret storage, and broad cross-tool access remove the review and containment steps that normally separate an extension from a privileged access path.

Impact: Attackers or careless publishers can use the marketplace to harvest secrets, persist access after removal, and pivot into email, ticketing, data, or admin systems through apparently legitimate agent actions.

Practitioner Guidance

What to verify: Require each marketplace item to declare its exact tool scope, secret dependency, and revocation behaviour before approval. If those three things are not visible, treat the platform as high risk even if the extension catalog looks well controlled.

Decision rule: If an installed skill can reach production systems, the question is no longer whether the feature is useful, but whether its permissions are narrower than the business task it performs. When scope exceeds task, block or constrain it.

What good looks like: Safe marketplaces make install, consent, secret storage, and offboarding observable and reversible, so security teams can prove that access is bounded rather than assumed.

Practitioner takeaway: A marketplace becomes unsafe when it starts distributing authority faster than the organisation can review, scope, and revoke it.

Related resources from NHI Mgmt Group

• How can security teams tell when an agent workflow is becoming unsafe?
• How can security teams tell whether a reused agent has unsafe inherited settings?
• How can security teams tell whether AI agent access is drifting out of scope?
• How can security teams tell whether agent access is actually under control?