If you are buying an agent platform, the first slide in the deck is probably a logo wall. Hundreds of integrations. I think that number is the wrong thing to count, and I built Team-X to prove the alternative.
In August 2025, Google Cloud's threat intelligence blog reported that the actor targeted Salesforce customer instances through compromised OAuth tokens associated with the Salesloft Drift third-party application. The exposure was not in the system of record. It was in a connector token held by a vendor.
The decision
Team-X is an open-source, local-first desktop app for running AI-agent organizations. It ships no first-party Slack, GitHub, Jira, Notion, or Discord integration, and it never asks for an OAuth grant. I checked this against the code at commit 62be216, not against our own documentation: no such packages in the dependency manifests, and no OAuth code in the application source.
Everything external arrives through the Model Context Protocol. Anthropic described it as "an open standard that enables developers to build secure, two-way connections between their data sources and AI-powered tools." The operator installs a server. One host in the main process holds every connection and routes every call.
The management argument is simple. A native integration means the vendor chose the scope, the vendor stores the credential, and the vendor patches the glue. A protocol boundary hands those three decisions back to you. OWASP's list for LLM applications describes the cost of getting scope wrong: "An LLM extension has permissions on downstream systems that are not needed for the intended operation of the application."
What the boundary enforces
- Per-role tool limits. Each role spec carries
tools_allowedandtools_denied. Team-X checks them when it builds the tool list and again inside the host at call time. Denial wins. A denied call never reaches the server, is logged as denied, and raises an authority violation event. - Process controls. A server binary must be an absolute path on an operator-managed allowlist, which starts empty. An entry can pin a sha256. The child process gets a short list of environment keys instead of the parent environment, and its working directory is pinned.
- Operator-owned installs. Skills are text instructions copied into a local snapshot. They are not executable code.
What it does not enforce
This is the part a vendor deck leaves out, so I will not.
An empty allowlist permits every tool. Of the 57 role files at that commit, 56 leave it empty. In practice, the control for most roles is the deny list and your choice of servers.
Tool descriptions reach the model unchanged. Invariant Labs defined the risk in April 2025: "A Tool Poisoning Attack occurs when malicious instructions are embedded within MCP tool descriptions that are invisible to users but visible to AI models." Team-X does not scan descriptions, so a poisoned tool that a role may call is not stopped by the lists.
The protocol's own guidance asks for more than role lists. The specification says clients should "Show tool inputs to the user before calling the server, to avoid malicious or accidental data exfiltration". The host has no confirmation step.
Client packages carry their own risk. JFrog reported that in mcp-remote "The vulnerability allows attackers to trigger arbitrary OS command execution on the machine running mcp-remote when it initiates a connection to an untrusted MCP server". Team-X does not depend on that package. The servers you run may.
There are also plain gaps in my own code. The connection-test path starts a stdio server without the allowlist check. The remote transport is the older SSE one and reads only a URL, so a server that needs a bearer token cannot be authenticated. MCP server environment values sit in the local configuration row, not in the OS keychain that holds provider keys. A GitHub skill source records the commit SHA but fetches by ref name, so only a URL containing a commit hash is truly pinned.
| Question for any agent platform | Team-X at the pinned commit |
|---|---|
| Who holds third-party tokens? | The MCP server you run, not Team-X |
| Where is access narrowed? | Role lists, checked twice, in one host |
| What spawns a process? | Allowlisted absolute paths, optional hash |
| What is not covered? | Tool descriptions, tool results, confirmation |
What I would do as an operator
- Ask every vendor for the list of credentials they hold on your behalf, not the number of connectors.
- Require an explicit allowlist per role. An empty list is not a policy.
- Review tool descriptions before enabling any server. They are model input.
- Pin skills and servers to a commit, not a branch or a latest tag.
- Decide which tokens may exist at all, and where they are stored.
I published the full walk-through, with the code references, at team-x.app. The protocol boundary is not a security product. It is a place where you can see, and own, the decisions that connector counts hide.
-Rocky
#TeamX #ModelContextProtocol #AIAgents #EngineeringDreams #StrategiaX
Originally published on Team-X Blog.