Security · Artica

The guarantee

How it's enforced.

Most vendors' data-retention promises live in a policy PDF. Ours lives in our build pipeline. On every code change, an automated check connects to a database carrying our real migrations and verifies two things:

The one table that touches ticket processing is allow-listed to exactly five columns — a run ID, a ticket ID, an embedding vector, a month bucket, and a timestamp. Any added column fails the build, whatever it's named.
Every other column in the entire schema is checked against deny patterns: subject, body, description, requester, comment, raw_, ticket_text. A schema change that creates a place for ticket content to sit is a red build, not a data-retention incident.

The failure mode this guards against is the well-meaning engineer caching a subject line "just for display." With us, that's a failed build — it cannot quietly become your data sitting in our database.

The data flow

Ticket text exists for one run. Then it's gone.

Connect.

You authorize Artica through Zendesk OAuth. Your access tokens are encrypted with AES-256-GCM before they ever touch our database. They're never logged and never sent to a browser.

Pull.

A processing run pulls your last 30 days of resolved tickets into an ephemeral compute environment. Ticket text exists only there, only in memory. If the process dies, the text dies with it.

Read.

An AI model reads each ticket and distils it to a single identifier-free line — what the customer asked, with names, numbers, and amounts stripped. The original ticket text is discarded as it's processed; only that scrubbed line and a numerical embedding vector survive.

Group and label.

The AI authors the topics from those scrubbed lines, organises them into help-center categories, and writes example questions; each ticket is placed under its topic by embedding — all inside the same ephemeral run, while the context still exists.

Persist.

What lands in our database: topic labels, descriptions, embedding vectors, monthly volume counts, AI-synthesized example questions, and Zendesk ticket ID numbers. What never lands: ticket subjects, bodies, requester names, or any ticket field rendered for display.

Even the ticket links are just pointers. When Artica links to an example ticket, it stores only the ID number. Click it and Zendesk authenticates you and shows you your own data — we never cache a subject line to display.

Even the example questions are checked. The AI-written questions describe a topic across many tickets, never one ticket. During processing, any generated question too similar to a single source ticket is automatically rejected and regenerated.

Storage

What we store, and what we never store.

Stored

Your account: name, email, workspace membership and role
Your Zendesk connection: subdomain, granted scopes, encrypted OAuth tokens
The derived taxonomy: topics, descriptions, vectors, volume counts, ticket IDs
Your published help-center articles' metadata (title, URL, content hash) — content you already publish publicly
Articles you write in Artica, and their images
Stripe customer and subscription IDs — never card numbers

Never stored, anywhere

Ticket subjects or bodies
Ticket requester names or emails
Any ticket field rendered for display
Raw, un-redacted screenshots
Card numbers or payment credentials
Plaintext invite tokens (we store only a hash)

The Chrome extension

The extension redacts before upload.

The extension records workflows as screenshots — which means it could record admin panels full of customer data. So redaction happens in your browser, before a single byte is uploaded:

What it detects. Emails, card numbers (checksum-verified, so order numbers aren't mass-blurred), API keys and tokens, phone numbers, SSNs, IBANs, password fields — and anything your own pages mark as sensitive. Not just text on the page: what's typed into form fields is scanned too, and declared payment fields are blurred whether or not they're filled in.
The blur is destructive. Matches are blurred into the image itself — heavy blur plus an opaque overlay, painted into the pixels. An unredacted screenshot never exists outside your tab's memory.
The text is redacted too, not just the pixels. Each capture step also carries a description, a page title, and a page URL — all of which pass through the same pattern redaction in your browser before upload, and URLs are stripped of query strings and fragments entirely.
Over-eager by design. A false positive blurs something harmless; a false negative would put a card number in a help center.
Minimal permissions. The extension requests activeTab, scripting, and storage — no "read your browsing history," no "access all your data on all websites" at install. Broader access is requested by Chrome's own prompt only at the moment you start a capture.
Discard means discarded. Cancel a capture and the screenshots are hard-deleted from storage — not flagged, deleted.
Where it stops. Embedded frames from another domain — a hosted payment form, a third-party widget — are sealed off from the extension by the browser itself, so their contents can't be scanned. That's a limit of doing redaction in your browser rather than on our servers, and we'd rather name it than let you assume otherwise. Frames from the site you're on are scanned normally.

Automated redaction is a safeguard, not a guarantee — you review captures before they go in an article.

Platform security

Access, isolation, encryption.

Every product route requires a signed-in session. Machine endpoints (webhooks, job callbacks) authenticate independently by cryptographic signature or token.
Workspace isolation. Every tenant-owned record is scoped to your workspace, every query is workspace-scoped, and stored files live under workspace-scoped keys — a file URL is not a capability; retrieval is checked against your session's workspace.
Roles are enforced server-side. Owner / Editor / Viewer live in our database and are checked at every mutating endpoint — hiding a button is not a gate.
Encryption: TLS everywhere in transit; provider-managed encryption at rest; application-level AES-256-GCM for the one credential we hold on your behalf (your Zendesk OAuth tokens).
Invites can't be minted from a database read — invite tokens are stored only as SHA-256 hashes; the token itself exists only in the recipient's email.

We use a small set of infrastructure providers, each receiving only what its role requires — and ticket text reaches only the ephemeral processing layer and the AI providers that read and analyse tickets mid-run, never storage. See the full list and what each receives →

What we don't claim

We'd rather tell you what's not done than let you assume it is.

No SOC 2 or ISO 27001 certification yet, and no third-party penetration test has been completed. On the roadmap as the business grows. What we have instead is the enforced-by-CI retention guarantee above — and unlike a certificate, you can ask us to show you the check.
Tenant isolation is application-level today. Database-layer row-level security is planned as a second enforcement layer, not yet shipped.
No unified audit log yet. Access grants (invites), job history, and topic-article match events are recorded; a comprehensive admin action log is roadmap.
Self-serve workspace deletion is roadmap; today it's handled same-day by support.

Your tickets pass through. They never stay.