Security & audit

Shared responsibility

FixControl runs as a cloud service. FixControl operates the platform infrastructure — TLS certificates, JWT key rotation, rate limiting, database isolation. On your side, you configure account security, identity, and visibility.

Tenant isolation

Every tenant's data is fully separated. Other FixControl customers cannot see your issues, emails, customer data, codebases, or memory rules. Enforcement is layered across authentication, application-level filtering, and database-level row security, with strict mode required at boot in hosted production.

In practice:

• Your Gmail tokens live in a row only your tenant can read.
• A user from another tenant cannot fetch one of your issues, even by URL.
• Knowledge chunks are never searched cross-tenant.
• Even cross-tenant reads by FixControl platform staff go through the same isolation path and are audited.

Audit log

The audit log is tamper-evident. Every state change writes a row with a per-tenant sequence and a hash chained to the previous row. Modifying any row breaks every subsequent hash, which an export-and-verify workflow detects.

Every audited event records the actor (a user, API key, or system), the event name (e.g. patch.approved), the target, the tenant, and the affected fields (with sensitive values redacted). View it under Settings → Audit.

Default retention: 365 days. Audit export (per tenant, CSV in a signed envelope so a downstream verifier can re-check the chain) is available under Settings → Audit → Export. The platform-admin export (all tenants, staff only) is NDJSON.

The inbox row event log (the timeline you see in inbox detail) is a separate stream — operator UX, not security audit. Don't conflate.

Sessions

• Default session duration: 24 hours.
• Log out on this device: top right.
• Log out everywhere (revoke sessions): Settings → Users → "Revoke sessions" on the user. Useful when a laptop is stolen or a colleague leaves.

Signing keys rotate on a schedule. Revoked sessions stop working immediately, even if the token signature is still otherwise valid.

Passwords

Stored as bcrypt hashes — not plain text, not recoverable. A forgotten password means reset.

• Minimum 8 characters.
• No complexity rules on letters/digits/symbols, but trivial passwords are strongly discouraged.
• MFA: enforce via an OIDC IdP (Okta, Azure AD, Google Workspace) — local-password MFA is intentionally not provided. See Users & identity → OIDC SSO.

Identity

See Users & identity for setup.

Two-person rule for destructive admin actions

A catalog of destructive operations (tenant deletion, secret-rotation, mass deactivation, audit-retention change, etc.) requires a token minted by one admin and consumed by another:

1. Admin A goes to Admin → Approvals and mints a token for the action + target.
2. Admin A hands the token to admin B (out of band, e.g. Slack DM).
3. Admin B's destructive call carries the token; the system consumes it.
4. Token is single-use, 10-minute TTL.

Each gated action is also rate-limited per admin per action. Mints, consumes, denials, and rate-limit hits are all audited.

During an incident

Suspicious traffic or a possibly leaked password:

1. Revoke sessions for the affected account (Settings → Users).
2. Reset the password or disable the user.
3. Inspect the audit log for activity by that account in the affected window.
4. Notify us via /contact — we can dig deeper into platform logs and assist with the chain re-verification if you need it.

What is intentionally not supported

• Auto-merge of patches. A patch is delivered as a PR or commit; merging is an explicit operator action.
• Multi-IdP per tenant. One OIDC provider per tenant.
• MFA at the FixControl password layer. Use OIDC + IdP-enforced MFA.
• BYOK (bring your own encryption key). Not offered today.
• Cross-tenant analytics. No "shared insights" surface; cross-tenant operations require platformAdmin and are audited.
• Self-service tenant deletion via API. Goes through a manual support flow with a confirmed hold window.
• Auto-mapping SCIM groups to FixControl roles. Groups are stored; mapping is a manual admin step.

Staged rollout philosophy

Every new automation surface ships in this order, never reversed:

1. Suggested only — AI prepares; operator releases. Default for every tenant.
2. Auto-draft, opt-in — AI prepares the artefact; operator still releases.
3. Auto-send / auto-apply, opt-in + guarded — released without operator action; off by default. Every automatic release is written to the audit log.

A new automation level is never the default for an existing tenant. You opt in.

FAQ

Will my customers see that I use FixControl? Not visible to them — replies come from your own support address, no "Powered by" badge.

Do you store emails from Gmail in your database? The relevant fields (sender, subject, body) yes, for inbox tracking. Delete an issue and the related inbound email is cascade-deleted.

Which FixControl staff can access my data? A small support team, only for explicit incident investigation, after your approval. Every staff access is logged in the audit chain and surfaces under your tenant's audit log.

Is the audit log resistant to insider tampering? The chain hashing means any modification to a row breaks every subsequent hash, which an export-and-verify workflow detects. The export endpoint is signed so a downstream verifier can re-check independently.

Can I get a static IP for outbound webhooks from FixControl? Not currently offered. Outbound webhooks carry an HMAC signature (X-FixControl-Signature), so receivers verify authenticity cryptographically instead of by source IP.