Skip to content

Security & tenancy

braXos Maestro is a multi-tenant gateway with server-side isolation. This page explains how authentication, organization isolation, and authorization work - the model that lets many organizations share one gateway safely.

Identity and sign-in

  • Connections authenticate with OAuth 2.0 against the braXos identity service (Keycloak). You sign in as yourself, through your organization's identity provider where single sign-on is configured.
  • No API keys are pasted into the client, and no user credentials are stored client-side.

Organizations and isolation

braXos runs a single shared identity realm in which each tenant is a Keycloak Organization. Your organization membership is derived server-side from your authenticated identity - the client cannot assert or switch it.

  • Every request is scoped to your organization only. You cannot see or act on another organization's data.
  • Isolation is enforced on the server, not by the client or by tool arguments.

Authorization

  • The tools you can see and call are filtered by your group memberships (an allow-list per resource).
  • Tools are annotated read-only, write, or destructive; clients use these hints to decide what to gate. The hints are advisory for UX - actual authorization is always enforced server-side, per tool, per caller.

Downstream credentials

Credentials for the systems Maestro fronts are held and applied server-side. They are never exposed to the model, the client, or the pipeline spec. Where a downstream system supports it, operations run with the caller's own permissions so that system's native access controls also apply; where it does not, access is scoped at the gateway by group and by curated fine-grained services.

Data handling

  • braXos proxies your organization's own systems on your behalf; it is not a third-party data broker, and it does not sell or share your data.
  • braXos processes your data only to fulfill the request you make through the gateway. The connected systems remain your systems of record; Maestro is a governed conduit to them.
  • Multi-step work can run as a transient pipeline on the on-prem sidecar, so records flow system-to-system without returning to the model - only the requested result does.
  • Every call is authenticated, authorized, and audited (see below).

Audit logging

Every gateway action is recorded to an append-only audit log, independent of the client:

  • What is recorded. Per tool call: the authenticated caller, their organization, the resource and operation invoked, the authorization decision (allowed, or denied with the gate and reason), and a timestamp. Transient pipelines additionally record a pipeline_step entry per step and a pipeline_run entry for the overall outcome (with the record count and whether the result was truncated).
  • What is not recorded. The audit log captures that an operation ran and who ran it - it is an access trail, not a copy of the business data that flowed through it.
  • Where. In the split deployment, tool-level records are written by the cloud relay (where the caller authenticates) and per-step records by the on-prem sidecar (where the work executes), so each node audits what it does.
  • Retention. Audit records persist in the running system and are covered by the platform's backup and retention policy (see Backup & recovery below); they are available to your organization's administrators on request.

Data residency

  • Downstream record data stays where your systems are. When a request runs as a transient pipeline, records are read, transformed, and written in-process on the on-prem Composer sidecar inside your environment; they are not staged in the cloud.
  • The cloud gateway (authentication, authorization, and tool projection) runs in the braXos cloud in Azure US East (Azure region East US). Because the relay never holds downstream credentials or the intermediate records of a pipeline, it transports work it cannot itself read.
  • Identity is handled by the braXos identity service (Keycloak); no downstream credentials or user passwords are stored in the MCP client.

Backup & recovery

The braXos cloud is backed up on the following schedule (all times UTC):

  • Instant-restore snapshots - retained for 2 days.
  • Daily backup - taken every day at 3:30 AM UTC, retained for 30 days.
  • Monthly backup - taken on the last day of each month at 3:30 AM UTC, retained for 12 months.

Privacy

braXos's handling of personal data is described in the braXos Privacy Notice, which covers what is collected, how it is used, and the rights available to data subjects.