Planned integrations
Mixed environments, explicitly qualified coverage
The planned scope spans discovery, assessment, management and configurable monitoring across AWS, Azure and Google Cloud services, not only compute, alongside productivity platforms and dedicated infrastructure. Multiple deployments may belong to one organization. Every service, version and operation needs qualification; an upstream API or MCP server is not proof of a working Service Planet connection.
Planned public-cloud coverage
Microsoft Azure
The initial qualification recommendation for read-only inventory, topology and cost evidence. Subscriptions, services, billing arrangements and permissions must be validated; later management and monitoring need their own supported scope.
Amazon Web Services
A planned coverage target across services. Account structure, resource relationships, billing evidence and individual operations require validation; broad AWS support is not a launch promise.
Google Cloud
A planned coverage target across services. Asset inventory, topology and billing may use different sources and permissions. Coverage, freshness and each management or monitoring operation need validation.
Microsoft 365: planned, separately qualified tenant, service and licensing or cost scope. Azure coverage would not establish Microsoft 365 support.
Google Workspace: planned, separately qualified tenant, service and licensing or cost scope. Google Cloud coverage would not establish Workspace support. No production integration availability is announced.
Dedicated servers and infrastructure technologies
OS-installed agents would extend coverage to qualified dedicated, data-center and cloud-hosted Windows or Linux servers. Read-only collection is the recommended starting point. Docker, Kubernetes, applications, databases and patch/update operations need version-specific checks. Networking, load balancers and firewalls need vendor and operation qualification; an agent alone does not cover every device or physical asset.
Private-cloud provisioning and migration between cloud or dedicated environments belong to the planned execution lifecycle, after separate qualification. Each plan must assess compatibility, dependencies, data consistency and movement, licensing, downtime, egress and parallel-run costs, cutover and recovery. A collector installation is not provisioning, and no universal automated migration is promised.
Web and mobile clients, separate from backend and agents
Planned web, iOS and Android management clients would share governed APIs, permissions, approval rules and audit. They are separate from the deployable backend/control plane and OS agents. The backend may use qualified provider APIs or MCP adapters; external AI clients are optional and individually tested. Control-plane hosting does not determine workload placement. No mobile app or app-store availability is announced.
What each qualified integration must document
- Status, supported versions and last verification date; current targets are all planned
- Supported discovery, inventory, topology, assessment, execution and verification scope, including cost or licensing evidence
- Required permissions, collection limits, freshness and qualified monitoring signals; notifications and alert settings remain tentative
- Authentication, revocation and any separately qualified external AI client surfaces
- Read-only collection and per-platform patch/update coverage, plus approval, fresh-state checks, outcome verification and recovery limits for each later operation