Fyxer AI security review — full inbox access is the highest-risk AI category

Not all AI tool integrations carry the same risk. A code completion tool that sees one file at a time is categorically different from a tool that has persistent, broad access to an entire communication channel. Fyxer falls into the latter category.

The risk is not that Fyxer is malicious — it is that the access pattern itself creates exposure. To deliver its core features (inbox categorisation, draft replies in the user's tone, follow-up tracking), Fyxer must:

• Read all emails in Inbox and Sent Items
• Understand conversational context across threads
• Learn writing patterns from historical sent messages
• Access calendar data for scheduling suggestions
• Optionally join meetings and transcribe them

This means the AI system has access to attorney-client communications, board discussions, M&A signals, HR conversations, customer PII, financial data — whatever passes through email. The review must account for theworst-case content in the mailbox, not the average case.

Based on Fyxer's public documentation, the data handling posture is as follows:

What Fyxer accesses: emails in Inbox and Sent Items (not other folders by default), calendar events for scheduling, and — if the Meeting Notetaker is enabled — live meeting audio via Google Meet, Microsoft Teams, or Zoom.

What Fyxer claims not to do: send emails on the user's behalf (drafts only, user must press send), access shared or group inboxes, use customer data to train public or third-party AI models, retain access after disconnection or account deletion.

Data residency: Fyxer states that all customer data is stored and processed exclusively in the EU/EEA, on Google Cloud Platform infrastructure in Belgium and the Netherlands. This is a strong claim — it means no cross-border transfers to US-based AI inference providers, which would be a critical finding if untrue.

Data retention: Fyxer's documentation states that disconnection or account deletion immediately revokes access and stops processing. The exact retention period for processed data (embeddings, style models, conversation context) is not publicly specified.

Fyxer connects via OAuth 2.0 through Google Workspace APIs (Gmail + Google Calendar) or Microsoft Graph APIs (Outlook + Microsoft 365). This means Fyxer never sees or stores email passwords — a baseline hygiene requirement that is met.

For Microsoft 365 deployments, admin consent is required via Microsoft Entra ID (formerly Azure AD). This is the correct pattern for enterprise: it gives IT visibility into what permissions are being granted and to whom.

Fyxer states it follows a “principle of least privilege” with no blanket or administrative mailbox access, no access to shared or group inboxes, and only permissions required for enabled features being requested.

What to verify in your review:

• Exact OAuth scopes requested. “Least privilege” is a claim. The actual scopes granted in Entra ID or Google Admin Console are the evidence. For an email assistant that reads all mail and calendar, the minimum viable scopes are broad by nature — but verify there are no write-level scopes beyond draft creation.
• Scope creep over time. OAuth grants are point-in-time. If Fyxer ships new features (e.g., auto-scheduling, send-on-behalf), they may request additional scopes. Your review should establish how scope changes are surfaced to admins.
• Revocation completeness. When a user disconnects, are all tokens revoked? Is cached data (embeddings, style models) also purged, or only live access?
• Multi-tenant isolation. In a team deployment, can one user's Fyxer instance access another user's email data? Fyxer's docs say team members only see summaries if explicitly shared — but the isolation mechanism (per-user encryption keys, logical separation, or just application-layer access control) matters.

This is where Fyxer's public documentation has the most significant gap. Fyxer repeatedly states that customer data is “never used to train third-party AI models.” This addresses the training question. It does not address the inference question.

To draft replies in a user's voice, categorise emails, and generate meeting summaries, Fyxer must run inference against some language model. The critical questions are:

• Which LLM powers Fyxer? Is it a self-hosted model, a fine-tuned open-source model, or a third-party API (OpenAI, Anthropic, Google Vertex)? Fyxer's public documentation and security page do not name the model provider.
• Where does inference happen? If Fyxer uses a third-party LLM API, email content is sent to that provider's infrastructure for processing — even under a zero-training agreement. This may conflict with the EU-only data residency claim unless the inference provider also operates in EU regions.
• What is the sub-processor chain? Fyxer's Trust Center lists approved sub-processors, but this page is access-restricted. During procurement, obtaining and reviewing the full sub-processor list is essential — particularly to confirm whether an LLM inference provider appears.
• What data reaches the model? Is the full email body sent for inference, or are only extracted features (summaries, embeddings) passed? The difference matters for data minimisation under GDPR Article 5(1)(c).

Fyxer states it is “Google-verified and Microsoft-verified” — meaning it passed marketplace security reviews from both providers. This is a positive signal but not a substitute for your own assessment: marketplace reviews verify OAuth implementation and basic security hygiene, not the full AI pipeline.

Fyxer's stated compliance certifications are strong for a company of its size:

• SOC 2 Type II — audited controls over time, not just design
• ISO 27001 — information security management system
• HIPAA compliance — relevant for healthcare organisations
• GDPR compliance — EU data protection
• CASA Tier 2 — Google's Cloud Application Security Assessment

Fyxer AI Limited is a UK-incorporated company (company number 15189973). Data is stored in EU/EEA on GCP. The UK adequacy decision from the EU means data can flow between the UK entity and EU infrastructure without additional safeguards — but this should be confirmed in the DPA.

Email provider terms compliance: both Google and Microsoft impose restrictions on what third-party apps can do with email data accessed via their APIs. Google's API Services User Data Policy requires limited use: data accessed through Gmail APIs can only be used to provide the user-facing features they consented to. Microsoft Graph has similar restrictions. Fyxer's Google-verified status suggests compliance, but the specifics of how “learning your writing style” maps to these policies should be confirmed during review.

A security review is only as good as the evidence available. Based on Fyxer's public documentation as of August 2026, the following questions are not answered:

None of these are unusual questions. Any vendor at Fyxer's maturity level (SOC 2 Type II, $17M ARR) should be able to answer them during a procurement security review. The gap is in public documentation, not necessarily in Fyxer's actual practices.

If you are evaluating Fyxer for enterprise deployment, these are the minimum items your security review should cover:

1. Obtain the sub-processor list from Fyxer's Trust Center (requires access request). Confirm whether an LLM inference provider is listed and where their infrastructure operates.
2. Verify OAuth scopes in your identity provider (Entra ID or Google Admin Console). Document the exact permissions granted and confirm no write-beyond-draft scopes are present.
3. Request the DPA and confirm data residency claims are contractually binding, not just stated in marketing materials.
4. Ask about prompt injection defences. Email is an attacker-controlled input channel. If a malicious email can influence how the AI processes other messages or generates drafts, that is a live vulnerability.
5. Confirm the “no send” boundary enforcement. Fyxer states it cannot send emails. Is this enforced at the OAuth scope level (no send permission granted) or at the application level (permission exists but the app chooses not to use it)? The former is verifiable; the latter requires trust.
6. Assess the Meeting Notetaker separately. Meeting transcription is a different risk profile from email processing — it involves audio data, real-time processing, and participant consent requirements. If you do not need it, do not enable it.
7. Define re-assessment triggers. What changes would require a new review? New OAuth scopes requested, model provider change, auto-send feature addition, expansion from individual to shared-mailbox access.

Based on publicly available information, a reasonable starting position for Fyxer's disposition is restricted pilot — approved for a defined user population with specific conditions, pending answers to the evidence gaps above.

The key conditions that would typically attach to this disposition:

• LLM provider and inference residency confirmed in writing
• Sub-processor list reviewed and accepted
• Meeting Notetaker disabled unless separately assessed
• OAuth scopes documented and monitored for changes
• User population limited to roles where email sensitivity is manageable (not C-suite, legal, or HR initially)

The path from restricted pilot to full production would require closing the evidence gaps, confirming prompt injection mitigations, and establishing audit log access for security operations.

Fyxer's compliance posture (SOC 2 Type II, ISO 27001, GDPR, HIPAA) and its data residency claims are among the strongest in the AI email assistant category. The vendor is not the concern — the access pattern is. Full inbox access to an AI system is inherently high-risk, and the review should be proportionate to that access level regardless of the vendor's certifications.