Security & multi-tenancy

Multi-tenancy isn't a setting in Mirakash; it's the architecture. Role-based permissions gate every action, org data is scoped server-side on every query, and any credential you bring — Twilio auth tokens, provider API keys — is encrypted at rest with AES-256-GCM and never logged.

app.mirakash.com/settings/access
Settings /Access control
N
RolesMembersAudit log
Roleagentsnumbersconvosknowledgeconnectorskeys
owner
workspace · full access
admin
manage · no key export
builder
build agents + tools
reviewer
QA · read + score
enforced server-side · signed session on every request · RBAC checked per call
The problem

Multi-tenant leaks are one forgotten WHERE clause away

In most systems, isolation is a filter someone remembers to add in the UI. Miss it once and one workspace sees another's calls, numbers, or customers. Bolted-on RBAC and plaintext provider keys make it worse.

How it works

The flow, end to end

01

Authenticate

A request carries a Firebase-verified actor — user or machine — with a role and an org.

02

Authorize

The route's permission guard runs before the handler; no permission, no entry.

03

Scope

The service scopes every org query to the actor's workspace; admins may scope explicitly.

04

Protect

Any stored credential is encrypted; any external host must be verified to resolve.

Capabilities

What's in the box

Role-based access

Every route is guarded by a permission; the UI gates nav and actions on the same permission set.

Firebase auth

Sign-in runs on Firebase; each request carries a verified actor with a role and an org.

Server-side scoping

Org queries are scoped to the caller's workspace in the data layer — not trusted from the client.

Encrypted BYO credentials

Any credential you bring is AES-256-GCM encrypted at rest, masked on return, never logged.

Isolation by construction

Cross-org access throws by construction; a workspace can never reach another's resource.

Isolation by construction

The safe path is the only path

Scoping and ownership checks live in shared helpers every service calls, so isolation isn't a thing you remember — it's the default. External callers are pinned to their own org; admins get explicit, audited cross-workspace reach.

  • One scoping helper, called on every org-scoped read
  • Ownership assertion throws on any cross-org access
  • Secrets encrypted at rest, masked on return, absent from logs
app.mirakash.com/settings/access
Settings /Access control
N
RolesMembersAudit log
Roleagentsnumbersconvosknowledgeconnectorskeys
owner
workspace · full access
admin
manage · no key export
builder
build agents + tools
reviewer
QA · read + score
enforced server-side · signed session on every request · RBAC checked per call
Bring your own credentials

Credentials that are usable in memory and opaque everywhere else

When you bring a Twilio auth token, provider API key, or OAuth token, Mirakash encrypts it with AES-256-GCM at rest, decrypts it only in-process at the moment of use, masks it on every read, and keeps it out of logs entirely. The plaintext never lingers beyond the instant it's needed.

  • AES-256-GCM encryption for every stored credential
  • Masked on return; never rendered or logged in plaintext
  • Decrypted only in-process, at the moment of use
app.mirakash.com/settings/access
Settings /Access control
N
RolesMembersAudit log
Roleagentsnumbersconvosknowledgeconnectorskeys
owner
workspace · full access
admin
manage · no key export
builder
build agents + tools
reviewer
QA · read + score
enforced server-side · signed session on every request · RBAC checked per call
AES-256
GCM for every stored credential
0
trust placed in client-supplied scope
1
scoping helper on every org-scoped read
100%
of routes behind a permission guard

Ready to put an AI agent on every call?

Book a walkthrough and see the voice pipeline, telephony, workflows, QA, and human handoff working together — on one platform.