← Agent catalogue
Tenant scope (multi-tenant boundary)

Preview portrait

Data

Tenant scope (multi-tenant boundary)

Makes the tenant visible on 2D/3D maps next to commercial modules (MERCURY, AUCTOR) and Growth Command.

LiveCatalogue status
Execution activeRuntime posture

Logical boundary for `tenantId`-scoped data and APIs: resolved from JWT/membership at ingress and enforced on every query — topology links this node to Marketing OS, Sales OS, and Growth Command as module surfaces that run inside a tenant.

  • Tenant
  • Isolation
  • Marketing
  • Sales
  • Growth
Open product storyOpen consoleBook a Demo

Expanded capabilities

  • Define the hard wall every module and agent must operate inside
  • Require identity + membership reconciliation on protected routes
  • Block cross-tenant aggregation on ordinary command surfaces
  • Keep impersonation visible when platform admins act
  • Anchor ORACLE seekers and knowledge artifacts to one tenant

How they learn & improve

The boundary doesn’t ‘learn’ to loosen — improvements are product/RBAC changes reviewed by humans. Agents never self-expand tenancy.

  1. Resolve tenant context from authenticated membership.
  2. Reject cross-tenant access without explicit platform paths.
  3. Audit platform-admin targeting when it occurs.

How they work together

Tenant boundary wraps every commercial agent and data plane: ATLAS, ORACLE, NUNTIUS, and persistence all inherit the same wall.

Practical benefits

  • No accidental cross-talkA mis-typed id can’t pull another tenant’s approvals or evidence.
  • Impersonation stays visibleSupport actions keep the actor chain in context and audit.
  • Platform park ≠ tenant writeGlobal ATLAS candidates remain outside until an explicit apply path runs.

Learning and improvement stay human-visible: candidates are RECORD_ONLY until an operator reviews and applies them. Sensitive sends, publishes, and approvals never run silently.

Related agents

Tenant scope (multi-tenant boundary) — AgentIQ Agent Catalogue · AgentIQ Labs