Executive summary

Seque is an enterprise data-loss-reduction (DLR) control for generative-AI usage. It intercepts prompts, pastes, and file uploads inside the browser, before any data leaves the user's device, and applies your organisation's classification policy to block, anonymise, or warn. An optional beta feature separately scans AI responses as they render, for emotion-inference and profiling language.

This document describes how Seque protects your data, the cryptographic and architectural controls behind it, the regulatory frameworks it supports, and, in the interest of transparency, the inherent limitations of browser-layer DLP and the deliberate design decisions we have made around them.

Three principles govern the design:

1. Local-first enforcement. The DLP control runs entirely on the device. It does not depend on network connectivity, and by default your prompt content is never sent to Seque to make an enforcement decision, see "Optional server-assisted classification" in §2 for the one admin-configurable exception.
2. Data minimisation. Sensitive values never leave the device in clear form. Telemetry is fingerprinted, redacted, and opt-in.
3. Defence in depth. Every trust boundary is validated independently; client and server each enforce their own checks rather than trusting the other.

1. Architecture overview

Seque has two components:

The critical property: enforcement is independent of the server. Classification and blocking happen in the content script using locally held rules. If the control-plane server is unreachable, DLP protection continues uninterrupted; the extension keeps blocking, anonymising, and warning exactly as configured. The server governs licensing and reporting, not protection.

Enforcement surfaces

Seque inspects data at each of the following interaction points with a supported AI platform:

• Typing: debounced inspection of the prompt field as the user types.
• Submission: keydown (Enter), click, pointerdown, and submit events are intercepted in the capture phase before the prompt is sent.
• Paste: clipboard content is classified before it is inserted.
• File upload: PDF, DOCX, XLSX, and plain-text files are parsed and scanned in-browser; sensitive content is anonymised or the upload is blocked. Some uploads are not scanned at all, see §8.
• AI responses (optional, beta) (rendered responses are scanned after the fact for emotion-inference and profiling language, firing a warning banner and audit event. This is a passive monitor, not a block, and is unrelated to the "before data leaves" guarantee above) a response is arriving, not leaving.

Supported platforms include ChatGPT, Claude, Gemini, NotebookLM, Microsoft Copilot, Perplexity, Poe, HuggingFace, DeepSeek, Grok, Mistral, Meta AI, Character.AI, You.com, Phind, v0.dev, and Bolt.new.

2. How your data is handled

On the device

• Prompt content is read transiently to classify it and, by default, is never transmitted to Seque: see "Optional server-assisted classification" below for the one configurable exception.
• Classification uses regular-expression rules and keyword-scoring policies executed locally.
• When a violation is found, the user sees a review dialog. Depending on policy, the value is masked/replaced, the submission is blocked, or the user is warned.

Optional server-assisted classification (ML-assist)

The separately deployed local Seque agent (not the Chrome extension, which has no such path) can optionally call server-side ML classification for text its local regex engine is uncertain about. This is off by default and requires opt-in at two levels: an administrator enables it and configures a provider for the organisation (OpenAI, Anthropic, or a customer-specified custom endpoint), and the agent itself is separately configured with the server URL and API key.

When enabled, the agent calls this path only for borderline or unmatched text (fewer than three local regex matches). It redacts any values its own regex rules already flagged before sending, but text that regex did not flag, which is the case ML-assist exists to catch, is sent in full, truncated to 4,096 characters, to the configured provider. The Seque server does not log or persist this text; it is discarded once the classification result is returned, subject to the third-party provider's own data-handling terms. If ML-assist is not enabled for an organisation, the "never transmitted" claim above holds without exception.

Local storage protection

Browser extension storage is sandboxed by origin but is not encrypted at rest by the browser. Seque adds AES-256-GCM encryption to sensitive locally stored values, using a key derived (PBKDF2, 100,000 iterations) from a device-bound identifier and a per-installation random salt.

What this does and does not protect against. The key is derived at runtime rather than stored, and it is device-bound: a value copied to another machine cannot be decrypted there without the originating device's identifier. Within the profile itself, however, both derivation inputs, the device identifier and the per-install salt, necessarily live in the same chrome.storage.local store as the values they protect, because the extension must be able to derive the key unattended on every service-worker start. Anyone able to read that store can therefore re-derive the key.

