Skip to content

Security & Trust

Last Updated: August 9, 2026

Version 2.2.0 · Effective Date: August 9, 2026

Tenant isolation

Postgres row-level security on every customer table

Encryption

TLS 1.3 in transit · AES-256 at rest

MFA

TOTP with backup codes, lockout on abuse

Operator & Data Controller

  • ShiftNode Digital s.r.o. (operator of the EM3A service at em3a.ai)
  • Registered office: Nové sady 988/2, Staré Brno, 602 00 Brno, Czech Republic
  • Company ID (IČO): 249 06 123
  • Privacy contact: privacy@em3a.ai
  • Legal / procurement contact: legal@em3a.ai

English legal version controls. Localized routes may include summaries for visitor convenience, but the English text controls unless a separately signed agreement says otherwise.

Purpose & scope

This page describes the security controls ShiftNode Digital s.r.o. has enabled in EM3A today. It is maintained by the operator and is not an independent audit or a certification of any kind. It is intended to help procurement, security, and legal reviewers answer common questions during vendor intake. Customers with signed contracts that include stricter controls should rely on those contracts; this page is a public summary.

ShiftNode Digital s.r.o. does not currently hold SOC 2, ISO/IEC 27001, HIPAA, or FedRAMP attestations. Where this page references those frameworks it is only to describe the shape of a control, not to claim compliance.

1. Identity, authentication & access

  • Authentication methods: email + password and Google sign-in via the managed authentication provider. GitHub, Apple, and other social providers are not enabled by default.
  • Multi-factor authentication (MFA): time-based one-time password (TOTP) with single-use backup codes. Users can enroll in MFA at any time; the EM3A platform admin can require MFA for a workspace.
  • Passwords: minimum length and complexity enforced client- and server-side. Leaked-password protection (HIBP check) is enabled — passwords that appear in known breach corpora cannot be set.
  • Session management: sessions time out after 30 minutes of inactivity and are capped at an absolute lifetime of 12 hours regardless of activity — after which re-authentication (and MFA, if enabled) is required. Trusted devices are remembered for up to 14 days when the user opts in, and users can revoke every active session across every device with a single "Sign out from all devices" action in Settings → Security.
  • Brute-force protection: the account is locked after 5 failed sign-in attempts within a rolling window; unlock requires password reset or an admin action.
  • Role-based access control (RBAC): role assignments are stored in a dedicated table and evaluated by a security-definer database function. Platform-owner, workspace-owner, workspace-admin, and member roles are distinct and scoped to a specific workspace.

2. Multi-tenant data isolation

  • EM3A is a multi-tenant application running on a shared Postgres cluster managed by our platform subprocessor. Isolation is enforced logically, not by physically separating databases per customer.
  • Every customer-facing table has Postgres row-level security (RLS) enabled. RLS policies filter rows by the caller's authenticated user id and the workspace id derived from their session — never from a client-supplied header or parameter.
  • Where a table is deliberately readable by everyone (reference data such as country codes, credit-cost tables, or the public help articles), that decision is documented in code and reviewed as part of any schema change.
  • Object storage paths (avatars, uploaded documents) are prefixed with the owning workspace and user identifier so that a stolen path from one customer cannot resolve to another customer's file.
  • Suspended and offboarded workspaces are blocked from writes at the database level by a validation trigger, not only at the application layer.

3. Data protection & cryptography

  • In transit: all customer traffic is served over HTTPS with TLS 1.3. HTTP is redirected to HTTPS. HSTS is set by our hosting layer.
  • At rest: the underlying Postgres database, object storage buckets, and backups are encrypted with AES-256 by our platform subprocessor.
  • Secrets: API keys, webhook signing secrets, and third-party credentials are stored in the managed secret store, not in source control or environment files committed to the repository.
  • Bring your own key (BYOK): not offered today. Customers with a regulatory requirement for customer-managed keys should contact legal@em3a.ai before purchase.
  • Backups: continuous point-in-time backups are managed by our platform subprocessor with retention windows defined in that subprocessor's service description.

4. AI, model use & data retention in AI systems

  • EM3A routes model calls through a managed AI gateway that fronts multiple upstream large-language-model providers. The specific model chosen for a given task is documented in the product's model registry.
  • Prompts and results are stored inside the customer's workspace under normal row-level-security. They are not shared across workspaces and are not used by ShiftNode Digital s.r.o. to train external foundation models.
  • We ask our AI gateway subprocessor to enforce zero-data-retention with its upstream providers wherever the provider offers that mode. Where a specific upstream provider does not, we call that out in the subprocessor page.
  • Retrieval-augmented workflows scope vector and knowledge-graph lookups to the caller's workspace id derived from the authenticated session, not from any value included in the prompt.
  • Automated worker missions run under strict per-mission budgets: maximum steps, maximum tool calls, and maximum credit spend, enforced on every iteration to prevent runaway or abusive execution.
  • Sales Simulator voice sessions use short-lived authenticated WebRTC tokens. The voice provider never receives EM3A service credentials; post-call events are HMAC-verified, provider identities are matched to the tenant-bound session, and provider-side audio storage is disabled.

