Cisco Cloud Control Makes Agent Tool Governance Mainstream

On June 2, 2026, Cisco announced Cloud Control, a platform where human operators and AI agents run critical IT infrastructure from one control plane. It entered controlled availability in the US the same day, its Agent Builder connects third-party systems over Model Context Protocol, and Reuters reported a third-party tool marketplace for the second half of the year. Agent tool governance just became an enterprise procurement question.

Updated September 2026: the marketplace Reuters described has arrived. Network World describes it as “a catalog of apps, agents, and integrations built by Cisco, customers, and partners” that already carries integrations from more than 50 ecosystem partners, including AWS, Google Cloud, Microsoft, Okta, PagerDuty, ServiceNow, Slack, Snowflake, Tenable and Wiz. The admission-control guidance below is unchanged, and now applies to a live catalog rather than a roadmap item.

Cisco calls the operating model AgenticOps: agents reason over telemetry, propose or take actions, and work under human oversight. The security detail that matters is the extension model. Cisco’s Agent Builder announcement is explicit about how anything outside Cisco gets reached:

For systems without a native integration, Agent Builder supports Model Context Protocol (MCP), an open standard that lets AI agents securely access tools, data, and enterprise systems beyond Cisco.

— Cisco Blogs, Announcing Cisco Cloud Control Agent Builder

Reuters coverage, republished by WTAQ, added the marketplace timing. TechRadar’s coverage framed the launch around the pressure security teams keep repeating: AI-driven attacks move faster than human-only operations can handle.

Key figures

Figure	What it measures	Source
June 2	Announcement date; Cloud Control entered controlled availability in the US that day	Cisco newsroom
50+	Ecosystem partners with integrations in the Cloud Control Marketplace	Network World
Second half of 2026	Reuters’ reported window for the third-party tool marketplace	WTAQ / Reuters
July 2026	Planned global availability of Cisco IQ Quantum Ready Assessments	Cisco newsroom
December 2026	Target for quantum-safe capability across the majority of Cisco’s core portfolio	Cisco newsroom
3,984	Agent skills Snyk analysed across two public registries	Snyk ToxicSkills
36.82%	Of those carried at least one security issue	Snyk
13.4%	Carried a critical-severity issue	Snyk
1,184	Malicious skill packages catalogued in the ClawHavoc registry campaign	Antiy CERT
12	Author IDs those 1,184 packages were attributed to	Antiy CERT

The last five rows are the reason the first five matter. Every registry that grew fast without admission criteria ended up with a double-digit percentage of hostile content — the full account is in the ClawHavoc post-mortem.

Why This Is A Supply-Chain Story

Cloud Control is designed around a reasonable premise: security and infrastructure teams cannot respond to AI-speed threats with disconnected dashboards and manual handoffs. Agents need shared telemetry, identity, policy, and action paths. Humans need visibility into what agents are doing.

But every agent action path is also a supply-chain boundary.

When an enterprise connects a third-party tool to an agentic operations platform, it is not just adding a data source. It may be adding a new way for an agent to query vulnerabilities, open tickets, change network policy, inspect code, trigger remediations, access observability data, or call cloud APIs.

That looks a lot like the rest of the agent ecosystem:

• A skill changes what the agent is instructed to do.
• A plugin or connector changes what the agent is able to reach.
• An MCP server exposes tools, schemas, descriptions, and handlers.
• A marketplace decides which capabilities are discoverable and easy to install.

The difference is blast radius. A coding skill that touches a local repo is risky enough. An infrastructure agent that can act across networking, security, identity, observability, and collaboration systems needs a much tighter trust model.

Figure: the same artifact review that is adequate for a coding skill is not adequate for a connector wired into network policy and identity.

This is why Cisco’s “humans in control” framing is necessary but incomplete. Human approval helps, but approval only works if the human sees the right artifact. The operator needs to know which tool is being called, which connector provided it, which version was approved, what permissions it has, and whether the tool surface has changed since review.

