Solutions

Industries

Partners

Resources

Book a Demo

Blog

Table of Content

The Risks of Connectors in Your AI Applications

Connectors increase the scope of what your AI can do, increasing the indirect prompt injection attack surface and the risk of irreversible actions.

AI Connector Risk Threat Model
Assess connector risks today

The Threat Model

Across AI applications, ‘connectors’ are a common means of expanding an agent’s capabilities to existing systems and thereby, its utility. However, connectors also expand the risk surface for indirect prompt injection attacks. New sources of untrusted data may contain prompt injections, and new sensitive data becomes at risk of exfiltration. Furthermore, agents can initiate new downstream actions taken across third-party surfaces. In total, the surface to audit is substantial.

Risks from connectors can be modeled similarly across most major AI applications. There are three pillars that matter:

  1. Untrusted external data intake: data pulled into the model’s context can contain prompt injections that manipulate the AI model.

  2. Sensitive internal data intake: any data pulled into the model’s context is at risk of exfiltration

  3. Downstream actions: interactions the model has with external systems can cause lasting effects, such as exfiltrating data by communicating with a third party or modifying a connected internal system.

These three pillars draw back to Simon Willison’s Lethal Trifecta for Agents. When an agent operates on sensitive data alongside untrusted data, with the opportunity for external actions, prompt injections in the untrusted data can manipulate the AI model to expose the sensitive data through an external action.

When choosing connectors, it is crucial to consider the cumulative effect of the connectors towards the ‘lethal trifecta’ existing in one’s environment. Consider an agent enabled with the following:

  • Confluence connector (read access to internal knowledge-base articles)

  • Zendesk connector (able to read and reply to customer support tickets)

Enabled together, a customer who files a ticket carrying a prompt injection can manipulate the model into reading a sensitive Confluence article and posting it back as a Zendesk reply, surfacing material intended for internal staff only to the customer.

Connectors risk when combined with existing functionality

Most AI apps ship with built-in capabilities that already satisfy one or two pillars of the trifecta before any connector is enabled. For example:

  • Built-in web search and browsing can provide both untrusted data ingestion (any web page can carry an injection payload) and an outbound channel (every fetch is a GET request the receiving server can log).

  • File uploads can introduce sensitive or untrusted data depending on the origin.

  • Memories and Projects can carry sensitive context from one session into future sessions.

As such, it is important to audit connectors in the context of an application's existing functionalities.

Applications with Connectors and How to Configure Them

Every major AI application exposes connector governance to admins, but the controls live in different places and offer different granularity. The table below maps where Owners and admins go to enable, disable, or scope connectors across the five most widely deployed enterprise AI apps.

Application
Admin path to connector configuration
Path
Organization settings → Connectors → Add
claude.ai/admin-settings/connectors
Controls
  • ›Enable or Delete per connector
  • ›Per-tool gating: Customize → Connectors → Select Tool → Tool permissions → Always allow / Needs approval / Blocked
Path
Workspace settings → Apps
chatgpt.com/admin/apps
Controls
  • ›Per-app enable/disable: Directory tab to enable; Enabled tab → ••• → Disable to revoke
  • ›Per-app Action control: All actions / Read only / Custom. When Custom is selected, new actions added later are governed by Enable all new actions / Only enable new read actions / Disable new actions
  • ›RBAC: Workspace settings → Permissions & roles → Custom roles → [role] → Connected data → Allow members to use apps → Select
Apps enabled by default on Business; disabled by default on Enterprise / Edu — admins must explicitly enable each app.
Path
M365 Admin Center → Copilot → Connectors
admin.cloud.microsoft/#/copilot/connectors
Controls
  • ›Enable or Disable each source for users
  • ›Staged Rollout — limits visibility to specific users
Path
Admin console → Connectors → per-connector enable/disable
Controls
  • ›Org-wide on/off per connector — when disabled at the org level, members do not see the connector in their personal settings at all
Deploying another AI tool?

An Audit of Common Connectors

When evaluating whether to enable a given connector, walk it through the three pillars: does it bring untrusted data into the model's context, does it allow the model to access sensitive data, and does it create a downstream action path?

Connector
Inputs
Outputs
Inputs
Sensitive
Financials, contracts, credentials, PII, legal correspondence.
Untrusted
Inbound messages, subject lines, and attachments from any external sender.
Outputs
Send email. Schedule send. Create, update, and send drafts. Forward. Archive or delete. Apply labels (single and bulk). Create labels.
Inputs
Sensitive
Attendees, agendas, locations, attached documents.
Untrusted
Event titles, descriptions, and locations from inbound invites sent by any external party.
Outputs
Create, update, and cancel events. Add event attachments. Respond to invites on the user's behalf. Find available time slots. Modify shared-calendar events.
Inputs
Sensitive
Documents, spreadsheets, decks, financial models, customer data, board materials.
Untrusted
Externally shared files, comments from external collaborators, suggesting edits, files imported from outside sources.
Outputs
Create files. Batch-update documents, spreadsheets, and presentations. Import and export files. Duplicate sheets across spreadsheets. Generate presentations from templates.
Inputs
Sensitive
Internal sites, document libraries, file shares, departmental data.
Untrusted
Files and pages uploaded or contributed by external guests; externally shared sites.
Outputs
Upload, update, copy, and move files. Create folders (single and bulk). Delete or restore items. Generate sharing links. Invite recipients to items. Manage item permissions.
Inputs
Sensitive
Internal channels, DMs, file uploads, incident channels.
Untrusted
Slack Connect channels shared with external orgs, third-party app messages, file uploads.
Outputs
Send messages. Schedule messages. Send to drafts. Create channels and DMs. Create and update canvases. Add reactions. Edit or delete prior messages.
Inputs
Sensitive
Proprietary source code, committed secrets, internal issues, security advisories.
Untrusted
Issue bodies, PR descriptions, review comments, commit messages, and README files from external contributors.
Outputs
Create, update, and delete files. Create branches and commits. Create, merge, and update pull requests (including auto-merge and reviewer assignment). Create issues and comments. Manage labels and assignees. Rerun workflow jobs.
Inputs
Sensitive
Roadmap, security tickets, customer escalations, internal estimates.
Untrusted
Jira Service Management portal tickets and comments from external collaborators.
Outputs
Create issues. Edit issues. Add comments. Transition status. Add worklog entries. Link issues.
Inputs
Sensitive
Internal wikis, planning docs, meeting notes, team knowledge bases.
Untrusted
Guest-collaborator pages and comments, content imported from web pages and external files, embedded URLs, shared-database rows.
Outputs
Create pages. Update pages. Move and duplicate pages. Create databases. Update data sources. Create and update views. Add comments.
Inputs
Sensitive
Customer PII, contact details, opportunity values, contract terms (CCPA / GDPR scope).
Untrusted
Lead web-to-form submissions, email-to-case ingestion, customer-populated free-text fields (case descriptions, survey responses).
Outputs
Create records (any sObject). Update records. Execute SOQL queries. Create account plans. Assign sales targets to SDRs. Summarize call transcripts.

A note on "read" actions

The self-described read / write split by connectors isn't always clean. Connector capabilities advertised as read-only still create externally observable side effects or local-execution paths, for example:

  • Search, browse, and lookup tools transmit the query itself to a third party. An attacker who controls a target service (or any service the model can be coerced into querying) can read those queries from server logs — the model has exfiltrated data without ever receiving a useful response.

  • Email-read connectors can fetch attachments to the local environment so the model can parse them. Attacker-controlled attachments can carry parser exploits or embedded malware.

When auditing connectors, it is pertinent to assess potential 'write' style impacts even on connectors described as 'read-only'.