5. Application & API security

  • Input validation: API-gateway and webhook endpoints validate request bodies against strict Zod schemas. Mass-assignment is blocked by whitelisting the fields the caller may set.
  • Server-side request forgery (SSRF): outbound HTTP calls to user-provided URLs (webhooks, document fetches) pass through an allow-list and block loopback, link-local, and metadata-service ranges.
  • Webhook signatures: outgoing webhooks are signed with an HMAC header (t=<ts>,v1=<hex>) over the timestamp and body. Customers verify signatures on receipt. Delivery failures are retried on an exponential schedule and moved to a dead-letter table after repeated failure.
  • API keys: customer API keys are scoped to specific capabilities (for example read:projects, write:projects). Keys can be rotated with an optional grace window; deletion is immediate.
  • Rate limiting: per-workspace request budgets protect against accidental or malicious spikes and cap AI-cost exposure.

6. Auditability & logging

  • Administrative actions, workspace-membership changes, credit grants and moves, merges, offboarding, and enhancement runs are recorded in dedicated audit tables inside the customer's workspace.
  • Audit records are append-only from the application and each row is chained to the previous one with a SHA-256 integrity hash, so any tampering, deletion, or reordering is detectable by an operator running verify_audit_chain.
  • SIEM export (Enterprise): a background worker fans out new audit rows every 5 minutes as signed HMAC-SHA256 webhook events (audit.user_activity, audit.admin_action, audit.org_event) to your Splunk HEC, Datadog Logs, Panther, ELK, or any HTTPS sink. Contact legal@em3a.ai to enable it on your workspace.
  • Sign-in attempts, MFA verifications, and password resets are recorded with a coarse IP and user-agent hash for anomaly investigation.

7. Retention & deletion

  • Active workspaces: customer data is retained for the life of the workspace.
  • Cancelled or offboarded workspaces: projects, contacts, and worker outputs are retained for 30 days after cancellation to allow reactivation, then permanently deleted from the primary database. Backups age out per our platform subprocessor's retention window.
  • Individual account deletion: users may request account deletion from Settings. The request is recorded in account_deletion_requests with a scheduled deletion 30 days out. An hourly worker (process-account-deletions) hard-deletes user-owned rows across ~50 tenanted tables, anonymises retained audit/financial rows, and removes the auth identity itself.
  • Operational log retention: a daily job (purge_retention_windows) prunes API request logs, edge function errors, login attempts, and notification delivery logs after 90 days; read notifications and email send logs after 180 days. Tamper-evident audit logs (user_activity_audit, admin_audit_log, org_audit_log) are retained for the life of the workspace.
  • Data export: customers may request a copy of their workspace data at any time via privacy@em3a.ai.

8. Incident response

  • Suspected security incidents can be reported to security@em3a.ai. This mailbox is monitored on business days and by on-call rotation outside business hours.
  • Customer notification: in the event of a confirmed personal data breach affecting a customer, ShiftNode Digital s.r.o. will notify the affected customer without undue delay and in any case within 72 hours of confirmation, in line with GDPR Article 33.
  • Every incident is followed by a written post-mortem that identifies root cause, blast radius, corrective actions, and their owners. A redacted summary is available to affected customers on request.

9. Vulnerability disclosure

  • We welcome coordinated disclosure of security vulnerabilities. Please email security@em3a.ai with a description, reproduction steps, and any proof-of-concept material. Do not exfiltrate customer data, deface systems, or run automated scans that would degrade the service.
  • We aim to acknowledge reports within 3 business days and to provide a remediation timeline within 10 business days. We do not currently run a paid bug bounty.
  • Please give us a reasonable window to remediate before any public disclosure. We will credit the reporter in the fix note unless anonymity is requested.

10. Subprocessors

A current list of subprocessors — including the managed platform host, AI gateway, email delivery, and analytics providers — is maintained at /legal/subprocessors. Changes are notified in accordance with our Data Processing Agreement.

11. Certifications & roadmap

Honest statement of certification posture

ShiftNode Digital s.r.o. does not currently hold SOC 2, ISO/IEC 27001, HIPAA, or FedRAMP attestations. Enterprise customers requiring one of these frameworks should contact us before purchase so we can share our current readiness posture and target dates.

Shared responsibility

Security is a shared responsibility. ShiftNode Digital s.r.o. operates the platform, the tenant-isolation controls, encryption, and the subprocessor relationships listed on this page. Customers are responsible for choosing strong passwords, enabling MFA, managing role assignments inside their workspace, protecting their API keys and webhook secrets, and complying with the Acceptable Use Policy.

Contact