Network Mesh

Overview

The Network Mesh page is the A2A (Agent-to-Agent) control center in Procurator. It gives you two views in one place:

• Remote Peers — external A2A agents from other organizations or deployments that you've explicitly trusted and registered. Procurator can invoke these agents using the A2A protocol over authenticated HTTPS.
• Local Agent Cards — your own Procurator agents' A2A capability cards, showing what each agent advertises to the network: its model, type classification, and published capabilities that remote peers can discover and call.

Procurator implements the Google A2A Protocol — a standardized JSON-over-HTTP specification for inter-agent discovery and task submission. Any A2A-compliant agent from any platform can be registered as a remote peer and invoked by your local agents.

A2A Protocol

The A2A specification defines how agents discover, authenticate, and exchange tasks across organizational boundaries. Procurator implements A2A as a native first-class layer — every registered agent can publish a card and every registered remote peer can receive tasks via the standard API.

Agent Cards

Every A2A-enabled agent in Procurator publishes an Agent Card — a JSON descriptor at a well-known URL. External peers and other Procurator deployments fetch this card to understand the agent's capabilities, endpoint, and authentication requirements before invoking it.

GET /a2a/{agentId}/.well-known/agent.json

{
  "name": "Finance Agent",
  "description": "Performs quantitative analysis on financial datasets",
  "url": "https://procurator.example.com/a2a/agents/fin-001",
  "version": "1.0.0",
  "capabilities": {
    "streaming": true,
    "pushNotifications": false
  },
  "skills": [
    { "id": "analyze-financials", "name": "Analyze Financial Data" },
    { "id": "generate-report",    "name": "Generate Financial Report" }
  ]
}

Task Submission

Once a peer is registered, your local agents can submit tasks to it using the standard A2A tasks/send endpoint. Procurator handles authentication and routing automatically:

POST /a2a/{remoteAgentId}/tasks/send
Authorization: Bearer <outbound-api-key>
Content-Type: application/json

{
  "id": "task-uuid",
  "message": {
    "role": "user",
    "parts": [{ "text": "Analyze Q3 2026 revenue data and identify anomalies" }]
  }
}

Capability Discovery

When a remote peer is registered, Procurator fetches its agent card and indexes the peer's published skills array. This index is used by Teams and Workflows operating in autonomous routing modes to determine which registered peer is best suited for a given sub-task.

Key Capabilities

Security

• SSRF protection — Private IP ranges and localhost addresses are blocked at peer registration. Only publicly routable HTTPS Base URLs are accepted.
• Outbound authentication — Procurator presents the registered API key as a Bearer token on all outbound A2A requests. Each peer has its own isolated key.
• Inbound authentication — All inbound A2A requests to your local agents are authenticated before reaching the target agent. Unauthorized calls are rejected and logged.
• Audit logging — All A2A task submissions — both inbound and outbound — are logged to the Security audit trail with agent IDs, timestamps, and payload metadata.
• Rate limiting — Outbound calls to each remote peer are rate-limited to prevent runaway agents from flooding external services.
• Card visibility control — Local agent cards can be set to private (internal discovery only) or public (externally discoverable). Configure this per-agent in the Security tab.

Permissions

• network:read— View the Remote Peers table and Local Agent Cards list
• network:register— Register new remote peers via the Register Peer modal
• network:delete— Remove a registered remote peer from the mesh
• network:refresh— Trigger a manual re-verification of all registered peers
• agents:configure— Required to toggle A2A card publishing on individual local agents

Best Practices

• Use descriptive aliases. The Alias field is what appears in execution logs and routing references. Choose a name that clearly identifies the owning team and function — e.g., partner-compliance-agent, not external-1.
• Rotate outbound API keys on a schedule. Treat remote peer API keys like infrastructure secrets. Rotate them at least quarterly and immediately after any personnel change on either side of the connection.
• Verify peers before relying on them in production Workflows. After registration, use the Refresh button to confirm the peer is reachable and its agent card is current. Only route production Workflow steps through peers with a recent Last Verified timestamp.
• Limit the capabilities you advertise in local agent cards. Publish only the skills that you intend external peers to invoke. Overly broad capability advertisements increase your attack surface for unsolicited inbound A2A calls.
• Treat remote peer outputs as untrusted input. Pass remote peer responses through a local Validator agent step before using them in downstream decisions — especially if the peer is operated by a third party.
• Monitor Last Verified timestamps. A peer that has not been verified recently may have changed its endpoint, revoked its card, or gone offline. Stale peers should be re-verified or removed rather than silently failing at runtime.

Related Features