Before installing an AI coding-agent plugin, inspect its manifest, skills, MCP servers, client-specific extensions, network behavior, and required credentials in a disposable repository. Portability tells you that a package can be loaded by more than one compatible client; it does not tell you that the package is trusted, sandboxed, least-privileged, or safe for production code.
This audit matters because Agent Plugins 1.0.0 is being positioned as an open, vendor-neutral format for packaging Agent Skills and MCP servers into a portable directory. Google’s announcement describes a fixed layout for plugin.json, skills/, mcp.json, and optional client-specific namespaces, while explicitly leaving installation, permission models, sandboxing, and provenance verification to clients and future ecosystem work. [1] GitHub’s August 2026 Copilot and VS Code release roundup also lists portable agent plugins as part of a wider set of cross-client session and workflow improvements. [2]
The useful mental model is simple: a plugin is a package boundary, not a security decision. Treat it like a dependency that can influence an agent’s instructions and tool access. TOOlover’s repository context-file guide helps define the project contract around the plugin, while the AI coding-agent evaluation checklist gives you a way to inspect the resulting change.
What an Agent Plugin 1.0 package contains
The specification keeps the portable core intentionally small. Google’s example uses a directory with a short manifest, one or more skill folders, an MCP configuration, and an optional reverse-domain directory for client-specific additions. [1]
reports-plugin/
├── plugin.json
├── skills/
│ └── summarize/
│ ├── SKILL.md
│ ├── scripts/
│ └── references/
├── mcp.json
└── com.example.client/This layout separates the portable core from extensions that only one client understands. It also makes the first audit mechanical: read the manifest, enumerate the skill files, inspect every MCP entry, and then examine any client-specific directory instead of assuming it is harmless because another client will ignore it.
| Package area | Audit question | Why it matters |
|---|---|---|
plugin.json | Does the name, schema, and repository identity match the source you intended to install? | A small manifest is easier to compare against the claimed package and commit. |
skills/ | What instructions, scripts, references, and file paths does each skill ask the agent to use? | Skill text can change an agent’s behavior even when no executable MCP server is present. |
mcp.json | Which servers start, through which transport, with which arguments and environment variables? | MCP configuration is where external tools, services, and credentials often enter the workflow. |
| Client namespace | Does the package include hooks, commands, or agents specific to one client? | Non-portable extensions may have different permissions and review surfaces. |
Run a five-minute pre-install audit
1. Start with the source and the exact version
Prefer a repository, release, or commit that you can name and record. Do not treat a package registry listing or a README badge as proof of provenance. Save the source URL, version, commit, and the date of your review in the pull request or team notes. If the package has no stable source or version boundary, stop at inspection rather than connecting it to a production repository.
2. Read instructions as executable policy
Search every SKILL.md, script, and reference file for commands that read or write outside the intended project, install dependencies, access environment variables, upload files, open network connections, or suppress tests. A skill is not automatically dangerous because it contains a shell command; it is dangerous when the command is outside the task’s stated boundary or is impossible to explain to a reviewer.
find plugin-review -type f -maxdepth 4 -print
rg -n "curl|wget|npm|pip|git push|env|secret|token|upload|sudo|rm -rf" plugin-review
cat plugin-review/plugin.json
cat plugin-review/mcp.jsonThe commands above are for inspection only. Run them in a disposable checkout and adapt the paths to the package you are reviewing. Do not paste credentials into a plugin just to see whether it works.
3. Separate portability from permission
Google explicitly states that Agent Plugins v1 defines a package format but does not define an install mechanism, permission model, sandboxing requirements, or trust and provenance verification. [1] That omission is a boundary, not a footnote. Your client, operating system, repository policy, and execution environment still decide whether an MCP server can access files, call the network, or use credentials.
Write down the answer to four questions before enabling a server: Which directories can it read? Which directories can it write? Which network destinations can it reach? Which credentials, if any, are available to it? If an answer is “the whole machine” or “whatever is in the shell environment,” the plugin is not ready for an unattended coding workflow.
4. Test the failure path
A plugin should remain understandable when one component fails. Google’s description says that a client can skip an MCP entry that fails to start while continuing to load independent skills. [1] Test that behavior with a deliberately unavailable endpoint or a missing optional variable in a non-production workspace. Confirm that the agent reports the failure, does not silently substitute a different server, and does not proceed with a misleading success message.
Use a review boundary after installation
Portable packages make distribution easier, which makes review more important rather than less important. GitHub’s August release notes describe features for navigating agent prompts alongside related file changes, continuing sessions created in other applications, and reviewing session details beside chat. [2] Those capabilities help reviewers reconstruct what happened, but they do not replace a diff, tests, or an approval boundary.
A practical handoff should include the plugin source and version, files it was allowed to touch, commands and servers it used, credentials that were available, checks that passed, and any component that was disabled. For structured comparisons, TOOlover’s Text Diff can make changes between a baseline and an updated configuration easier to inspect; the project’s own tests remain the authority for correctness.
| Stage | Minimum evidence |
|---|---|
| Before install | Source URL, exact version or commit, package tree, intended capabilities, and a disposable checkout. |
| During test | Observed commands, MCP startup results, network destinations, file changes, and failure behavior. |
| Before merge | Reviewable diff, project tests, lint or build results, secret scan, and an explicit human approval. |
| After adoption | Owner, upgrade policy, rollback path, and a record of changes between plugin versions. |
The takeaway
AI coding-agent plugins are useful when skills and tools belong together and need to travel across compatible clients. The safe adoption pattern is to treat portability as packaging, not trust: inspect the fixed files, identify every execution path, constrain permissions, test component failure, and preserve a human-reviewed handoff. If a plugin cannot explain what it reads, writes, calls, and changes, keep it out of the production repository until it can.
References
- Agent Plugins package your skills, tools, and more — Google Developers Blog, August 6, 2026.
- GitHub Copilot in VS Code, August 2026 releases — GitHub Changelog, August 31, 2026.
- Agent Plugins 1.0.0 specification — Agent Plugins project specification.