16.9 Installing is a trust decision
- Approved by
- Panaversity ·
In everyday life. You would not give a stranger a key to your house because their flyer, a small printed ad, says "We water plants!". You would want to know who they are, what they will do inside, and whether they make copies of your mail. The flyer is not the person.
What you will learn. What a plugin can do on your computer once you install it. How to read one before you decide. What an organization can control.
Why it matters. A plugin's description is written to sell it. What decides whether you can trust it is in the files that run.
What does a plugin do once it is installed?
Parts of it run. A plugin is not a document you read. It is a bundle the agent loads.
- A plugin runs as you. Its skills tell your agent what to do, with your permissions. Its local connectors are programs started on your computer, with your files and your network. Its hooks run code at fixed moments, such as when a session starts. Some products also load code modules, programs that change how the product itself looks and behaves.
- Most of this runs with no sandbox. A sandbox limits what a program can reach. Hooks, code modules and local connector processes usually run with your full rights. A hook that runs when a session starts runs before you have typed anything.
- Every enabled plugin also costs context, on every turn (16.5). A plugin you do not use is still a cost and still a risk.
So installing a plugin is a decision to trust its author with what you can reach. A description that says "faster AP lookups" is a flyer.
How do I read a plugin before I install it?
Like a pull request. Before you install a plugin, read its files, as you would read a change to your own code (Chapter 15). Look for what runs:
| Look in | Ask |
|---|---|
| The manifest | Who made it? Is the version pinned? Does it ask for values, and which ones? |
| Hooks | When does each one run, and what command does it run? |
| Scripts and code modules | What do they read? Where do they send anything? |
| Connectors | What program, which version, which folders or addresses? Are its write tools needed? |
| Skills | Do the instructions match the description? Do they tell the agent to send, upload or delete anything? |
A network address in a script, especially one that receives your files, is the first thing to explain. So is any file read outside the plugin's own folder, such as .env, where keys are often kept.
What can an organization control?
Most products let an administrator decide which plugins people may install: none, a reviewed list, some installed for everyone, or some required. Most also let an administrator limit which catalogs people may add. In a company, the safe default is a reviewed list, and every plugin on it was read by someone responsible. Making a plugin unavailable for everyone is also how a bad version is removed quickly.
Does a reviewed catalog make a plugin safe?
It helps, and it does not replace reading. A curated directory may scan and review what it lists, and may refuse all plugins with hooks. That lowers the risk. It does not tell you whether a plugin should be able to reach your data. You still decide that.
Can I keep something valuable in a plugin?
No. A plugin's files are readable by anyone who installs it, so a plugin is a poor place for anything valuable or secret. If your value is in logic, data or a model you pay for, keep it on a server you control. Put it behind a remote connector that checks who is calling. Chapters 17 and 18 teach how that server works and how it checks.
At work. A colleague forwards Ana an "AP helper" plugin that promises instant answers. The builder reads it before anyone installs it. Its manifest and skill look harmless. Its hook runs a script at the start of every session. The script sends every file in data/, and .env, to an outside address, then copies the files into a "cache". Nothing in the description mentions either. The answer is "do not install". The hook, the script's line and the address are written down, so the next person who is sent it knows why.
The operating rule: before you install a plugin, read what it runs, where it sends data and what it can reach. Install only what you would let run as you.
Figure 16.13. Read a plugin before you install it. The lines that run code, and the addresses they send to, decide whether you can trust it.
Practice it. Practice: installing is a trust decision, in your own tool, ten minutes.
Building Skills and Plugins with Coding Agents
Question 1 / 8
0 answered
A colleague installs a plugin with a hook. Whose rights does the hook run with?
- Owner
- Panaversity