The honest boundary is this: local storage encryption raises the effort of casual inspection and prevents values being lifted to another machine. It is not a defence against an adversary with full access to an unlocked profile, and it should not be relied on as one in a threat model where laptop theft is in scope. Full-disk encryption on the endpoint (BitLocker, FileVault) remains the control that answers that risk, and Seque assumes it. Sensitive material is additionally minimised at the source: audit logs hold keyed fingerprints rather than flagged values, and the token registry that maps tokens back to real values is held in memory only and never written to disk at all.

Telemetry and audit (opt-in)

Audit events record that a violation occurred, never the sensitive content itself:

• Flagged values are replaced with one-way fingerprints before any transmission. The server can recognise repeat occurrences of the same value without ever seeing it.
• A server-side denylist rejects known raw-content field names (e.g. flagged/original/matched text) even if a client were to send them, and only schema-approved metadata fields are stored, defence in depth.
• Server synchronisation is opt-in (consent-gated) in line with POPIA Section 11 and GDPR Article 6. With consent withheld, audit data remains on the device only.

Tamper-evident audit trail

Every audit entry is linked into a SHA-256 hash chain (PCI DSS 10.3). Modifying or deleting any entry breaks every subsequent hash, making tampering cryptographically detectable. The same chaining is applied server-side for archived events, supporting eDiscovery and regulator proceedings.

2.1 Data inventory

What Seque stores, why, and for how long. This is the record to work from for POPIA §17 / GDPR Article 30 (records of processing) and for security questionnaires. Everything below lives in the deployment's own database, see §5 for how a jurisdiction is chosen.

Never stored

• Prompt or document content, by default. Classified transiently on the device; never transmitted to Seque unless an admin has opted the org into ML-assisted classification (§2), which sends only unmatched/borderline text, truncated to 4,096 characters, to a configured third-party provider.
• Raw flagged values. Only keyed HMAC-SHA-256 fingerprints are transmitted or stored. A server-side denylist additionally rejects known raw-content field names if a client ever sent them.
• Passwords. Administrator authentication is OIDC against the customer's IdP; Seque holds no credential to steal.

Stored

Precision on identifiers

• Device identifiers are random UUIDs generated on the device; they carry no personal information in themselves. In seats, device_heartbeats and device_credentials they are additionally pseudonymised server-side with a dedicated HMAC secret, so the raw value never lands in those tables. In audit_events the client-supplied identifier is stored as received (format-validated, not pseudonymised) for retry-idempotency scoping.
• Operator IP addresses are not pseudonymised at write. They are retained in the clear for 90 days to support security investigation, then rewritten in place as HMAC pseudonyms by a daily job.
• user_id is whatever the customer's directory supplies. If they provision by email address, that is personal data under POPIA/GDPR and is held for the life of the seat.
• Flagged-value fingerprints are keyed HMAC-SHA-256 using a device-bound key, so repeats are recognisable for that device without the value ever being transmitted.

Erasure

Two paths reach the same code, so there is one definition of "erased" rather than two that can drift apart:

• On demand: an administrator exercising POPIA / GDPR Article 17 on behalf of a data subject.
• Automatically: a daily sweep erases an organisation once 90 days have passed since its subscription ended, which is the commitment made in the Terms of Service and Refund Policy. The window is measured from licence expiry, so a renewal simply moves it and a renewing customer is never a candidate. Suspension is deliberately not a trigger: it is a reversible commercial action, and erasing on it would make it irreversible.

Erasure anonymises rather than drops rows. Audit entries carry a hash chain that is evidence for other events too, so nulling the identifying columns removes the personal data while leaving the chain verifiable, an erasure that broke the chain would destroy the integrity guarantee for records that are not being erased. Identifying fields are cleared, credentials revoked, sessions deleted, and the organisation is marked purged.

The sweep is bounded rather than trusted, being the only unattended irreversible operation in the system: a circuit breaker refuses the entire run if more organisations qualify at once than an ordinary rate of attrition would produce, on the reasoning that a bulk match indicates a clock or data fault rather than a genuine cohort.

Processors outside the deployment

3. Cryptographic controls

4. Control-plane security

For deployments that use the optional server, the control plane implements the following controls:

