Every Connector Is a Standing Credential

Picture a single wall socket with a tower of plug adapters jammed into it. Somebody added one adapter to charge a laptop, somebody else stacked a multi-way block on top of that for a monitor, and a third person plugged a travel adapter into the block for a phone. Every addition made sense on the day it happened. Now one outlet feeds eleven devices, the whole assembly is warm to the touch, and nobody in the building could tell you what is plugged into it without walking over and looking.

That is what the integration layer of an AI agent looks like in most organizations right now. Every connector somebody adds lets the agent reach one more system, and every connector carries its own credential to get there.

What a Connector Actually Is

The Model Context Protocol, usually shortened to MCP, is an open standard for connecting AI assistants to tools and data. A connector built on it, or on any of the similar plugin systems, is a small piece of software that gives the agent a set of actions against a real system: read the calendar, search the shared drive, open a ticket, query the database, send an email.

To do any of that, the connector needs authority. It holds an OAuth token granted when somebody clicked through a consent screen, or an API key pasted into a configuration file, or a service account password somebody set up for a demo. That credential sits there permanently, working whenever the agent calls the tool, whether or not the person who installed it is at their desk.

Installing one takes minutes. There are public directories listing thousands of them, many written by individual developers, and a curious engineer can have three connected to their assistant before lunch. None of that passes through procurement, and most of it never reaches the security team at all.

The Agent’s Reach Is the Sum of Its Connectors

Here is the part that changes the risk calculation. An employee’s access is bounded by what their role needs and what their manager approved. An agent’s access is bounded by the union of every scope on every connector attached to it, and nobody ever approved that union as a whole.

Consent screens make this worse because they ask for what the connector’s author found convenient to request, which is rarely the minimum. A connector built to read calendar availability often asks for full mailbox access, because the same API covers both and the broader scope is one checkbox. The employee who clicked accept wanted meeting times, and the token they granted can read, send, and delete email.

Local connectors add a second problem. Many of them run on the employee’s own machine and take their credentials from a configuration file, frequently as a plain API key in a JSON block. Your identity provider cannot revoke a key it never issued, your access reviews never list it, and the key stays valid long after the person who pasted it changes roles or leaves. We made the same argument about machine identities outnumbering your people, and connectors are the fastest-growing category of machine identity most programs are not counting.

The Combination That Gets Exploited

A single connector with a broad scope is a standing credential. A few connectors attached to the same agent become something more useful to an attacker, because the agent will move data between them if it is told to.

Put yourself in the shoes of somebody who wants the contents of a finance team’s shared drive. They do not need to phish anybody or break into the drive. They need the finance analyst’s agent to read one piece of content they control, such as an inbound email, a calendar invitation, a support ticket, or a document shared from outside, containing instructions phrased as part of the task. If that same agent can search the drive and can send email or post to a web endpoint, the instructions can ask it to do both, and the agent has every credential it needs already.

The dangerous pattern is an agent that can read untrusted content, reach private data, and communicate outward, all at once. Each capability is harmless alone. Together they give an attacker a proxy inside your environment holding somebody else’s permissions, and the action logs show the employee’s own agent doing it.

Why the Usual Controls Miss It

Your data loss prevention sees an authorized user’s tool reading an authorized file and sending an email the user is allowed to send. Your identity provider sees a valid token being used by the application it was granted to. Your endpoint agent sees a normal process making normal network calls.

Nothing is anomalous at the layer your controls watch, because the misuse happens in the reasoning step that decided to take the action, and no tool you own records that step by default. The sandbox escapes we wrote about were a version of this, where the agent used reach that was already granted, and shadow AI is the same story from the data’s side.

What to Do About It

Find the grants you already have

Start with OAuth consent records in your identity provider, filtered for applications that describe themselves as assistants, agents, or connectors, and look at the scopes each one holds. Then search endpoints for local connector configuration files, which tend to live in predictable paths for each assistant, and count the API keys inside them. Both numbers will be larger than anybody expects.

Scope every connector to the job

Read-only should be the default, and write access should require a reason. Where a connector asks for more than it needs, replace it or restrict it at the identity provider with an admin consent policy, so employees can no longer approve broad scopes on their own. A calendar connector does not need to send mail.

Break up the dangerous combination

Do not let a single agent hold all three of untrusted input, sensitive data, and an outbound channel. An agent that summarizes inbound email should not also have write access to the shared drive and permission to send, and an agent working on sensitive data should not browse the open web in the same session.

Make credentials short-lived and revocable

Prefer connectors that use short-lived tokens issued through your identity provider over static keys in files. Where a static key is unavoidable, put it in a secret manager with rotation, and tie every connector to a named human owner so it can be revoked when that person leaves, the same discipline we argued for with access held by people who do not work for you.

Log the tool calls

Record which tool the agent called, with which arguments, on whose behalf, and in response to what input. When something goes wrong, the question will be why the agent did it, and without tool-call logs that question has no answer.

The Budget Line You Did Not Know You Had

Every one of these connectors is an integration, and in any other context an integration with production data would go through security review before it went live. The only reason these did not is that an employee could install them without asking.

The cost of reviewing them now is a few days of inventory and some consent policy changes. The cost of not reviewing them arrives the first time a poisoned document reaches an agent holding credentials to your email, your files, and your ticketing system at once, and the investigation finds a trail that looks exactly like one of your employees doing their job.

Chris Armour is Director of Information Security at Grab The Axe.

Director of Information Security

Chris Armour

The Breaker & Builder.

Operating on the philosophy that 'you can't build a secure system if you don't know how to break it,' Chris leads our engineering division. A top 1% National Cyber League competitor, he hardens our digital infrastructure against the very exploits he has mastered.

View Author Page →