Support Agent and MCP connectors

What's enabled by default when this feature is available

MCP access for the Support Agent "fails closed": nothing is enabled by default.

• It is never auto-enabled. No release or upgrade turns it on.

• Connecting an MCP server doesn't grant the Support Agent access to it. Connectors you add for your team or the Assist Agent don't carry over.

• Access is granted per connector and per tool. New tools on an already-approved connector stay off until you approve them.

If you do nothing, the Support Agent keeps working exactly as it does today: answering from your knowledge base and training content, with no MCP access.

Who can enable it

Only an organization admin can enable MCP for Support Agents. This isn't delegable to the people tuning day-to-day agent behavior — enabling a tool here is a security decision, not a configuration one. Read the next two sections first.

What changes when you enable it

The Support Agent replies to customers without human review, so its default access is narrow: no past tickets, no internal notes. Enabling MCP tools extends its reach to the systems you connect.

It still reads untrusted customer messages, and still replies on its own. A message written as instructions rather than a question can influence which tools it calls and what it reports back — using the access you granted.

Restrict tools, not behavior

Agent instructions are not a security control. Telling the agent to ignore embedded commands or never reveal a field doesn't reliably hold; prompt-level defenses are defeated consistently in published testing. Restrict what a tool can reach instead — an instruction has to anticipate every phrasing of a request, while a tool that can't read a field has nothing to anticipate.

What Pylon enforces

• The Support Agent's context stays narrow — no past tickets or internal notes, regardless of MCP configuration.

• Autonomous agents use an Agent Connection, an organization-level identity an admin authorizes ahead of time, rather than a teammate's session.

• Tool access is approved at the organization level, and permissions are checked on every tool call.

• We don't use output filtering as a security control. Where we can't guarantee something, we'd rather say so.

Before you enable

• Prefer read-only tools. The worst case becomes disclosure rather than action.

• Prefer narrow, typed lookups over general-purpose query tools. "Get subscription status for this account" is safe in a way that "run this query" isn't.

• Scope the credential at the provider. Assume anything it can reach could appear in a reply.

• Check whether the tool can reach across accounts. Looking up any customer is a different risk than looking up the one who wrote in.

• Start with one connector and one tool. Review real behavior, then widen.

Getting started

Contact your Pylon representative and we'll walk through toggling on the availability for this feature.