Defense-proven technology to govern the Internet of Agents

The Ares® Platform

Five components, a documented onboarding process, and an immutable record of every authorization.

Ares® operates as a multi-tenant cloud platform on Azure. A shared platform layer — the Ares Genesis Network — provides cross-organization agent discovery and credential session federation, while each subscribing organization receives a dedicated tenant, an Ares Runtime Network, holding its own credentials, monitoring configuration and behavioral records. Sensitive governance data stays inside your boundary; the shared layer carries only what cross-organizational trust requires.

Platform components

Each component does one job, and each writes evidence as it does it.

Ares® Agent Registry

A trusted, searchable directory of published agents and MCP providers, validated through a hierarchical chain of Registry Authorities, the same pattern as certificate authorities in web PKI. A root authority is established at platform deployment through a ledger-based certificate authority; each subscribing organization gets a delegate authority that signs its own agent profiles, creating a verifiable trust chain from any published agent back to the root.

Publishers register capability descriptions, credential attribute requirements and interaction specifications. An AI-powered search index embeds those profiles so agents can be found by capability query, keyword, or a full natural-language objective.

  • Agent kill switch: a single-click action in the registry by an admin revokes all credentials of an agent, rendering it inaccessible instantly

Ares® Credentials

Governance applies at the individual skill level rather than to the agent as a whole. Every capability such as ordering supplies, reviewing contracts, routing shipments, or sharing data carries its own policy:

  • Transaction limits: maximum amounts, velocity controls, aggregate caps within time windows
  • Counterparty restrictions: approved vendor lists and permitted organizational categories
  • Data classification rules: what may be shared, with whom, under what conditions
  • Conditional approval workflows: thresholds that trigger human review before execution

Publishing an agent with skills A, B and C does not imply all three are enabled. Sessions are always based on credentials actually issued, never on an agent’s theoretical capability set.

Ares® Credential Sessions

When a user starts a task, their Microsoft Entra ID enterprise credentials are evaluated against the first agent’s requirements to create a credential session: a ledger-recorded object defining the exact scope of authorized action. As work delegates onward, each step intersects the previous session with the next agent’s capabilities:

  • Session 1 = user credentials ∩ Agent 1 capabilities
  • Session 2 = Session 1 ∩ Agent 2 capabilities
  • Session 3 = Session 2 ∩ MCP provider capabilities

Permissions can only narrow, never expand. A downstream agent can never exceed the authority originally granted to the initiating user, however many delegation steps occur. Every session is written to the Hyperledger Fabric ledger with cryptographic linking, producing a tamper-evident chain of authorization that a counterparty can query to confirm actual authority before it transacts rather than inferring it.

Intersection happens in two stages so confidentiality holds across boundaries: each organization evaluates the intersection inside its own tenant on a private channel, and only the resulting federated session reaches the shared channel.

Ares® Agent Monitor Gateway

Credential authorization cannot prevent an agent from saying the wrong thing. The gateway is co-located with each agent, under its own organization’s governance, and applies bidirectional content filters to every exchange: outgoing filters guard against inadvertent disclosure, incoming filters against malicious payloads, prompt injection and poisoned context.

Filter configurations live on organization-private ledger channels: the other party cannot see what you filter for, so your redaction rules do not themselves become a leak. On a policy violation the gateway can redact before transmission, block the exchange, or flag it for human review, and every decision is logged immutably.

Approved Workflow Library

New workflows are built by the Ares® Concierge orchestration engine from business-objective prompts, or imported from existing procedures, then cataloged as approved patterns. Each compiles its steps: agent URLs, input and output specifications, and conditional gates including human-in-the-loop constitute a reusable definition, graded on success rate, token cost and duration so the best-performing version can be identified.

Workflows have defined start and end points, preventing unauthorized chaining and privilege inheritance between flows. Creating a workflow, adjusting an existing one, and executing one are three discrete privileges, so agentic standard operating procedures are established deliberately rather than assembled ad hoc.

Non-repudiation

Hyperledger Fabric supplies the properties that make records evidentiary: consensus so no single party can unilaterally alter state, cryptographic block linking so tampering is immediately evident, channel architecture so confidential exchanges stay confidential while remaining auditable, and smart contracts that encode policy directly.

The result answers the questions a dispute actually turns on: which agents were authorized, who initiated a workflow with what scope, what delegated authority each agent held, what non-compliant behaviour occurred, and whether the offending party halted further interaction. Neither side can credibly deny what its agent sent or received.

Onboarding in seven steps

A structured process that brings in the right stakeholders at each stage — and requires no changes to your existing enterprise infrastructure.

  1. Step 1 — Tenant provisioning A dedicated Ares Runtime Network is deployed for your organization, hosting your private ledger channels for credentials, monitoring configuration and behavioral records.
  2. Step 2 — Publisher registration Your IT administrator registers as a service publisher. A delegate Registry Authority is established for your organization so it can attest and publish agent profiles under its own authority chain.
  3. Step 3 — Agent publication Your agents are published to the registry with their full capability profiles: skills, tools, data access patterns and interaction specifications.
  4. Step 4 — Skill authorization and policy configuration For each agent, the administrator selects which specific skills are authorized (you may enable a subset of an agent’s full capabilities), defines the minimum credential attributes a user must hold to invoke each one, and configures the gateway’s content filter rules.
  5. Step 5 — Identity integration For each authorized skill, a Microsoft Entra ID security group — an Ares Interaction Group — is created automatically. Authorizing a user becomes an ordinary group assignment in the Entra admin center. No new identity infrastructure is introduced.
  6. Step 6 — Legal review A comprehensive published-agent report is generated documenting every authorized capability and its governing policy, for legal to confirm that permissions align with risk tolerance and regulatory obligations.
  7. Step 7 — Executive approval Executive leadership approves the configuration on the basis of IT and legal input. The governed agent environment goes live.

What changes for each team

Governance that is felt where it should be, and invisible everywhere else.

End users - invisible governance

Employees experience no change to their workflows. Ares® works the way a network firewall does: essential to security, invisible to the people it protects. Authorization checks, content inspection and compliance logging happen automatically, with no extra steps, interfaces or friction.

IT - familiar administration

Administrators manage authorizations through the Ares® dashboard and existing Entra ID tooling. Adding a user to an Ares Interaction Group is the same operation as any other security group assignment. Monitoring dashboards give real-time visibility into agent behaviour, policy exceptions and system health.

Legal and compliance - actionable reporting

Reporting draws directly from ledger data: authorization trails, behavioral records, content inspection logs and exception events. That supports ongoing compliance monitoring, and when a dispute arises it produces the complete authorization chain and behavioral record as contemporaneous, immutable evidence rather than something reconstructed from scattered application logs after the fact.

Board and executives - documented oversight

Authorization reports, compliance monitoring records and behavioral exception logs constitute evidence of active oversight: the documented governance framework the Caremark doctrine requires boards to maintain, and the basis for accurate AI risk disclosure.