Security

Last updated: 25 October 2026

Instama keeps every customer's data in the EU, isolates each tenant inside the database itself, and builds on managed infrastructure that is independently certified to SOC 2 Type II and ISO/IEC 27001.

This page describes how the platform is built and run, written for anyone evaluating Instama and for technical and security teams in particular. Where something is not in place yet, it says so. For what comes next, a walkthrough or a security questionnaire, write to security@instama.co.

At a glance

Every client, including the AI assistant, reaches the data through the same API and the same database rules. Only a few external services, such as AI model providers, work outside the EU, and they receive only what a task requires.

Hosting and data residency

Instama runs only on managed, serverless infrastructure, so there are no servers of our own to patch or harden. All customer data is stored in the EU, and all platform compute runs in EU regions; a deployment to a region outside the EU is refused by the platform's own configuration.

Every third party that receives data, including the AI model providers, is listed with its purpose and location on the subprocessors page.

Transport and encryption

• HTTPS only. TLS 1.2 or 1.3 at the provider's edge, with certificates managed and renewed automatically. Plain HTTP is permanently redirected.
• HSTS with a two-year max-age on the platform and the website, so browsers refuse to downgrade.
• Custom domains for organisations get their certificate once DNS is verified; unknown hosts answer "not found".
• Service-to-service traffic to the database, storage, render compute, payments and AI providers is all over TLS.
• At rest, the database, its backups and file storage are encrypted with AES-256.
• Credentials Instama issues (API keys, OAuth tokens, invitation tokens) are kept only as keyed hashes (HMAC-SHA256); a key is shown once.
• Access tokens for connected accounts (social and ad platforms) are encrypted by the application itself (AES-256-GCM) before they are stored, each bound to its brand, with a key per environment that the database never holds: a database copy or backup holds them only in encrypted form, and they are decrypted only on the server, for the call that uses them. Signed-in users cannot read them; the database refuses a token stored any other way, and automated tests check both.

Tenant isolation

Customers are organised as organisations, each holding one or more brands. Every piece of content, media, brand knowledge, publishing channel and chat belongs to a brand, and every query is scoped to the brands the caller is a member of. PostgreSQL enforces this itself, so a bug in application code still cannot read or write another tenant's rows.

• Row-Level Security on every table. Internal tables, such as the audit log and credential hashes, have no user-facing policy at all, so no signed-in user can reach them.
• No anonymous access to any application table.
• Hardened database functions. Every privileged function pins its search_path, closing a known class of privilege escalation; internal functions cannot be called through the API.
• Append-only and immutable data. The audit log rejects updates and deletes, even from the service role; key columns such as an API key's owner and scope cannot be changed.
• One enforcement point for every credential. A browser session, an API key, an OAuth token and a background job all reach the database as the person they act for, with that person's permissions.
• Realtime on private channels. Live updates travel on private topics per person, organisation, brand and document, authorised by the same rules, and carry identifiers only.
• Verified by tests. Database tests check every role against every permission and table, and that an outsider reaches nothing; schema tests fail when a table lacks Row-Level Security or a function lacks a pinned search_path; integration tests sign in as real users.

Identity and access

Nobody has a password on Instama, accounts exist only by invitation, and a second factor, once set up, is enforced by the database itself.

Sign-in

• Passwordless only: a one-time code by e-mail, or Google, Microsoft or GitHub through the OAuth authorisation-code flow with PKCE. With no password database there is nothing to leak and no credential stuffing.
• Invite-only accounts: a database hook refuses any new account, by any sign-in method, unless it holds a pending invitation, an approved access request, or a valid invite link or code.
• Rate limits on sending and verifying codes, sign-ins, token refreshes and invite codes.

Second factor and step-up

• TOTP second factor. Once a person adds one, every table refuses their session until it is verified with that factor (AAL2). An application bug cannot skip this check.
• Step-up for sensitive actions. Creating or revoking API keys, revoking OAuth grants and changing the account e-mail need a fresh proof within the last 15 minutes, refused per RFC 9470 otherwise.
• No credential outranks its session. API keys, OAuth grants, assistant turns and background jobs carry the assurance level of the session that created them and never act above it.

Sessions

• Host-only __Host- cookies: Secure, SameSite=Lax, scoped to the platform's own domain.
• Access tokens last one hour; refresh tokens rotate on every use, and reuse is detected.
• A request that changes data on a cookie session must come from the platform's own origin (no cross-site request forgery).
• Signing out ends all of a person's sessions on every device.

Roles

Permissions are stored as data, so an organisation can define its own roles; folders and channels can be shared with specific people at a set level. Every role and grant is checked by the database, not only by the interface.

Instama staff access