• Authentication: Administrators sign in via SSO/OIDC. Sessions use HMAC-signed cookies with hashed server-side token storage. Direct credential proof-of-possession is disabled in production.
• Authorisation: Role-based access control (admin / analyst / viewer). Roles are re-validated against your identity provider's group mappings on every request, so revoking access in your IdP takes effect immediately.
• Multi-factor authentication: MFA can be enforced org-wide; enforcement applies live to all active sessions, not just new logins.
• CSRF protection: All state-changing requests require a CSRF token bound to the session.
• Cross-tenant isolation: Every query is org-scoped; licence-to-organisation binding is verified on each request to prevent credential mix-ups.
• SSRF hardening: All outbound requests to customer-controlled URLs (SIEM endpoints, webhooks, OIDC issuers) pass through an SSRF-safe HTTP client that resolves DNS once and pins the connection to the validated address (defeating DNS-rebinding/TOCTOU), blocks redirects, rejects private/loopback/link-local/cloud-metadata ranges, enforces HTTPS-only, and caps response size.
• Rate limiting: Per-organisation and per-route limits protect against abuse and brute force.
• Operator audit trail: All administrative actions are recorded with actor, role, resource, and IP, supporting SOC 2 Type II evidence collection.
• Remote revocation & kill-switch: Compromised licences can be revoked centrally; an emergency kill-switch can disable affected instances during incident response.

Secrets management

Signing keys and encryption keys are supplied through environment variables and never written to disk or committed to source control. The repository is protected by an automated secret-scanning gate in continuous integration, and key material is excluded by policy.

5. Data residency and regional deployment

Seque supports regional control-plane deployments so that licensing, audit and account data are processed and stored within a chosen jurisdiction. Clients are directed to their regional endpoint through their signed licence, and the endpoint is validated against an allow-list before use, a licence cannot redirect traffic to an arbitrary server.

How a region is established. A region is a deployment of the Seque server bound to a database in that jurisdiction, for example an AWS RDS instance in af-south-1 (Cape Town) for POPIA. Two settings define it:

Regional hostnames follow api-<region>.dfum.org. The client allow-list accepts the primary and any such regional host over HTTPS, and rejects everything else; a rejected endpoint is logged as an error rather than silently downgraded, because a silent fallback would move a region's data to another jurisdiction without evidence.

What personal data stays in-region. Everything in the §2.1 inventory rests in that deployment's database. By default, prompt content never leaves the device (audit records carry keyed fingerprints, and free-text fields are stripped server-side. Device identifiers are pseudonymised in the seat and device tables with a dedicated HMAC secret, and sensitive columns are encrypted at the field level. Operator IP addresses are retained in the clear for 90 days for security investigation before being pseudonymised in place) see §2.1 for the exact handling of each identifier.

What can leave the region. Some dependencies are external to the deployment and must be configured or accepted per jurisdiction:

• Email: recipient addresses are handled by the configured provider. EMAIL_PROVIDER=ses with an in-region AWS_REGION (e.g. af-south-1) keeps this in-jurisdiction; the Resend default is US-hosted.
• Bot protection: Cloudflare Turnstile sees the client IP on the public trial sign-up form only.
• Error reporting: Sentry, only if SENTRY_DSN is configured.
• Optional ML-assisted classification: if an org enables ML-assist (§2), unmatched/borderline prompt text is sent to the configured OpenAI, Anthropic, or custom endpoint for classification. Unless that endpoint is itself hosted in-region, this is a cross-border transfer and should be assessed against your jurisdiction's transfer rules (e.g. POPIA s.72, GDPR Art. 44-49) before enabling.

6. Regulatory alignment

Seque is designed to support compliance with:

Seque has not completed a formal SOC 2 Type II audit; the row above reflects controls that generate the evidence such an audit would examine, not an attained certification. Seque is a tool that supports your compliance programme; it does not by itself constitute legal compliance. Your obligations depend on your jurisdiction, data, and configuration.

7. Resilience and availability design

Seque is designed to fail safe for protection and fail open for availability: a deliberate and clearly bounded trade-off:

• Matched text-classification rules never fail open. Classification and blocking are local and do not depend on the network: if a configured rule matches text content, it is blocked or anonymised regardless of server reachability. This guarantee applies once content has been extracted and classified; §8 documents the file-upload cases (oversized files, extraction failure, unsupported formats) where content is not scanned at all.
• Licensing degrades gracefully. When a valid licence expires, a 30-day grace period keeps the tool fully operational while warning the administrator, rather than abruptly disabling protection.
• Telemetry and revocation tolerate outages. If the control plane is temporarily unreachable, audit synchronisation retries and the tool continues operating on its last-known-good licence state rather than disabling itself. This prioritises uninterrupted protection during network incidents.

