Intercom Fin Security: What Teammate Roles, API Tokens, and Regional Hosting Cover
Intercom secures Fin and the broader workspace through three separate mechanisms: teammate seat types and custom roles, API access tokens and OAuth scopes, and Regional Data Hosting across the US, EU, and Australia. Each answers a different question about who can reach the workspace and where data sits. None evaluates the content of a specific customer conversation Fin resolves on its own. This piece maps where each control ends.
A workspace running Intercom's Fin AI Agent has three separate controls deciding what happens before a customer conversation reaches a model. Teammate seat types and custom roles decide which human can configure Fin or view its conversations. API access tokens and OAuth scopes decide which integration can call Intercom's platform at all. Regional Data Hosting decides which geography a workspace's data physically sits in. I want to walk through what each one actually secures, then the request none of them evaluate.
TL;DR
- Intercom's three seat types (Admin, Teammate, Lite Teammate) and Expert-plan custom roles control what a human can configure or view inside the workspace; each teammate holds exactly one role.
- API Access Tokens grant an integration full workspace access by default, similar to a password, while OAuth apps get Standard or Intercom-approved Extended scopes.
- Regional Data Hosting pins a workspace's data to the US, EU (Dublin), or Australia (Sydney), with no direct cross-region migration once set.
- None of the three evaluates the content of a specific Fin conversation against the sensitivity of the customer data inside it.
Teammate roles and custom roles authorize the person, not the conversation
Intercom assigns every human user one of three seat types: Admin, with full workspace control; Teammate, scoped by role; or Lite Teammate, limited to email-based interactions. Custom roles, available on the Expert plan, let an organization define reusable permission sets, and SCIM group sync can assign those roles automatically from an identity provider. A teammate holds exactly one role at a time, and Intercom blocks a user from editing their own role, a sensible guard against self-escalation.
That system answers who can view the Fin AI Agent's settings, adjust its content sources, or read a customer's conversation history inside the Intercom inbox. It does not evaluate what Fin actually says inside a given conversation, or whether the specific account data a customer shared should have been eligible for an AI-generated response at all. A support lead with full Teammate access to Fin's configuration is authorized to configure the feature. That authorization says nothing about whether a specific reply, generated automatically, handled a specific customer's sensitive data correctly.
Access tokens and OAuth scope the integration, not the caller
Programmatic access to Intercom's platform runs through two models. Access Tokens for private, internal apps grant broad workspace access and are meant to be treated like a password. Public apps use OAuth, with Standard scopes available by default and Extended scopes requiring Intercom's approval. Either way, the resulting credential authenticates an integration, and every call that integration makes inherits the same scope, regardless of which employee or automated workflow triggered it.
A workspace wiring Fin Actions into an internal order-management system typically holds one Access Token for that integration. Every Fin Action call to the backend uses the same token. The token secures which integration can reach the backend API. It carries no field for which specific customer conversation, or which category of account data, triggered a given backend call.
Regional Data Hosting isolates storage location, not conversation content
Regional Data Hosting lets a workspace pin its primary data to the US (us-east-1), the EU (Dublin, eu-west-1), or Australia (Sydney), and Intercom's documentation notes there's no direct migration path between regions once a workspace is set up. That satisfies a genuine data-residency requirement for customers under EU or Australian data-localization expectations. Billing and support-related account details can still travel outside the chosen region, which is worth knowing before treating regional hosting as an absolute boundary.
Regional hosting answers where data is stored. It does not evaluate what data enters a Fin conversation in the first place, or whether a specific reply should have been withheld given the customer's data classification. Intercom holds SOC 2 Type II, ISO 27001:2022, ISO 27018, ISO 27701, and ISO/IEC 42001:2023 certifications, along with a HIPAA attestation, which is a genuinely strong compliance posture for the platform layer. None of those certifications inspect the content of an individual Fin response, which is the same gap I found looking at Fin's own conversation and activity logs.
The request-level gap, and a reminder from April 2026
Stack teammate roles, scoped tokens, and regional hosting together and the result is a well-administered workspace, a controlled set of integrations, and data sitting in the right jurisdiction. What none of them provide is a check on the specific content crossing into a specific Fin conversation at the moment it happens, the same post-authentication gap that shows up across most AI-enabled SaaS products. On April 30, 2026, Intercom disclosed that malicious versions of its intercom-client npm package and intercom-php package had been published under compromised maintainer credentials; both were pulled within hours, and Intercom stated it found no evidence of unauthorized access to customer data. The incident hit developer tooling, not Fin's conversation path, but it's a concrete reminder that account-level and workspace-level controls protect a different surface than the one a live AI conversation touches.
DeepInspect
This is the gap DeepInspect closes for the AI traffic a support organization controls directly, including Fin Actions calling internal systems and any other LLM tools running in the same environment. DeepInspect sits inline as a stateless proxy in front of any HTTP-based LLM endpoint, evaluating the identity behind a request, the role it carries, and the classification of the data inside it, before the request reaches a model.
Teammate roles, access tokens, and regional hosting keep governing what they already govern well: who can administer the workspace, which integration can call the platform, and where the data physically sits. DeepInspect adds the layer none of them were built to provide, a per-request, identity-bound policy decision independent of how Fin itself is configured, with a signed record for every decision. Book a technical deep dive at deepinspect.ai.