How your data is protected

Tenant isolation

Every record in FullArc belongs to exactly one account, and separation is enforced three times over rather than once. The layers are independent on purpose — a mistake in one is caught by the next, instead of becoming a data leak.

• Request context. The account is established immediately after authentication and carried through the request, so application code cannot forget to scope a query — it has no way to ask for “everything” in the first place.
• Database client. A layer above the query builder injects the account filter into reads, writes and deletes, and independently verifies ownership on any operation that addresses a record directly by its identifier.
• Row-level security in PostgreSQL. The database itself refuses rows belonging to another account. This is the floor: it holds even if the two layers above it are bypassed entirely.

Cross-account access is covered by automated tests that attempt the leak directly, rather than by review alone.

Stored credentials

FullArc holds credentials you connect: AI provider keys, Google Places keys, and Gmail or IMAP mailbox access. These are the most sensitive values in the system, and they are treated accordingly.

• Encrypted at rest with AES-256-GCM, using a key derived per record via PBKDF2 with a random salt. Two accounts storing the same API key produce different stored values, so keys cannot be correlated across accounts by comparison.
• Never returned to the browser once saved. The interface shows whether a credential is configured, not what it is.
• If encryption is not available, saving a credential fails rather than falling back to storing it in the clear.
• Used only for your account's own requests. FullArc has no platform AI key, so your key is never pooled with anyone else's and never spent on another account's work.

Accounts and access

• Passwords are hashed with bcrypt. They are never stored or logged in a recoverable form, and we cannot tell you what your password is.
• Two-factor authentication is available using any TOTP authenticator app, with single-use backup codes.
• Sessions use signed, HttpOnly, Secure, SameSite cookies that JavaScript cannot read. Access tokens are short-lived; refresh tokens can be revoked, which signs out every session for that user at once.
• Granular permissions — 46 distinct capabilities across five roles — so access can be scoped to the job rather than granted wholesale.
• State-changing requests carry CSRF protection, and are rate limited per account.

Infrastructure and data flow

• All traffic is served over HTTPS. Database and queue connections are TLS-encrypted.
• Data is stored in managed PostgreSQL with provider-level encryption at rest and point-in-time recovery.
• Long-running work — enrichment, scraping, mail delivery — runs in separate worker processes with no inbound network exposure. Nothing on the public web reaches them directly.
• The application sets X-Frame-Options and a frame-ancestors policy, so it cannot be embedded by another site to trick you into clicking something.
• Secrets are held in the deployment platform's encrypted configuration, never in source control.

Subprocessors

These third parties process customer data on our behalf. The list reflects what the application actually calls, and is kept current as that changes.

AI providers are a deliberate exception to the usual arrangement: because you supply the key, that processing happens under your agreement with the provider, not ours.

Reporting a vulnerability

Send it to security@getfullarc.com with enough detail to reproduce it. We will confirm receipt, keep you updated through the fix, and credit you if you would like to be credited.

We will not pursue legal action against researchers acting in good faith: testing only against accounts you control, not accessing or retaining other people's data, not degrading the service, and giving us a reasonable window before publishing.

What we do not claim

FullArc is a young product from a small studio, and it is more useful to you to know the edges of that than to read a page that implies otherwise.

• No SOC 2, ISO 27001 or comparable certification. We have not completed a third-party audit. If your procurement process requires one, we are not there yet.
• No third-party penetration test has been performed to date.
• No contractual uptime guarantee. We do not currently offer an SLA with service credits.
• No comprehensive security audit log. Communication activity is recorded, but per-user administrative action history is not yet something you can export.

Each of these is on the roadmap rather than dismissed. If one of them is a blocker for your business, tell us — knowing which ones people actually need is how they get prioritised.