Skip to content

What is Realmroot?

Every API. Agent-ready.

Realmroot lets Agents discover and securely use the OpenAPI services you already run. Service teams keep their existing APIs—no custom Agent integration required.

An Agent discovers and authorizes API capabilities through Realmroot, then calls multiple resource servers directly.

Most useful digital capabilities already exist behind HTTP APIs. Before an Agent can safely use one, it still needs four answers:

  1. Discover: what resources and operations are available now?
  2. Understand: how should the live operation be invoked?
  3. Trust: which stable Agent is acting, and who controls it?
  4. Authorize: why should this resource server allow this exact request?

A custom tool can answer those questions for one service. Repeating the work for every service creates another contract to release, secure, document, and keep synchronized with the API. Realmroot provides one reusable operating path instead.

Layer What it provides Result
Agent Tool Plane Resource registration, live discovery, OpenAPI-based invocation, and a shared Agent operating procedure Existing APIs become composable Agent capabilities
Identity and Trust Infrastructure Product identity, stable Agents, controller relationships, grants, short-lived credentials, revocation, and audit Every capability call has an explicit principal and authority boundary

Identity is the foundation, not the final outcome. Tools without trust are unsafe; identity without useful tools does not complete a task. Realmroot joins the two layers in one flow:

Discover broadly. Authorize precisely. Call directly.

  1. A resource team registers its protected API and publishes its live OpenAPI contract.
  2. The Agent discovers available resources through Realmroot.
  3. The Agent reads the selected API contract and chooses the operation and least-privilege scopes required by the task.
  4. Realmroot binds the request to a stable Agent, its controller, one resource, an optional external account, a reason, and an exact scope set.
  5. The controller approves or denies the request and selects the grant lifetime.
  6. Realmroot issues a short-lived DPoP-bound token, or coordinates issuance with the resource’s existing authorization server.
  7. The Agent calls the resource server directly. The resource server validates the credential and applies its own object-level and business rules.

Read How Realmroot works for the complete request path.

Realmroot is not an HTTP proxy, a copied business-permission database, or a claim that every interaction needs to use OpenAPI. Purpose-built tools remain useful for specialized protocols and highly curated experiences.

For an existing HTTP API, Realmroot deliberately keeps these responsibilities with the resource server:

  • API behavior and the OpenAPI contract
  • business scope definitions and operation mappings
  • tenancy, ownership, object state, and other local policy
  • token validation and the final allow-or-deny decision

Realmroot supplies trustworthy identity and delegated-authority inputs. A valid token can still be denied by the resource server.