OpenAI Developers announced a portable plugin format on August 6, developed with AWS, Cursor, GitHub, Visual Studio Code, and Vercel. The pitch is straightforward: build a skill once, then use it across compatible clients. The format packages reusable skills and MCP server configurations so teams can move capabilities between environments with less rework. The announcement is important because it changes the economics of distribution. A capability no longer needs to be rebuilt for every tool. It can travel.
That convenience creates a governance problem that most adoption plans are not ready to handle. Portability makes software easier to install, but harder to evaluate. The question is no longer whether a skill works in one environment. It is whether the publisher, permissions, provenance, security history, and reputation can travel with it.
Portability removes friction in both directions
A portable skill can save a development team days of integration work. A documented format reduces client-specific packaging. Standard MCP configuration makes it easier to connect a capability to external systems. Internal teams can share proven workflows instead of copying instructions between repositories.
Those are real benefits. We should use them.
But the same format also lowers the cost of importing untrusted software. A developer can discover a useful skill, install it in a local environment, and make it available to sensitive tools before security or procurement has reviewed the publisher. If the skill works, adoption becomes self-reinforcing. Other teams copy the configuration. A private registry appears. The capability becomes operational before anyone has established who maintains it or what it can access.
That is the supply-chain risk. Portability does not merely distribute code. It distributes trust assumptions.
The package is not the proof
A plugin manifest can describe what a skill does. It cannot, by itself, prove that the description is accurate.
A useful evaluation record should answer at least five questions:
- Who published the skill, and can that identity be verified independently of the marketplace where it was found?
- What systems, data sources, and actions can it access?
- Where did the package originate, and can every release be traced to a known source?
- What security history exists, including reported issues, fixes, ownership changes, and unexplained release changes?
- What evidence supports its claimed performance, reliability, and maintenance commitments?
Most teams currently answer only the second question, and even that answer is often incomplete. They inspect a configuration file, see a familiar server name, and assume the rest. That is not due diligence. It is a technical installation check dressed up as a risk review.
The distinction matters because skills can influence consequential decisions without directly holding credentials. A capability that summarizes customer records, chooses a data source, recommends a vendor, or prepares a transaction can create material exposure even when a human still clicks the final button.
Permissions must be readable before approval
The first practical control is a permission manifest that a reviewer can understand without reverse-engineering the package.
A skill should declare:
- The tools it can invoke
- The data it can read, write, or transmit
- The identities it uses when calling external services
- The domains and endpoints it contacts
- The actions that require explicit human approval
- The maximum financial, operational, or reputational impact of those actions
Do not accept broad labels such as "access to business tools." That phrase can conceal read access to a warehouse, write access to a CRM, and permission to send external messages. Those are three different risks and should be reviewed separately.
Google Cloud's MCP guidance recommends creating separate identities with narrowly scoped permissions instead of allowing a tool to operate with a developer's personal access. That principle should become the default for portable skills. A package that requires the installer's full privileges is not portable in any meaningful governance sense. It is portable escalation.
Provenance needs to survive redistribution
A package copied from one client to another should retain its origin, version history, dependency information, and signing identity. If that information disappears when the package enters an internal registry, the registry has preserved functionality while discarding accountability.
This is where software teams should borrow from established supply-chain practice. Require signed releases. Pin versions. Record checksums. Maintain a bill of materials for dependencies and referenced MCP servers. Log who approved each version and why. Treat an ownership change as a review trigger, not as routine metadata.
The goal is not to make every internal tool pass a six-month procurement process. The goal is to make the decision explainable. If a portable skill reaches production, your team should be able to answer where it came from, what changed, who reviewed it, and which evidence justified approval.
Reputation has to be attached to the publisher
Star ratings and download counts are weak signals. They measure attention, not trustworthiness. A popular package can still be poorly maintained, over-permissioned, or controlled by an unknown publisher.
Reputation becomes useful when it is attached to a verifiable identity and supported by evidence. That might include maintenance history, incident disclosures, successful reviews by known organizations, response times for security reports, and evidence that the publisher controls the domains and signing keys associated with the package.
This extends the argument from our earlier post, Who Decides What Software Buys?. When software selects a service, discovery and ranking become commercial control points. Portable skills add another control point before selection: installation. If the ecosystem ranks packages by visibility alone, it will reward distribution faster than accountability.
What technical leaders should do this quarter
Teams defining plugin or MCP policies should establish a minimum admission standard now, before informal marketplaces and internal registries become permanent infrastructure.
Start with a simple decision record for every third-party skill:
- Verified publisher identity
- Declared permissions and external connections
- Signed package and pinned version
- Dependency and server inventory
- Security contact and disclosure history
- Test evidence for the intended use case
- Expiration date for the approval
- Named owner responsible for renewal or removal
Then separate installation from authorization. A developer may be allowed to test a skill in an isolated workspace, while production access requires security review, scoped credentials, monitoring, and an accountable business owner. This gives teams room to experiment without confusing technical availability with organizational approval.
Finally, make trust data portable too. When a skill moves between clients, the receiving environment should receive its identity, capability claims, permission history, review status, and known incidents alongside the package. Otherwise every client starts its own investigation, and the least careful environment becomes the path of adoption.
BluePages is built around this missing record of identity, capability evidence, and reputation for software that organizations need to evaluate before granting access. The important work is not creating another directory. It is making the evidence travel with the capability.
Before you approve the next portable skill, require a portable trust record. Start with the publisher, the permissions, and the provenance, then make every future review easier to defend.