Platform administration is limited to a small, named set of Instama staff, granted outside the customer data model. Every administrative session needs a verified second factor, a factor proof within the last 12 hours and administrative activity within the last hour. Administrative changes are written to the append-only audit log. To anyone else the administration area answers "not found", and there is no "log in as a customer" feature.

API, MCP and integrations

Every client uses one API behind one set of checks: the web app itself, AI assistants through MCP, and any other API client, such as the Figma plugin, a desktop app or a customer's own integration. Every action checks the caller's brand scope and then runs under the caller's database permissions. Errors share one documented format; database errors and stack traces never reach a client.

Connected accounts. Instama publishes to and reads results from Facebook, Instagram, LinkedIn, LinkedIn Ads, Meta Ads, Google Ads and Pinterest through the standard OAuth 2.0 authorisation-code flow. Sign-in redirects pass a stateless relay that accepts only signed state valid for 15 minutes and redirects only to Instama's own domains. Tokens are stored per brand, never cross the tenant boundary, and a brand admin can disconnect them at any time.

Abuse protection. Rate limits on sign-in, OAuth client registration, access requests, demo bookings, invite codes and voucher redemptions; a cap on concurrent AI tasks per person; and a spend monitor that warns as an organisation nears its limit and pauses AI work when usage runs far beyond it.

Storage and rendering

• Private storage. Uploads, generated assets and rendered outputs sit in private buckets under the same brand and second-factor policies as the database. A separate public bucket holds only files that are deliberately public.
• Delivery through a same-origin proxy that fetches with the viewer's own credentials, or signed URLs that expire within an hour and are issued only for files the viewer was just confirmed to reach. A refused, missing or unknown file all answer the same "not found".
• Uploads are signed, uploaded and committed: the platform checks permission, folder and quota against a named profile (allowed types, size limit), the client uploads with a single-use URL that cannot overwrite anything, and the file is committed only after it is verified.
• Rendering runs on short-lived, isolated compute in the EU: a fresh, isolated environment for each video, image or PDF render. A render receives only signed, time-limited links to the brand's own files, checked against the requesting person's access, and keeps nothing afterwards.

AI

Every AI call starts on Instama's servers, goes through a small number of controlled routes, and uses the person's own permissions. A model never gets direct access to the database: it acts only through the same checked tools as a person.

• Tools, not raw access. The in-app assistant and external assistants (through MCP) act through registered tools that check brand scope and run under the caller's permissions. Text a model reads in a web page or a document cannot widen what it may reach.
• No trusted context from the request. The brand and organisation a conversation works in are resolved on the server against the person's own memberships.
• Approval across brands. A change the assistant wants to make outside the brand the person is working in waits for the person to approve or deny it.
• Stoppable. Every assistant turn is a durable, server-owned job; stopping it reaches the running model call and tool.

Which providers are used and what each may keep or train on is on the AI and your data page.

Secure development

A change reaches production only after it has run in two separate environments (development and preview, each with its own database and secrets) and passed a gate of type checks, linting, unit tests, database tests and a full production build. Production is released through a pull request from the tested preview branch, and a release is refused while its database lacks a migration it needs.

• Declarative database changes. The schema lives in version-controlled SQL; each migration is generated from it and verified to reproduce it exactly before it is applied.
• Rules as tests. Architectural guard tests encode the platform's security rules, for example: no shortcuts around the API, one error format, the database client confined to one package, zero data retention on decision models, and every AI provider and retention period on these pages matching the code.
• Configuration checked at build time. A hosted build stops when a required setting is missing, when a setting is forbidden in production (test sign-in codes, mock providers), or when a region is outside the EU.
• Supply chain. A locked dependency tree; a release-age gate that keeps newly published package versions out for a minimum period; known-vulnerable transitive dependencies pinned to patched versions; install scripts only for an explicit allow-list.
• Secrets are encrypted environment variables, separate per stage, never in source control. Code that handles them is marked server-only, so a build fails if it would reach the browser.

Operations

• Audit log. Every change and every refused attempt through the app, the REST API and MCP: who acted and as what (person, API key, OAuth client, background job), the surface, the authentication method, the outcome, a redacted preview of the input and the duration. Append-only, kept 24 months.
• Monitoring. Daily automated checks of the access rules and the retention sweeps; continuous spend and usage monitoring; real-user performance measurement; durable background jobs that retry a failed step.
• Backups and continuity. Daily encrypted database backups that roll over within 30 days; a stateless application where any deploy can be rolled back instantly; infrastructure and database structure defined in code. Point-in-time recovery and documented recovery objectives are planned.
• Incidents. We notify the supervisory authority of a personal-data breach within 72 hours and an organisation whose data is affected within 48 hours. A documented incident response plan with exercises is planned.

Shared responsibility

Found a weakness? See how to report a vulnerability.