What the platform actually ships today.

Every Tenant has a mandatory `brandId` foreign key. Brand-Owner role admins a Brand and every Tenant under it without ever seeing sibling Brands, even when they share the same VPS.

Per-Brand secrets vault (AES-256-GCM, scoped by `brandId`) means an LLM key leak on one Brand cannot bleed into another. Same primitive for OAuth client secrets, Slack tokens, Teams bot creds.

Brand offboarding is a 30-day soft-delete window with a one-click export of every audit row, tenant config, KB file, and secret reference.

Every Brand picks one IdP at onboarding. The Brand-Owner pastes the public OIDC config (tenant id, client id, hosted-domain or audience as required), then their downstream end-users sign in straight to their own provider with PKCE. No Aroovo identity is required at any level.

A reseller serving a Workspace-native customer signs them in on Google. A reseller serving an Okta shop signs them in on Okta. A Salesforce-shop customer is the only one Aroovo can't serve cleanly today, and even there the contact form lands in the same flow.

Brand-Owner pastes their provider API key into the Brand settings; the encrypted-secrets vault holds it under a brand-scoped row. From that moment, every Tenant under that Brand transparently sends Messages API calls signed with the Brand's key — no Aroovo proxying, no Aroovo-fronted margin.

OpenClaw integration (the open Anthropic-compatible API) lets a Brand sidestep first-party Anthropic billing entirely. Same for OpenRouter, which exposes ~150 models across providers behind one key.

Provider-quota errors surface to the Brand-Owner in the admin console — no silent fail, no support ticket roulette.

Teams: per-Brand Azure Bot Service registration. Each Brand registers their own Bot Channel + Entra app, drops the credentials into Aroovo, and their customer sees the Brand's bot in their Teams workspace — not a generic shared bot.

Slack: per-Brand Slack App with channel-to-Tenant mapping. One Slack workspace can host bots for multiple Brand-customers if needed; channel-level isolation keeps the conversations separate.

Multi-channel doesn't mean lowest common denominator — the agent runtime uses an Ingress interface that each channel implements, so adding Discord (planned) is the same shape, not a rewrite.

Agents call tools through Anthropic's Model Context Protocol — a 6,000+-tool surface via Zapier MCP plus any custom MCP server you point Aroovo at. Per-agent tool allowlists scope what a given persona can invoke.

Every tool defines whether it gates: zero gates (a read-only lookup), single approval (a Brand-Owner clicks approve), or dual approval (two operators sign off, defaults required for destructive actions). Operators see the queue in the console; high-risk actions never auto-execute.

MCP runtime treats each MCP server as a URL — swap Zapier for Composio, Cloudflare, or your own stack without an agent rebuild.

Every tool call, config change, role change, secret rotation, approval resolution, trigger fire, and sign-in writes an `AuditEntry` row. Rows are chained: each row stores the HMAC of (its content + the previous row's hash), keyed by a per-deployment secret only the operator holds.

A `verifyChain()` job can be run anytime to detect tampering — a deleted or modified row will fail the recomputed HMAC at the breakpoint. The chain is per-Tenant, so one Tenant's tamper detection is independent of another's.

Rate-limit + spend cap + PII redaction sit alongside as defence in depth — the audit row is the source of truth; the rest is friction at the entry point.