Built so AI can act without anyone losing control
FixControl is a governance layer. The AI proposes a change; your policy and your people decide whether it goes ahead; and every decision is written to an audit trail you can replay. Isolation, approval and audit are built into how it works.
Every customer operates in an isolated environment
In plain terms: your data can never be seen by another organization using FixControl. Isolation is enforced in three layers: the request authenticates, the application filters to your own organization (its tenant), and Postgres row-level security has the final say — running in strict mode, which hosted production refuses to boot without. No single mistake takes the wall down.
Layered enforcement
Authentication, tenant filtering and Postgres row-level security all have to agree before a row is returned. A query that arrives without a tenant context reads zero rows rather than someone else's data. Inside a tenant, project roles and memberships scope access further: project-bound work is deny-by-default for non-members.
No cross-tenant reads — even by URL
A user in another tenant can't open your issues, emails or codebases, even from a direct link, and knowledge search stops at the tenant boundary.
Credentials scoped to your tenant
Provider tokens and secrets are encrypted with AES-256-GCM and stored in rows only your tenant can read.
Staff access is audited
A cross-tenant read by FixControl staff runs through the same isolation path, needs a written reason, and lands in your tenant's audit log.
Human approval before high-risk actions
By default, nothing ships without a recorded human decision. Where a tenant turns on more autonomy, that choice is explicit, bounded by policy and written to the audit log.
Approval gates on risky work
A plan, a risky patch, a deployment or a customer-facing reply stops at a gate until someone approves it, rejects it or asks for changes.
A frozen decision ledger
Each verdict freezes who decided, in which role, over which evidence, under which policy version and through which channel, so a decision can't be quietly rewritten later.
Two-person rule on destructive actions and customer e-mail
A destructive admin action needs a token one admin mints and a different admin spends — single-use, short-lived, rate-limited and audited. Outbound customer e-mail follows the same four-eyes principle: the requester never approves their own message, and the approved content is frozen — any change invalidates the approval.
No silent external writes
A write to Slack, Jira or GitHub goes through a governed outbox that retries on failure and shows the failure when it can't recover. Nothing reaches an outside system without leaving a trail.
- 01
Suggested only
DefaultThe AI prepares the work; an operator releases it. This is where every tenant starts.
- 02
Auto-draft
Opt-inThe AI drafts the artefact ahead of time; an operator still releases it.
- 03
Auto-apply, policy-scoped
Opt-in + guardedReleased without an operator click — off unless a tenant turns it on, bounded by policy and loud in the audit log. It never becomes the default for an existing tenant.
Every recommendation carries its evidence
An approver shouldn't have to take the AI's word for anything. Each recommendation carries the evidence it rests on, and it is verified before the decision, not after it.
Evidence behind every proposal
A plan or patch cites the documentation, tickets and code it drew on, so the reviewer can see what it's based on and why.
Sandbox verification first
A proposed change is verified in an isolated sandbox — a containerized environment with a disposable database, separate from your production systems; your deployment's configuration determines the exact isolation. Where configured, the supporting services the application needs are started alongside it, without internet access and without access to your source code, and removed after the run. A passed verification records the exact versions it passed against. The results travel into the approval before anything touches your repository.
Evidence lineage in the timeline
The mission timeline links each decision back to the evidence it was made on, from intake through to deployment.
Capability-level integration health
Connection status is tracked per capability, so a broken write path shows as broken instead of hiding behind one green checkmark.
Replay every operational decision
In plain terms: when someone asks who decided what, and why, you answer from the record — not from memory. The audit log is tamper-evident: each entry is hash-chained to the one before it, per tenant. Change a single row and every hash after it stops matching — which export-and-verify then catches.
Tamper-evident chain
Each audited event records the actor, the action, the target and the fields it changed, hash-chained so history can't be edited without leaving a break.
Signed audit export
Your tenant's CSV export ships inside a signed envelope, so a verifier outside FixControl can re-check the chain on their own.
Mission replay
A mission keeps its whole timeline — intake, triage, plan, verification, approvals, delivery — so you can reconstruct how any outcome happened.
365-day retention by default
Audit events are kept for a year by default. Even if that setting is lowered, a hard 90-day floor refuses to delete anything younger.
What the AI may do on its own — and what it may not
The clearest security statement we can make is the boundary itself: what runs without a decision, what waits for one, and what we refuse to promise.
AI may do this on its own
- Classify and route incoming work
- Answer ticket questions in authenticated Slack, Teams and in-app chat
- Draft replies, plans and proposed changes
- Analyze code and prepare patches for review
- Run configured read-only checks in the sandbox
These wait for a recorded decision
- Customer-visible replies (Freshdesk; Jira Service Management where configured)
- Comments and status changes on external trackers
- Opening pull or merge requests
- Deployment promotions and CI/CD deployment verdicts on configured gates (Argo, GitHub Actions, GitLab, Jenkins)
- Any other external write, as set by your policy
What FixControl does not claim
- Hallucination-free AI — evidence and approval gates exist precisely because models can be wrong
- Replacing human responsibility — approvers remain accountable for what they approve
- Legal or compliance liability transfer — FixControl provides governance evidence; contractual terms live in the agreement
Where certification stands, honestly
FixControl does not yet hold third-party certifications such as SOC 2 or ISO 27001, and we say that plainly rather than imply otherwise. What we offer today is direct evidence: control documentation, a reviewable audit chain, and access to the people who built the system.
Third-party certifications — not yet
Certification audits have not yet been completed, and we do not claim certifications until they are. Certification is on the roadmap; ask us for the current status. Architecture, controls and audit evidence can be reviewed directly during procurement or a pilot, under NDA where needed.
External penetration test — not yet
An external penetration test has not yet been performed. The codebase ships with automated security guards in CI — route authentication, tenant-isolation coverage, external-write coverage — and the architecture is open to review during procurement.
Responsible disclosure
Found a vulnerability? Report it to contact@fixcontrol.ai — the address is published in /.well-known/security.txt. We confirm receipt and keep you informed while it is fixed.
Procurement & security reviews
Security questionnaires, an architecture overview and data-processing documentation are provided during onboarding and procurement review, answered directly by the team that builds the product.
Data processing agreement (DPA)
Where FixControl processes personal data on behalf of your organization, roles, subprocessors and deletion terms are recorded in a data processing agreement. The DPA is part of onboarding and available on request via contact@fixcontrol.ai.
Guided onboarding as a control
Every rollout starts with guided onboarding that validates tenant boundaries, approval gates and audit behavior together with your team, on a scope you define. Governance is in place before the first automated action — a security control built into how FixControl goes live.
Where your data lives and which models touch it
Straight answers to the questions a security review asks first. The privacy statement carries the formal subprocessor list; this is the operational picture.
Hosting & data residency
The hosted service runs on infrastructure in the European Union (the Netherlands), operated for FixControl by TransIP, a Dutch hosting provider. Enterprise private deployments are scoped per engagement.
AI model providers
Anthropic is the default model provider. A tenant can configure others — OpenAI, Google, OpenRouter, or a locally hosted model — and which provider processes a request follows that configuration. Embeddings can run on FixControl-managed infrastructure instead of a third party.
No training on your data
FixControl does not train models on customer data — there is no training pipeline in the product. Calls to model providers are inference requests governed by the provider's API terms; the defaults are named in the privacy statement's subprocessor list.
Default subprocessors, named
Three subprocessors underpin the core service: TransIP B.V. (hosting, the Netherlands), Anthropic PBC (AI models, the default provider) and Resend Inc. (transactional email). The formal, current list — including configuration-dependent providers — lives in the privacy statement.
Key management
Integration credentials are encrypted at rest with AES-256-GCM under a per-tenant data key, wrapped by a master key ring that exists only on the server. Decryption happens server-side only and failed decrypts are audited. Keys are FixControl-managed; there is no customer-managed key option yet.
Account security, plainly
Self-serve accounts use passwords (bcrypt-hashed) with self-service reset and everywhere-at-once session revocation. Built-in TOTP two-factor authentication (authenticator app + recovery codes) can be enabled per user and required per tenant; admin and platform roles require a 2FA-satisfied session. OIDC SSO sessions carry MFA from your identity provider instead.
Customer database access
The optional database connector is read-only (PostgreSQL), TLS-verified, restricted to allowlisted query shapes and approval-gated. Connections originate from FixControl's servers; concrete network details are shared during onboarding.
Private infrastructure — outbound only
Private Kubernetes, Argo, Jenkins and GitLab connect through the FC Agent: a service in your own environment that dials out to FixControl over HTTPS and executes signed, expiring, single-use operations. No inbound access, no VPN; your allowlists and least-privilege RBAC bound what it can do, and its credentials stay in your cluster. Offered during pilot onboarding.
Backups & continuity
Databases are backed up automatically every day. No contractual RPO/RTO or availability commitment is published yet; Enterprise agreements can include committed terms.
Deletion & export
Cancelling soft-deletes your tenant with a restore window, after which an irreversible purge removes the data. Your audit history remains exportable as a signed CSV until then.
What FixControl won't do, on purpose
A few capabilities are left out deliberately. Leaving them out is what keeps the governance promise honest.
No auto-merge
A patch arrives as a pull or merge request; merging it stays a deliberate operator action.
No silent autonomy
A new automation level never switches itself on for an existing tenant. You opt in to it, under a policy you set.
No cross-tenant analytics
There is no shared-insights surface across tenants. A cross-tenant operation needs platform-admin scope and is audited.
No 2FA back doors
Disabling two-factor authentication requires the user's password plus a live factor, and the platform-admin emergency reset demands a written reason, is audited, revokes every session and notifies the user.
The baseline underneath
The uneventful parts, handled continuously.
TLS everywhere
Certificates are managed automatically at the edge, and traffic stays encrypted in transit.
Encrypted secrets
Provider tokens and secrets are encrypted at rest with AES-256-GCM.
Session control
Sessions last 24 hours, can be revoked everywhere at once, and sign with keys that rotate on a schedule.
Enterprise identity
OIDC SSO carries MFA from your identity provider, and SCIM 2.0 provisions and deprovisions accounts automatically.
Password hygiene
Local passwords are stored only as bcrypt hashes, so there is nothing to recover in plain text.
Signed webhooks
An outbound webhook carries a timestamped HMAC-SHA256 signature, so the receiver can confirm it's genuine and not a replay.
Security FAQ
Can the AI ship a change without anyone approving it?+
Will my customers see that I use FixControl?+
Which FixControl staff can access my data?+
Is the audit log resistant to insider tampering?+
How do I enforce MFA?+
Are you SOC 2 or ISO 27001 certified?+
Where is my data hosted?+
Is my data used to train AI models?+
Can FixControl scale with us?+
Security questions deserve real answers
The full security documentation walks through isolation, identity, the audit chain, incident response and the deliberate limits in detail.