1 Key Risks
The most critical security risks an operator inherits when deploying this agent in its documented default configuration. Intercom Fin ingests untrusted end-user content across multiple channels into a vendor-managed cloud runtime that accesses customer records and executes external actions through Data connectors and Fin Tasks, while the primary security signal comes from vendor-published compliance certifications and a supply-chain incident history affecting the SDK ecosystem.
2 AIRQ Scores
The four headline scores quantify how exposed the agent is, how damaging a successful attack would be, and how much the agent’s own controls reduce that risk. Intercom Fin's scores reflect a cloud-hosted conversational agent whose damage potential is bounded by the vendor's infrastructure with no operator-side code execution, while defense posture draws on compliance attestations and independent adversarial validation, offset by a supply-chain evidence penalty on the configuration surface.
The moderate attack surface reflects broad untrusted input channels feeding a RAG-grounded reasoning pipeline inside a cloud-hosted runtime, with configuration carrying the sole evidence penalty from two confirmed supply-chain SDK compromises. The low blast radius stems from the absence of shell, file system, and deployment capability, leaving exposure concentrated on outbound connector calls and customer records accessible through the platform. Defense controls draw on vendor-documented input guardrails, compliance-attested monitoring, and configurable action approval workflows.
The table below links each headline score to the architectural characteristics and evidence anchors that drive it. Attack Surface is dominated by the configuration penalty from agent-specific supply-chain compromises; Blast Radius reflects the constrained execution authority of vendor-defined action primitives; Defense Controls capture the vendor's documented control posture validated through compliance certifications and independent adversarial testing.
| Metric | Score | Comments |
|---|---|---|
| AIRQ Score | 2.85 | Evidence base spans agent-specific GitHub Security Advisories for supply-chain SDK compromises, independent AIUC-1 adversarial certification results, vendor trust documentation covering encryption and audit practices, and product architecture documentation describing the RAG pipeline and action primitives. Defense posture is grounded in vendor-published compliance certifications corroborated by third-party adversarial testing. [1][2][4][5] |
| Blast Radius | 2.5 / 10 | The agent runs entirely inside the vendor's cloud with no shell, file system, or deployment capability. Residual exposure concentrates on outbound API calls through configured connectors, workspace-scoped customer data accessible via the Intercom API, and autonomous workflow execution through the Fin Tasks framework. [9][10] |
| Attack Surface | 4.8 / 10 | Most surfaces cluster at the moderate band where the cloud-hosted runtime constrains execution authority to structured action primitives rather than open-ended tooling. Configuration stands apart as the sole penalty-carrying surface, anchored on two confirmed supply-chain compromises of Intercom's client SDK packages that enabled credential exfiltration at scale. [1][2][3] |
| Defense Controls | 9 / 15 | The vendor documents input guardrails through defensive prompting and RAG grounding, execution isolation within cloud infrastructure, action controls through configurable approval workflows, and monitoring through audit trails and compliance certifications. Output guardrails carry the lowest score reflecting the absence of documented dedicated outbound data-loss prevention. [4][5][7][8] |
3 Attack Surface
Attack surfaces are the entry points and interaction patterns through which adversarial input can reach the agent’s reasoning loop and steer its behavior. The dominant exposures are broad untrusted input channels spanning chat, email, social messaging, and API endpoints, a RAG pipeline grounded on operator-curated knowledge bases, and a configuration surface penalized by two confirmed supply-chain compromises of the vendor's client SDK packages.
Most bars sit at the moderate band where cloud-hosted execution and vendor-defined action primitives limit the available attack repertoire. Configuration stands apart as the only penalty-carrying surface, driven by agent-specific supply-chain incidents rather than architectural exposure.
The table below ties each surface to its strongest evidence anchors. The dominant risk pattern is the supply-chain dependency exposure on the configuration surface, while the remaining surfaces reflect the inherent multi-channel input ingestion of a cloud-hosted conversational agent with constrained execution authority.
| Surface | Score | Comments |
|---|---|---|
| User Input | 2 / 4 | Customer messages arriving through chat widgets, email inboxes, social platforms, and the Fin Agent API all feed into the agent's reasoning context. Defensive prompting and OWASP-aligned input handling are documented, but no specifications for an independent prompt injection detection layer are published. [6][7] |
| External Data | 2 / 4 | The RAG pipeline retrieves content from operator-configured knowledge bases including help center articles, public URLs, and PDFs. Retrieved content feeds directly into the generation context, making knowledge base integrity the primary control surface for data poisoning. [7] |
| Memory | 1 / 4 | Memory is session-scoped and does not persist across conversations, constraining any injected context to the duration of a single interaction. Vendor documentation describes the session lifecycle without addressing memory integrity verification or context-poisoning mitigations within a live session. [7] |
| Reasoning | 2 / 4 | The proprietary Fin Apex 1.0 model drives answer generation through a multi-stage pipeline with query refinement and response grounding. The vendor claims OWASP LLM Top 10 alignment and passed independent AIUC-1 adversarial testing, though specific reasoning-layer control architecture and bypass resistance remain unpublished. [4][7][12] |
| Planning | 2 / 4 | Fin Tasks support multi-step workflows that chain actions across external systems. The planning surface is constrained to vendor-defined workflow primitives rather than open-ended tool selection, limiting the scope of adversarial plan manipulation to the configured task repertoire. [10] |
| Tool Execution | 1 / 4 | Tool execution is limited to vendor-defined Data connectors and Fin Tasks operating through structured API integrations. There is no shell access, no arbitrary code execution capability, and no operator-facing scripting surface. Tool authority is bounded by the connector permissions the operator configures. [9][10] |
| Orchestration | 2 / 4 | The agent orchestrates across its RAG pipeline, action primitives, and escalation routing within a single vendor-managed runtime. Workflow execution follows operator-configured rules for when to act autonomously versus escalate to a human agent. The orchestration boundary does not extend to external agent frameworks. [10] |
| Inter-Agent | 0 / 4 | The current architecture operates as a single-agent system with no delegation protocol, no inter-agent messaging bus, and no integration surface for external orchestration frameworks. Every conversation terminates at the Fin instance or escalates to a human operator through the platform's routing rules. [7] |
| Output Processing | 1 / 4 | Generated responses are grounded through RAG retrieval and delivered through the same channels that receive input. No standalone outbound content filter or PII redaction stage is documented as an independent control beyond the RAG grounding mechanism itself. [7] |
| Configuration | 3 / 4 | Two confirmed supply-chain compromises targeted Intercom's client SDK ecosystem. GHSA-54pg-9963-v8vg compromised the intercom-client npm package via a hijacked developer account, deploying an obfuscated preinstall hook that harvested cloud credentials, environment variables, SSH keys, and tokens. GHSA-gr3r-crp5-qrrm compromised the intercom-php Composer package via a hijacked service account with a credential-harvesting dropper. Both carried CVSS 9.3 severity. [1][2][3] |
The Lethal Trifecta is triggered when an agent processes untrusted content, accesses private data, and communicates externally in the same session — the three conditions that turn an isolated prompt injection into full-chain exfiltration. Intercom Fin processes end-user messages from external parties across chat, email, social messaging, and API channels, reads customer records and account data within the operator's Intercom workspace, and transmits data to external systems through Data connectors and Fin Tasks.
Intercom Fin exhibits all three of these conditions in its documented default configuration:
- Untrusted input — Customer messages arriving through chat, email, social channels, and the Fin Agent API originate from parties outside the operator's trust boundary and constitute the primary input vector for the agent's reasoning loop. [6][7]
- Sensitive data — Fin reads customer records, conversation histories, and account details from the operator's workspace, while configured connectors reach into external systems holding order records, subscription state, and billing information on the operator's behalf. [9][10]
- External egress — Fin Tasks and Data connectors send data to external endpoints when processing refunds, updating accounts, and modifying subscriptions, while generated replies are delivered through outbound email and social channels that cross the operator's trust boundary. [10]
4 Blast Radius
The blast radius is what an attacker who controls the agent can reach — which systems they touch, which credentials they read, and which actions they take without operator approval. Blast exposure is bounded by the cloud-hosted architecture with no shell, file system, or deployment capability, concentrating residual risk on outbound API calls to configured connector endpoints, customer records reachable through the platform's data model, and autonomous workflow execution through Fin Tasks.
Half the factors score zero reflecting the complete absence of code execution, file system access, and deployment capability in the agent's architecture. The remaining factors cluster at the moderate band where Data connectors and Fin Tasks provide bounded external action authority.
The table below ties each blast factor to the specific capability evidence and source anchors. The pattern is a narrowly scoped agent whose damage potential concentrates on the business logic actions the operator explicitly configures rather than on runtime infrastructure compromise.
| Factor | Score | Comments |
|---|---|---|
| Code execution | 0 / 4 | The agent has no shell access, no embedded code interpreter, and no capability to execute arbitrary code on any host. All execution occurs within vendor-managed cloud infrastructure through structured API calls to predefined action primitives. [7][10] |
| File system access | 0 / 4 | The agent cannot read, write, or traverse file systems on operator or end-user hosts. Knowledge base content is accessed through the vendor's RAG pipeline API, not through file system primitives. [7] |
| Network access | 2 / 4 | Configured connectors and Fin Tasks issue outbound API calls to process refunds, update accounts, and modify subscriptions on the operator's behalf. Network reach is bounded by the connector endpoints the operator provisions and does not include arbitrary HTTP request capability. [10] |
| Credential access | 2 / 4 | Fin operates inside the operator's workspace with access to customer records, conversation threads, and account details via the Intercom data model. The Fin Agent API enforces minimal OAuth scopes with a documented 97-percent permission-surface reduction relative to general-purpose keys. [9] |
| Autonomous action | 2 / 4 | Fin Tasks let the agent autonomously execute multi-step workflows spanning refund processing, account modifications, and subscription changes. Approval gates requiring human confirmation are available as operator-configurable controls on sensitive action categories. [10] |
| Deployment access | 0 / 4 | Fin cannot modify its own deployment topology, scale the underlying infrastructure, alter platform configuration, or trigger operational changes to the Intercom environment. Infrastructure lifecycle management is entirely vendor-internal with no operator-facing or agent-facing control plane. [8] |
5 Defense Controls
Defense controls are what the agent’s own architecture does to detect, contain, and report attacks before they reach the operator’s systems. Intercom Fin's defense posture benefits from vendor-documented input guardrails, compliance-attested execution isolation and monitoring, and configurable action approval workflows, with the weakest component being output guardrails where RAG grounding is the sole documented constraint on generated content.
Four of five components score at the vendor-documented band reflecting controls whose existence is attested through compliance certifications, vendor documentation, or independent adversarial testing. Output guardrails score lower due to the absence of a documented standalone data-loss prevention layer.
The table below links each defense component to the specific controls the vendor documents and the evidence tier backing each score. Opt-in mitigations that an operator can layer on top of the default posture are not counted toward the score and reappear as hardening tips.
| Component | Score | Comments |
|---|---|---|
| Input Guardrails | 2 / 3 | The vendor documents defensive prompting, RAG grounding constraints, and claims OWASP LLM Top 10 alignment for input handling. Independent AIUC-1 adversarial testing covered jailbreaks and prompt injection scenarios, though the testing methodology and pass rate breakdowns are not publicly available for independent verification. No dedicated ML-based prompt injection scanner is documented. [4][6][7][11] |
| Execution Isolation | 2 / 3 | The agent runs within Intercom's cloud infrastructure with tenant-level isolation documented under the vendor's SOC 2 and ISO 27001 audit programs. Per-conversation sandbox architecture details and the specific isolation primitives separating agent execution contexts across tenants are not publicly described. [5][8] |
| Action Controls | 2 / 3 | Fin Tasks and Data connectors support operator-configured approval workflows that can require human confirmation before sensitive actions execute. The Fin Agent API enforces minimal OAuth scopes. Operators should verify approval gate configuration through the Intercom admin console, as default per-action granularity is not fully specified in public documentation. [9][10] |
| Output Guardrails | 1 / 3 | Response generation is constrained through RAG grounding against the operator's knowledge base corpus, bounding output to documented source material. No standalone outbound DLP layer, content classification gate, or PII redaction pipeline is documented as an independent output control. [7] |
| Monitoring | 2 / 3 | Organizational monitoring is attested through SOC 2 Type II and ISO 27001 audit programs. The platform provides conversation analytics and audit trails, and a public Bugcrowd bug bounty channel handles external vulnerability reports. Fine-grained per-conversation security event detection beyond the platform's standard analytics surface is not publicly specified. [4][5][8] |
6 Hardening Tips
Concrete actions an operator can take to reduce the risks reported above, grouped by which defense control each tip strengthens. The tips below address the scored gaps in each defense component, prioritizing the absence of standalone input filtering, the opaque execution isolation architecture, and the lack of dedicated outbound data-loss prevention for generated responses.
Input Guardrails
Input guardrails intercept adversarial content before it reaches the reasoning loop.
- Policy Require all Fin-facing knowledge base content to pass through an operator-managed content review workflow before publication — counters external data poisoning risk where compromised knowledge base articles could inject adversarial instructions into the RAG retrieval context.
- Configuration Enable and configure Intercom's custom answer controls to restrict Fin's response scope to explicitly approved topic categories — counters the broad input surface where end-user messages across all channels reach the reasoning loop without topic-level filtering.
- Engineering Deploy an independent prompt injection detection layer upstream of the Fin API endpoint — counters the absence of a documented standalone input validation system operating independently of the LLM's own defensive prompting.
Execution Isolation
Execution isolation contains what a compromised agent can do on the host.
- Policy Negotiate with the vendor for documentation of the per-tenant execution isolation architecture — counters the gap where compliance certifications attest to organizational controls but do not describe the runtime sandbox primitives separating agent execution across tenants.
- Configuration Restrict Fin's deployment to a dedicated Intercom workspace separate from internal employee communications — counters the risk of cross-workspace data leakage where a single workspace hosts both customer-facing and internal conversations.
- Engineering Implement network-level monitoring on the Intercom workspace's API integration endpoints to detect anomalous outbound request patterns from Fin Tasks — counters the opaque execution environment where the operator has limited visibility into the agent's runtime behavior within the vendor's cloud.
Action Controls
Action controls govern which tools and actions the agent can invoke autonomously.
- Policy Enable human-in-the-loop approval workflows for all Fin Tasks that modify financial records, process refunds, or update subscription states — counters autonomous action risk where the agent can execute sensitive multi-step workflows without confirmation gates.
- Configuration Apply the minimum necessary OAuth scopes when configuring the Fin Agent API and audit scope assignments quarterly — counters credential access exposure by limiting the agent's data reach to operational requirements, reducing the blast radius if a session is compromised.
- Engineering Restrict Data connector endpoints to an allowlist of approved external systems and review new connector additions through a change management process — counters the network access surface where each new connector endpoint expands the agent's outbound reach.
Output Guardrails
Output guardrails inspect what the agent sends to other systems and users.
- Policy Implement a downstream content review mechanism for Fin responses in channels where generated content reaches external recipients — counters the absence of a documented outbound data-loss prevention layer where RAG grounding alone constrains response content.
- Configuration Configure Intercom's custom answer settings to restrict Fin from discussing topics outside the operator's documented service scope — counters the output processing surface where the agent may generate responses that exceed the operator's intended disclosure boundary.
- Engineering Monitor Fin response content for PII patterns using the Intercom platform's analytics capabilities or a third-party integration — counters the sensitive data dimension where customer records accessible through the workspace could surface in generated responses.
Monitoring
Monitoring captures what the agent did and surfaces anomalies for review.
- Policy Export Fin conversation logs to the operator's SIEM or security analytics platform for correlation with broader security event streams — counters the monitoring gap where vendor-provided analytics operate in isolation from the operator's incident detection infrastructure.
- Configuration Establish alerting thresholds on Fin Task execution volume and failure rates to detect anomalous action patterns that may indicate adversarial manipulation — counters autonomous action risk where bulk or unusual Task execution could indicate a compromised conversation flow.
- Engineering Build automated anomaly detection for Fin conversation patterns that flag statistical deviations in response length, topic distribution, and action invocation frequency — counters the monitoring gap where platform analytics provide aggregate metrics but no real-time behavioral anomaly alerting for adversarial session manipulation.
7 References
The evidence base behind every score and finding in the profile, grouped by source type so the reader can verify any claim. Numbers in brackets throughout the report (e.g. [7, 13]) refer to entries below, listed in citation order.
Selected Vulnerabilities
- GHSA-54pg-9963-v8vg Supply-chain compromise of intercom-client npm v7.0.4 via hijacked developer account (CVSS 9.3). An obfuscated preinstall hook exfiltrated secrets, environment variables, and SSH keys from consumer build environments. Patched by reverting to v7.0.3.
- GHSA-gr3r-crp5-qrrm Supply-chain compromise of intercom-php Composer v5.0.2 via hijacked service account (CVSS 9.3). A malicious Composer plugin acted as a credential-harvesting dropper targeting downstream integrator build pipelines. Patched by reverting to a clean commit.
- intercom-client npm compromise analysis Technical analysis of the intercom-client npm supply-chain attack covering the Bun runtime dropper mechanics, credential exfiltration targets, and downstream CI/CD blast radius for affected consumers.
Selected Research
- AIUC case study on Intercom Fin certification Case study documenting how Intercom achieved AIUC-1 certification through independent adversarial testing
Vendor Documentation
- Security at Fin Vendor security page covering encryption, IaC, audit trails, pen testing, and Bugcrowd program
- AI data privacy and safety at Intercom Blog post on prompt injection defenses, LLM data contracts, RAG grounding, and OWASP alignment
- The Fin AI Engine Documentation of the RAG architecture, multi-stage safety controls, and OWASP LLM Top 10 claims
- Fin trust and reliability Trust page listing SOC 2, ISO 27001, ISO 42001, AIUC-1, HIPAA, GDPR, and CCPA compliance
- Fin Agent API setup API token security model with minimal OAuth scopes and 97-percent permission surface reduction
- Fin Tasks and Data connectors Product docs on Data connectors and Fin Tasks for external system actions
Other Sources
- AIUC-1 security standard AIUC-1 adversarial robustness testing requirements and unauthorized action prevention mandates
- Fin Apex 1.0 model page Description of the Fin CX Model Suite and the proprietary Fin Apex 1.0 answer generation model