Security overview

RAUM AI Assistant handles support data, AI-provider credentials, Zendesk credentials, and external-system connections. Its security model is built around keeping those concerns separated and making risky operations explicit. This page describes the current product architecture at a customer-help-center level. For contractual/privacy terms, use RAUM’s published legal and privacy materials rather than treating a help article as a substitute for a data-processing agreement.

​

Current hosting

RAUM’s production platform is hosted on Microsoft Azure. The current architecture uses Azure-managed application, database, cache, object-storage, and secret-management services. Older RAUM documentation that referred to AWS/KMS is no longer current.

​

Encryption at rest

Credentials, API keys, and other sensitive configuration are encrypted by the application with AES-256-GCM before they are written to the database. The encryption key material is derived from a secret held separately in Azure Key Vault. The underlying Azure database and object storage also provide encryption at rest.

​

Bring your own AI provider

RAUM uses the provider account you connect. The simplified Assistant data flow is: Zendesk → RAUM → your AI provider → RAUM → Zendesk RAUM prepares the request, applies organization knowledge and policy, masks supported personal information, and sends the necessary model request using your configured provider credentials. RAUM does not run the request through a RAUM-owned OpenAI, Anthropic, Gemini, or equivalent customer-facing model account.

​

Personal-data masking

Before supported content is sent to AI models or written into relevant AI logs, RAUM applies personal-information masking/redaction. The current public security implementation describes masking for categories including names, email addresses, phone numbers, payment-card details, and other sensitive values, replacing them with placeholders and restoring the corresponding values in the final response where required.

​

Tenant boundaries

RAUM resources are organization-scoped. Assistant knowledge, Zendesk connections, AI settings, credentials, activity, and tool configuration are resolved in the context of the active organization. When an organization also uses AI Chatbot, public Chatbot resource publication is a separate trust boundary. An internal Assistant resource or connection does not become public merely because both products belong to the same organization.

​

SOURCE versus ACTION safety

External tools are classified as:

• SOURCE — read-only retrieval;
• ACTION — operations that can change state.

ACTION tools are gated by approval/authorization rules and do not default to automatic approval. Simulation intercepts ACTION side effects so teams can test the Assistant pipeline without executing the mutation.

​

Zendesk app credentials

The public RAUM AI Assistant Marketplace app uses a scoped RAUM application credential associated with the organization. Automatic installation can mint and inject that credential into the Zendesk app without requiring an administrator to copy it manually. Manual installation uses the Organization ID and a RAUM API token. Rotating the credential invalidates the old credential according to the installation/rotation workflow.

​

Auditability

RAUM records Assistant activity and administrative/system events so teams can investigate how a ticket was processed and what configuration actions occurred. Use:

• Activity → Ticket Activity for AI-run evidence;
• Activity → System Activity for operational/admin events; and
• Activity → Audit for the audit-trail view.

​

Recommended customer controls

For a production deployment:

1. use Zendesk OAuth where practical;
2. grant RAUM only the external-system access required for the workflow;
3. classify every mutating connection as ACTION;
4. keep automatic action approval off unless the workflow is specifically reviewed for it;
5. use shared encrypted credentials instead of copying secrets into multiple connections;
6. validate changes in Simulation;
7. review user/admin access periodically; and
8. rotate credentials when personnel, providers, or integrations change.