Organisations operating in high-assurance environments can pair Seque with a secondary revocation channel and network-egress controls for additional defence.

8. Known limitations (transparency)

Browser-layer DLP has inherent boundaries. We document them openly so your security team can make an informed decision and apply compensating controls.

• Voice / audio input. When a user dictates a prompt using a platform's built-in voice feature, speech-to-text occurs inside the platform's pipeline. If the platform renders the transcription into the editable field, Seque inspects it on the next tick. If the platform submits the audio directly without rendering text, that path is not inspectable from a browser extension. Audio streams are not accessible to content scripts.
• Network-send race window, closed in 3.2. Submission events are intercepted in the capture phase, and on some single-page platforms a fast keyboard or click sequence could dispatch the request inside the same event cycle as the intercept. Earlier editions of this paper described that window as irreducible without a network proxy. That was wrong in one respect: the request itself is now inspected before it leaves, so the outcome no longer depends on winning a race against an event handler. The residual limit is not timing but reach. See the entry above for what still lies outside the APIs a page uses.
• Interception depends on how a platform sends. Seque inspects prompts and uploads at the points a browser exposes: typing, pasting, submission, file selection, and the network calls a page makes. From 3.2 that includes platforms which select files through the File System Access API (showOpenFilePicker) rather than a file input, ChatGPT among them, where an extension previously had nothing to observe and attachments uploaded unchecked. It also includes the request itself: fetch, XMLHttpRequest, sendBeacon and WebSocket frames are inspected before they leave, which closes the narrow send-race described below rather than merely bounding it. What remains outside this is anything that never passes through those APIs in the page: a request issued from a Web Worker has its own scope, and a request body streamed as a ReadableStream can be consumed only once, so it is recorded as uninspected rather than treated as clean.
• File uploads that are not scanned. Three cases pass an uploaded file through without content inspection, each recorded as a FILE_SCAN_SKIPPED audit event so admins retain visibility, except extraction failure, which passes the file through unmodified with no distinct event: (1) image, video, and binary formats, where content-based scanning would require an OCR step Seque does not perform; (2) PDFs or plain-text files over 20 MB, skipped to bound memory use; (3) files whose text could not be extracted. Treat all three as a signal for manual review, not as scanned-and-clean.

These limitations are characteristic of all browser-extension DLP and are not unique to Seque. For coverage of unsupported paths, Seque complements, and does not replace, network DLP, endpoint DLP, and acceptable-use policy.

9. Secure development practices

• Continuous-integration security gates: dependency audit, source secret-scanning, ReDoS-pattern parity checks across all rule engines, and runtime regression tests run on every change.
• ReDoS protection: all dynamically loaded classification rules are screened for catastrophic-backtracking patterns and executed under a time bound, preventing a malicious rule from freezing a browser tab.
• Input validation: licence and policy payloads are structurally validated before any cryptographic processing, preventing resource-exhaustion and parser-edge-case attacks.
• Least privilege: the extension requests only the host permissions required for supported AI platforms and its own licensing endpoints.

10. Responsible disclosure

We welcome reports from security researchers. If you believe you have found a vulnerability, please contact connect@dfum.org with details and reproduction steps. We aim to acknowledge reports promptly and will work with you on coordinated disclosure. Please do not publicly disclose an issue until we have had a reasonable opportunity to remediate it.

Summary

Seque applies enterprise-grade cryptography (RSA-2048 signatures, AES-256-GCM encryption, HKDF request proofs, timing-safe comparisons), strong control-plane security (SSO/OIDC, live RBAC, MFA, CSRF, best-in-class SSRF defence), and a privacy-first data model (local-only enforcement by default, fingerprinted opt-in telemetry, tamper-evident hash-chained audit). It is transparent about the inherent limits of browser-layer DLP and is designed so that the core protection continues working even when everything else is offline.

For architecture deep-dives, deployment guidance, or a security questionnaire response, contact connect@dfum.org.

This whitepaper describes the design and intent of the Seque product as of the version noted above. Capabilities may evolve; configuration determines which controls are active in your deployment. This document is informational and does not constitute a warranty or legal advice.