MCP Connectors Need Admission Controls

Cisco’s Agent Builder post says MCP support will let customers and partners build connectors for tools beyond Cisco. That is the right interoperability move. It is also where security teams should slow down.

MCP is not just a transport. It is a way to present capabilities to a model. The model sees tool names, descriptions, schemas, and returned content, then chooses actions. A connector can be useful, vulnerable, over-permissioned, or malicious at any of those layers. The protocol’s own security best practices, OWASP’s practical guide for secure MCP server development and the Cloud Security Alliance’s Agentic MCP security best practices all say the same thing from three directions: the server is infrastructure, and it needs inventory, boundaries and validation like any other.

We have covered several versions of this problem already:

• MCP tool poisoning, where hidden tool metadata can steer an agent in ways the user never sees.
• MCP RCE risk, where plugin installation starts to look like running local executable code.
• VIPER-MCP taint scanning, where model-filled tool arguments can flow into shell commands, file access, SSRF, or database queries.
• NSA MCP guidance, which treats MCP servers as operational infrastructure that needs inventory, trust boundaries, parameter validation, sandboxing, and monitoring.

Cloud Control does not create those risks. It validates that the market is moving toward exactly the environment where those risks matter most: centralized agent platforms with extension points. Our running checklist for that environment lives on the MCP security page.

If a marketplace can install or enable a connector, the marketplace needs more than categories and popularity signals. It needs admission criteria.

Figure: four gates before install, one monitor after it — and a changed tool surface re-enters at gate two rather than inheriting the old approval.

Useful admission controls should include source provenance, publisher identity, version pinning, dependency review, secret scanning, tool metadata review, handler-level code scanning, permission manifests, runtime auditability, and re-review when the tool surface changes. That is 10 criteria, and none of them are satisfied by a star rating.

For MCP connectors, the approval unit should be precise: this publisher, this connector, this version, this set of tools, this schema, this permission set, this deployment boundary. Anything broader becomes a blank check.

The Marketplace Changes The Incentives

Marketplaces make ecosystems grow. They also make trust shortcuts tempting.

An operator under pressure will install the connector that solves the incident. A team building an agent workflow will choose the integration that already exists. A vendor with a useful tool will want distribution. A platform will want a broad marketplace because breadth makes the platform more valuable.

That is normal. It is also exactly how package, browser extension, IDE plugin, and CI action ecosystems accumulated supply-chain risk. The agent-skill version of that story took six days: Antiy CERT catalogued 1,184 malicious skill packages from 12 author IDs on a registry that had no pre-publication scan.

Agent tool marketplaces add one extra complication: the artifact being installed may not be only code. It may include natural-language instructions, tool descriptions, schemas, prompt templates, hosted endpoints, OAuth scopes, local handlers, background services, and runtime-discovered tools.

That means marketplace review has to answer more than “does this package contain malware?”

It has to answer:

• What can this connector cause an agent to do?
• Which credentials or systems can it reach?
• Which tool descriptions will be loaded into model context?
• Can the connector change its available tools after approval?
• Are model-filled arguments validated before reaching dangerous operations?
• Can output from this connector steer another tool in the same session?
• Is the installed artifact identical to the reviewed artifact?

Those 7 questions are supply-chain questions, but they are agent-native supply-chain questions.

Practical Defenses For AgenticOps Teams

Start with inventory. Track every skill, plugin, connector, MCP server, hosted agent, and marketplace-installed tool your agents can reach. Include local developer agents, CI runners, SOC workflows, infrastructure automation, and desktop copilots. For the MCP half of that inventory, our 12-check checklist sets out what to verify before install, at the call, in flight, and on every update.

Tie every capability to provenance. Record publisher, source repository or vendor, version, hash where possible, deployment location, credential scopes, exposed tools, and last review date. If a connector is hosted and dynamic, record the endpoint and the observed tool surface.

Separate read-only context from action authority. An agent that can search documentation is not the same as an agent that can change firewall policy, rotate credentials, deploy code, mutate databases, or post to incident channels. Put stronger approval and logging around actions with real blast radius.

