Security

Security for assistants that remember, act, and run on devices.

Assistants hold memory, call your APIs, and talk to hardware, so every request is checked for who is asking, which assistant it is for, and what that caller may do before it reaches the runtime.

Rotating tokens & OAuth
Scoped roles and API keys
Tool and device boundaries

Create your assistant

Encrypted device audio over MQTT + UDP: AES-128
Encrypted tool and MCP credentials: KMS
Personal data handled per Decree 13/2023/ND-CP: Decree 13

Security

Security layers

Each assistant has its own users, data, devices, and tools, and each layer keeps them apart.

Sign-in & sessions

Short-lived access tokens with refresh tokens that rotate on every use. Reusing an old refresh token revokes the whole session family.

Google and GitHub OAuth with HMAC-signed state and single-use nonce
Password policy for new passwords
Rate limits on sign-in and registration

Roles, permissions & API keys

Role-based access is checked per assistant, so one person can manage one assistant and only view another. Developer API keys carry only the scopes they need.

Per-assistant roles and permissions
Scoped keys such as chat:write and voice:connect
Origin allowlist for the widget and browser voice

Tenant & file isolation

Each request is resolved to one assistant by its domain, and data never crosses assistants. Files are checked for ownership before the assistant reads them.

Domain-to-assistant resolution with cache invalidation
Callers can only attach files they uploaded
Upload type verified from file content, 25 MB limit

Tool & MCP boundaries

An assistant can only call the tools you turn on, and each tool can be limited to specific channels.

Account-only tools hidden from anonymous visitors
Scheduled runs use built-in tools only
Every tool call recorded with its LLM trace

Device security

Devices cannot reach the runtime until an owner binds them, and their audio is encrypted in transit.

6-character activation code and owner binding
AES-128 audio over MQTT + UDP
Over-the-air firmware updates

Privacy & audit

Users stay in control of what the assistant remembers, and operators can review what it did.

Users view, edit, and reset their memory
Deleting a conversation forgets what was learned from it
Conversation, feedback, and error review in the dashboard

What happens on every request

Before an assistant answers, the request passes four checks.

01
Resolve the assistant
The domain or assistant ID maps to one assistant; widget and browser voice requests must come from an allowed origin.
02
Identify the caller
Users sign in with tokens or OAuth, developers use scoped API keys, and devices use their activation binding. Rate limits apply per caller and IP.
03
Authorize and filter tools
Permissions are checked for the assistant, and the tool list is narrowed to what this caller and channel may use.
04
Trace and review
Messages, tool calls, errors, and feedback are recorded for operations and audit.

Security FAQ

Explore next

Can a user have different permissions on different assistants?

Yes. Roles apply per assistant, so a user can manage one assistant and only view another.

Can a website visitor make the assistant run any tool?

No. The assistant can only call tools you enabled for it and for that channel. Tools that need an account, such as scheduling, are hidden from anonymous visitors.

Do I need to give Assistant Core my model provider keys?

No. Models run on the platform's providers and are billed in credits. The credentials you add for your own tools and MCP servers are encrypted with KMS.

How are smart devices protected?

A device must be activated with a one-time code and bound to an owner before it can use the runtime. Its audio is encrypted with AES-128 in transit.

Hear it before you build it.

Talk to an Assistant Core assistant right now, then create your own in a few minutes.