The Duct-Tape Era of Agent Tooling Is Over
A developer needs an agent to talk to the company's payment provider. There is no approved way to do this yet, so they do what anyone does under a deadline: they generate an API key, paste it into a .env file, and drop a copy in Slack so a teammate can use it too. Someone else finds an MCP server on GitHub that looks like it does the job, clones it, and wires it into Claude Code without reading past the README. A third person adds a Skill they found in a gist. None of this gets reviewed. None of it gets recorded anywhere. Three months later, nobody in the company can say with confidence which agents can reach which systems, whose credentials they are using to do it, or what happens to any of it when that developer leaves.
That scene is a composite. It shows how easily agent access can grow without anyone taking ownership of it.
It is time to end the duct-tape era.
The system nobody owns
When installation happens person by person, even the platform team may not know how many MCP servers are connected across the company. The list of active Skills becomes "whatever each person installed." Ask who approved any of it, and there is no answer, because nothing required approval. The capability just showed up the day someone needed it, the same way a browser extension shows up: click, allow, done.
The credentials underneath it are worse. Long-lived API tokens get generated once and live forever, pasted into environment variables, DMed to a teammate, checked into a private repo "temporarily," reused across three different tools because requesting a fourth key felt like more friction than it was worth. Without an owner, rotation gets forgotten. Scoping gets deferred because pasting the same broad key everywhere feels easier.
And when something changes, there is no clean path. A server turns out to be malicious, or just abandoned. A vendor gets breached. A developer leaves the company. In a governed system, that is a lookup and a revoke. Without that ownership, it is a scramble: who was using that thing, what did it have access to, and how do we even find out.
Why it happened this way
None of this is negligence, exactly. A new capability layer shows up faster than the org chart can absorb it, and everyone improvises around the gap.
MCP servers and Skills do not fit neatly into an existing ownership box. A security process built around SaaS access may not cover what a developer installs in Claude Code. A platform team can own the infrastructure without owning agent configuration. Under a deadline, filing a ticket for a tool that already works can feel like unnecessary friction.
So capability provisioning fell into the gap between teams, and the fastest available fallback filled it: copy the token, clone the repo, install the thing, ship the feature. A corner nobody owns fills with whatever is fastest. The difference this time is that the thing being granted access is not a person who can be reasoned with in a Slack DM. It is code that will use whatever access it is handed, including when it follows an instruction the team never intended to authorize.
What ad hoc actually breaks
The gaps stay quiet until something goes wrong.
Installation gets ahead of review. A capability that looked right in a README is not the same thing as one someone actually checked. Anthropic's own guidance for deploying Skills at enterprise scale spells out what real vetting looks like: read every file in the Skill directory, check for hardcoded credentials, look for instructions that tell the model to ignore safety rules or hide actions from the user, treat installing a Skill with the rigor of installing software on production systems.1 That review has to happen before installation becomes routine.
This is not a hypothetical risk. Cursor disclosed CVE-2025-54135 in August 2025: an indirect prompt injection could create a local .cursor/mcp.json file and trigger code execution without approval. Cursor fixed it in version 1.3.9.2 Invariant Labs also demonstrated tool poisoning attacks, where instructions embedded in a tool description manipulated an agent into actions the user had not requested.3
Credentials can stay broad and permanent because that is easier than managing their lifecycle. MCP's authorization specification for HTTP transports describes scoped access tokens and requires servers to validate them on incoming requests.4 Local servers using stdio follow a different model and may read credentials from the environment. Either way, someone still needs to own the secret and decide when its access should end. Pasting a token into Slack does not create that ownership.
And none of it shows up until someone asks a question the company can't answer. Who approved this capability. When was it last reviewed. What is it allowed to touch. Who is using it right now. Reconstructing that from Slack history and someone's memory is not an audit trail. It's archaeology.
What a governed system looks like
Every MCP server and every Skill available to any agent in the company belongs in a registry someone owns, has gone through an approval step, and can be looked up in seconds, not discovered by asking around. The public MCP Registry helps people discover servers, but its metadata is self-reported. Moderation is not a security review of everything listed.5 A company's internal catalog needs to say what the company has actually approved.
What lives in that registry should be pinned like any other dependency. A lockfile stops "whatever the latest version happens to be today" from silently becoming production behavior; a hash check stops a tampered package from passing as the one that was reviewed. Anthropic's enterprise guidance recommends version pinning and checksum verification for Skills. In its API, omitting the version selects the latest version. Updates should go through review as new deployments.1
Long-lived service credentials should not have to live in every agent's configuration. Docker's MCP Enterprise Gateway describes a way to keep them in a secret store and inject them when needed. It authenticates the caller and evaluates policy for each tool call.6 That reduces credential distribution. It does not make an agent incapable of leaking data it is authorized to read.
An audit log helps you find out who used a capability. Enforcement is what cuts access off. Docker says revoking a server or tool takes effect on the next call.6 Skills need their own update path: removing one from a catalog does not erase copies already installed on workers. A rollback may need a redeployment or a session restart. The important part is knowing how the change reaches every affected agent.
None of it works scoped to a single tool. Claude Code, Cursor, Codex, and whatever custom agent your team built in-house need to pull from the same catalog, obey the same scoping rules, and show up in the same audit log. Approve a capability in one tool and leave it invisible to the others, and you have just built a second, smaller version of the same duct tape.
The boring infrastructure that saves you
Package managers gave teams a way to track dependencies. Cloud IAM gave them finer control over access. Agent tooling needs the same kind of ownership.
The instinct to resist this is understandable. A registry sounds like process. Scoped credentials sound like friction. An approval workflow sounds like the thing that slows down the team that just shipped three features with an MCP server nobody reviewed.
But the actual cost of skipping it does not show up as slower shipping. It shows up as the moment someone asks a question the company cannot answer.
What does this agent have access to? Who approved it? What do we do now that it needs to be revoked?
Build that ownership into the system early, and you have a record to consult. Skip it, and you have to reconstruct the access history right when you can least afford the delay.
I would rather already know.
Footnotes
-
Anthropic. "Skills for enterprise." Governance, security review, and versioning guidance for deploying Agent Skills at scale. https://platform.claude.com/docs/en/agents-and-tools/agent-skills/enterprise ↩ ↩2
-
Cursor. "MCP auto-start leading to RCE via .cursor/mcp.json file." August 2, 2025. CVE-2025-54135, patched in Cursor 1.3.9. https://github.com/cursor/cursor/security/advisories/GHSA-4cxx-hrm3-49rm ↩
-
Invariant Labs. "MCP Security Notification: Tool Poisoning Attacks." April 2025. https://invariantlabs.ai/blog/mcp-security-notification-tool-poisoning-attacks ↩
-
Model Context Protocol. "Authorization." Draft specification for OAuth 2.1-based, scoped access tokens for MCP servers; authorization is optional under MCP and applies to HTTP-based transports. https://modelcontextprotocol.io/specification/draft/basic/authorization ↩
-
Model Context Protocol. "Introducing the MCP Registry." September 8, 2025. https://blog.modelcontextprotocol.io/posts/2025-09-08-mcp-registry-preview/ ↩
-
Docker. "MCP Enterprise Gateway." Product page describing identity-provider authentication, per-call policy evaluation, credential injection, and audit logging for MCP servers. https://www.docker.com/products/mcp-enterprise-gateway/ ↩ ↩2
