For Agents
Define managed networks, group memberships, scope assignments, and peering policies for centralised Azure VNet topology management. Use for managed network configuration, not for VNet creation or per-NIC operations.
Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the ManagedNetworkManagementClient, or any other public or private API you need. You set the rules, the agent never sees your credentials, and every call is logged.
# On the machine that will host your Jentic One instance:
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh# On the machine where your agent runs (keep this separate from the instance):
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh
jentic register # connects your agent to your Jentic One instanceJentic One is in public beta. The setup above keeps your agent separate from the instance, which is what you want before using real credentials: an agent running as the same OS user as Jentic One can read its stored keys directly. Just evaluating? A single local install is fine to start. See the secure deployment guide for the tiers.
What an agent can do with ManagedNetworkManagementClient API.
Create and manage ManagedNetwork resources that group VNets and scopes under one boundary
Define ManagedNetworkGroups that collect virtual networks for shared connectivity rules
Configure ManagedNetworkPeeringPolicies that automate hub-and-spoke or mesh peering
Apply ScopeAssignments that bind a managed network to a subscription or management group
GET STARTED
Use for: Create a managed network that groups all production VNets under one peering policy, Add a list of VNets to the 'prod-spokes' managed network group, Apply a hub-and-spoke peering policy to the 'prod-network' managed network, List all managed networks in my subscription
Not supported: Does not create virtual networks, subnets, or network interfaces, and does not manage Azure Firewall or NSG rules — use only for Microsoft.ManagedNetwork grouping, peering policy, and scope assignment resources.
Jentic publishes the only available OpenAPI document for ManagedNetworkManagementClient, keeping it validated and agent-ready.
Jentic publishes the only available OpenAPI specification for ManagedNetworkManagementClient, keeping it validated and agent-ready. ManagedNetworkManagementClient is the Azure Resource Manager surface for the Microsoft.ManagedNetwork provider — Azure Virtual Network Manager's managed network construct. It defines a managed network that groups virtual networks, subscriptions, or management groups under one connectivity boundary, and manages the groups, scope assignments, and peering policies inside it.
List managed networks across a subscription or resource group
Update peering policies to change topology between hub-spoke and mesh
Patterns agents use ManagedNetworkManagementClient API for, with concrete tasks.
★ Centralised Hub-and-Spoke Topology
Enterprises with dozens of VNets across business units use ManagedNetworkManagementClient to declare a hub VNet and spoke groups, then attach a peering policy that produces the right peerings automatically. New VNets added to a spoke group inherit peering without per-VNet configuration. This replaces hand-maintained peering scripts with a declarative ARM resource graph.
Create managed network 'prod-network', a ManagedNetworkGroup 'spokes' containing 12 spoke VNet IDs, and a ManagedNetworkPeeringPolicy of type HubAndSpokeTopology with the hub VNet ID, then verify the peerings appear under each VNet.
Scope-Driven Network Governance
Cloud platform teams attach a managed network to a subscription or management group via ScopeAssignment so that any VNet created under that scope is governed by the managed network's policies. This shifts VNet connectivity policy from a per-resource concern to a platform concern, simplifying landing zone enforcement.
Create a ScopeAssignment that attaches managed network 'prod-network' to the 'prod-mg' management group, then list ScopeAssignments to confirm the binding exists.
Topology Migration from Mesh to Hub-Spoke
Operations teams reducing east-west traffic costs migrate a fully meshed VNet group to a hub-and-spoke topology. Updating the ManagedNetworkPeeringPolicy from Mesh to HubAndSpokeTopology causes Azure to remove the redundant peerings and create the hub-routed ones. The migration is declarative and auditable through ARM activity logs.
PATCH the peering policy 'prod-policy' on managed network 'prod-network' to set type=HubAndSpokeTopology with the chosen hub VNet ID, then list peerings on each spoke to verify the new topology.
AI Agent Network Topology Operations
Network platform agents use Jentic to discover managed network operations on demand. Searching for 'apply azure peering policy' returns the matching ManagedNetworkPeeringPolicies operation; the agent loads the schema and executes against management.azure.com using a token from the Jentic vault, so topology automation does not require bundling the Network Manager SDK.
Use Jentic to search 'create azure managed network peering policy', load the ManagedNetworkPeeringPolicies_CreateOrUpdate schema, and PUT the policy with the requested topology and hub VNet ID.
19 endpoints — jentic publishes the only available openapi specification for managednetworkmanagementclient, keeping it validated and agent-ready.
METHOD
PATH
DESCRIPTION
/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.ManagedNetwork/managedNetworks/{managedNetworkName}
Create or update a managed network
/subscriptions/{subscriptionId}/providers/Microsoft.ManagedNetwork/managedNetworks
List managed networks in a subscription
/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.ManagedNetwork/managedNetworks/{managedNetworkName}
Delete a managed network
/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.ManagedNetwork/managedNetworks/{managedNetworkName}/managedNetworkGroups
List groups inside a managed network
/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.ManagedNetwork/managedNetworks/{managedNetworkName}
Update a managed network
/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.ManagedNetwork/managedNetworks/{managedNetworkName}
Create or update a managed network
/subscriptions/{subscriptionId}/providers/Microsoft.ManagedNetwork/managedNetworks
List managed networks in a subscription
/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.ManagedNetwork/managedNetworks/{managedNetworkName}
Delete a managed network
/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.ManagedNetwork/managedNetworks/{managedNetworkName}/managedNetworkGroups
List groups inside a managed network
/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.ManagedNetwork/managedNetworks/{managedNetworkName}
Three things that make agents converge on Jentic-routed access.
Credential isolation
AAD client credentials are encrypted in the Jentic vault. Agents receive only short-lived bearer tokens scoped to https://management.azure.com/ at call time — the AAD secret never enters agent context.
Intent-based discovery
Agents search by intent (for example, 'apply hub and spoke peering policy') and Jentic returns the matching ManagedNetworkPeeringPolicies operation with its full schema, so the agent calls the correct endpoint without consulting Microsoft Docs.
Time to first call
Direct ARM integration: 2-3 days for AAD setup, async polling for peering reconciliation, and topology validation. Through Jentic: under 1 hour — search, load schema, execute.
Alternatives and complements available in the Jentic catalogue.
NetworkManagementClient
The full Microsoft.Network surface for VNets, subnets, NICs, and load balancers.
Use when the task is creating VNets, subnets, or NICs themselves rather than managing the higher-level grouping.
PolicyClient
Enforce that VNets must be members of a managed network as a compliance policy.
Use when wrapping managed network membership into Azure Policy assignments.
MonitorManagementClient
Configure diagnostic settings on managed networks for activity log collection.
Use to surface managed network configuration changes into Log Analytics.
Specific to using ManagedNetworkManagementClient API through Jentic.
Why is there no official OpenAPI spec for ManagedNetworkManagementClient?
Microsoft Azure does not publish an OpenAPI specification. Jentic generates and maintains this spec so that AI agents and developers can call ManagedNetworkManagementClient via structured tooling. It is validated against the live API and kept up to date. Get started at https://app.jentic.com/sign-up.
What authentication does the ManagedNetworkManagementClient use?
AAD OAuth 2.0 bearer tokens scoped to https://management.azure.com/. With Jentic, AAD client credentials are stored encrypted in the vault and a short-lived bearer token is injected at call time.
Does this API create virtual networks?
No. Virtual network creation, subnet management, and per-NIC operations live in the Microsoft.Network provider (NetworkManagementClient). This client manages the higher-level managed network grouping and peering policy resources only.
What are the rate limits for the ManagedNetworkManagementClient?
Standard Azure Resource Manager throttling: typically 12,000 reads and 1,200 writes per hour per subscription per region. PeeringPolicies operations are asynchronous when they trigger downstream peering changes and return 202 Accepted with an Azure-AsyncOperation URL to poll.
How do I apply a hub-and-spoke topology through Jentic?
Run pip install jentic, then search Jentic for 'create azure managed network peering policy'. Jentic returns the ManagedNetworkPeeringPolicies_CreateOrUpdate schema; load it, set type=HubAndSpokeTopology with the hub VNet ID and spoke group IDs, and PUT to /managedNetworks/{managedNetworkName}/managedNetworkPeeringPolicies/{policyName}.
What peering policy types are supported?
The peering policy resource accepts type values such as HubAndSpokeTopology and Mesh, with the chosen hub VNet and spoke groups supplied for hub-and-spoke configurations. Switching between types is a PATCH on the policy resource and triggers Azure to reconcile peerings automatically.
Update a managed network