Treat model-filled tool arguments as untrusted input. Connector handlers should validate types, lengths, formats, paths, URLs, commands, and resource identifiers. Use allowlists for destinations and operations. Avoid shell-built command strings. Parameterize database queries. Remove dynamic execution sinks.

Require re-review on drift. A new tool, changed description, broader schema, dependency update, widened OAuth scope, or changed endpoint should not inherit the previous approval automatically.

Log the chain, not just the result. For every sensitive action, capture the user request, selected agent, selected tool, connector identity, argument hash or redacted argument, policy decision, human approval state, and output summary. Without that chain, post-incident review becomes guesswork.

Finally, scan before trust. Static scanning can catch suspicious skill instructions, malicious subprocess calls, credential access patterns, obfuscation, risky install scripts, and poisoned metadata — you can run that scan on any public skill from the web scanner. MCP-aware scanning can inspect tool descriptions and handler code. Runtime monitoring can catch exposed ports, unexpected network egress, and tool-call chains that cross trust boundaries.

Where SkillSafe Fits

SkillSafe is focused on the artifact layer of this problem: the skills and plugin-like bundles that change how agents behave before they act.

Cisco’s launch reinforces why that layer matters. Enterprise platforms are moving toward governed agent builders, MCP connector ecosystems, and third-party marketplaces. Those platforms still depend on the trustworthiness of the artifacts and integrations they load.

A skill can look like documentation while changing agent intent. A connector can look like an integration while expanding agent reach. An MCP server can look like a harmless API bridge while exposing a dangerous handler. A marketplace listing can look approved while pointing to an artifact that later drifts.

The defense is layered:

1. Verify the publisher and source.
2. Scan the artifact the model will read.
3. Scan the code the tool will run.
4. Pin the reviewed version.
5. Compare what the consumer installs with what was reviewed.
6. Scope the runtime permissions.
7. Monitor what agents actually do.

That is the same logic behind dual-side verification. Publisher-side scanning catches problems before sharing. Consumer-side scanning checks what actually arrives before install. Cryptographic comparison detects tampering between those two points.

Frequently Asked Questions

Are MCP servers a security risk?

They are a risk surface, not a defect. An MCP server presents tool names, descriptions, schemas and returned content directly to a model, and the model acts on all four. The protocol’s own security best practices and OWASP’s secure MCP development guide both treat a server as infrastructure requiring inventory, validation and monitoring.

How do you secure MCP connectors in an enterprise?

Pin the approval unit: this publisher, this connector, this version, this tool set, this schema, this permission set, this deployment boundary. Add provenance records, handler-level scanning, secret scanning and runtime logging, then require re-review on any drift in the tool surface. The checklist we maintain is on the MCP security page.

What should an agent tool marketplace check before listing a connector?

Ten things: source provenance, publisher identity, version pinning, dependency review, secret scanning, tool metadata review, handler code scanning, a permission manifest, runtime auditability, and re-review on drift. Popularity is not one of them — Snyk found 36.82% of 3,984 published skills carried at least one security issue, install counts included.

What is AgenticOps?

Cisco’s term for operations where AI agents and humans work from the same control plane: agents reason over telemetry, propose or take actions, and operate under human oversight. Cloud Control is Cisco’s implementation, announced June 2, 2026 and in controlled availability in the US from that date.

Does a marketplace listing mean a connector was reviewed?

Only if the marketplace says what it reviewed and when. A listing usually attests to a point-in-time check of one version. If the connector can add tools, change descriptions or widen scopes after approval, the listing describes an artifact that no longer exists — which is why drift re-review, not initial review, is the control that holds.

Cisco Cloud Control is a signal that agent tool governance is becoming mainstream. That is good news. It means the industry is admitting that AI agents need identity, policy, observability, and human oversight.

The next step is making sure the tools those agents consume are verified too. More on that in our supply-chain coverage.