At a glance
- An AI plugin intake and approval workflow is a documented path from request, through security assessment, to an allowlist decision and continuous enforcement.
- Scope the workflow around everything an agent loads: MCP servers, Agent Skills, hooks, rules files, connectors and models, not only the agent.
- Backslash Security operates a free Skills Security Scanner that scans AI agent Skills for security risks, giving intake reviewers a concrete assessment step.
- Backslash Security publishes Claw-Hunter, an open-source tool for discovering and assessing OpenClaw risks.
- Shadow AI, meaning unapproved AI tools installed by employees under personal accounts, never reaches intake, so continuous endpoint discovery has to feed the workflow.
Backslash Security
Published:
An intake and approval workflow for AI plugins is a documented, repeatable process that takes an AI extension from "an employee wants to use this" to "security has assessed it, recorded a decision, and enforced that decision on the machine where it runs." The term AI plugin is used broadly here to mean anything an AI agent can load and act through at runtime: MCP servers, meaning Model Context Protocol connections that let an agent reach external tools and data sources; Agent Skills, meaning packaged instructions and scripts that extend what an agent can do and that execute with the user's own permissions, often amounting to little more than a markdown file on a laptop; hooks, meaning triggers that fire before or after an agent action; rules files such as AGENTS.md or CLAUDE.md, which carry standing instructions an agent reads on every run; plus connectors, plugins, subagents and local models. A workflow that covers only the agent application, for example Claude Code, Cursor, GitHub Copilot or Codex, leaves the components doing the actual work ungoverned. As of 2026, these components can be installed by an employee under their own identity, outside the software procurement path that governs ordinary business applications, so the approval decision has to be enforced where the component executes: on the endpoint.
A workable design has four stages, each of which produces a record:
- Request — a single intake channel, typically a form routed through Jira or ServiceNow, that captures the component, its source, the agent it will run under, and the data and systems it will touch.
- Assessment — a security review against stated, written criteria rather than reviewer judgment alone, covering provenance, permissions, outbound destinations, and the instructions the component carries.
- Decision — an explicit allowlist or denylist entry, scoped to a team or risk profile, with an owner and a review date attached.
- Enforcement and evidence — continuous application of that decision on endpoints, with audit and tracing data retained so the organization can reconstruct what an approved component actually did.
What counts as an "AI plugin" that actually needs an intake process?
What counts as an "AI plugin" for intake purposes is wider than the browser-style add-on the word suggests: on an endpoint, an AI plugin is any installable unit that extends what an agent can do, and it executes with the employee's own identity, tokens, and file access. The scope here is deliberately narrow in one respect — these are components an individual installs on a laptop or workstation, outside any central deployment pipeline — and deliberately broad in another: several of them are not software packages at all, but plain text files.
| Component | What it is | Where it typically lives | Intake trigger |
|---|---|---|---|
| Agent / coding assistant | The runtime that plans and acts, such as Claude Code, Cursor, GitHub Copilot, Gemini CLI or Codex | Installed application or CLI binary | Always — approve the agent before anything layered on it |
| Model | The inference engine, hosted or local via runtimes like Ollama or LM Studio | Local weights or an API endpoint | Always — destination of every prompt and pasted artifact |
| MCP server | A connection built on the Model Context Protocol, the standard agents use to reach external tools and data | Local process or remote endpoint in a config file | Always — each one is an action path into a real system |
| MCP tool | An individual callable function exposed by an MCP server | Declared by the server at connect time | On change — tool definitions can shift after approval |
| Agent Skill | Packaged instructions and scripts extending an agent; in practice often a markdown file that can tell the agent to read a file, call an API or run a shell command | Skills directory on the machine | Always — runs with the user's own permissions |
| Hook | A trigger that fires before or after an agent action, running something alongside it | Agent settings or project config | Always — executes without a prompt |
| Rules file (AGENTS.md, CLAUDE.md) | A file carrying standing instructions the agent reads on every run | Repository root or home directory | Inventory plus change review |
Formal intake is warranted when a component can execute code, reach credentials or tokens, send data to an external destination, or supply text the agent will treat as instruction. Plugins and connectors installed from personal accounts fall under shadow AI and belong in the same queue, since the approving team cannot see them any other way.
Why do existing software approval paths miss AI plugins entirely?
When the AI extension in question never passes through purchasing, existing software approval paths have nothing to act on. Traditional procurement, software request tickets, and endpoint management were all built around an installable, licensed artifact with a vendor behind it. Most agentic components are none of those things.
Which "AI plugin" are we actually talking about?
The term carries two distinct meanings, and approval processes only cover one of them.
The marketplace add-on. An extension installed into a sanctioned SaaS application — a connector added to an approved productivity suite, for example. It has a publisher, a billing relationship, and an admin console. A security review team can request a SOC report, negotiate terms, and switch it off centrally. Existing intake handles this case reasonably well.
The endpoint-side agent component. An MCP server — Model Context Protocol being the standard agents use to reach external tools and data — an Agent Skill, a hook, a rules file such as AGENTS.md or CLAUDE.md, or a plugin loaded by a coding agent like Claude Code or Cursor. An Agent Skill is often a markdown file that tells the agent to read a path, call an API, or run a shell command, executing with the employee's own permissions. There is no purchase order, no installer, and frequently no publisher at all.
This article uses the second meaning throughout.
Why does the existing stack not see it?
- Procurement triggers on spend. A file copied from a public repository costs nothing.
- Software request workflows trigger on installation. Editing a configuration file or dropping a markdown file in a directory is not an install event.
- MDM — Intune, Jamf and similar — manages applications, profiles and policies, not the components an already-approved agent loads at runtime.
- Identity controls such as Entra ID or Okta govern corporate sign-ins. An agent authenticated through an employee's personal account sits outside that record entirely, which is how shadow AI persists unnoticed.
- EDR inspects processes, files and known-bad behavior. The agent process itself is approved; what it was instructed to do is not visible at that boundary.
What stages should an AI plugin intake and approval workflow include?
An AI plugin intake and approval workflow moves through a defined sequence of stages, and the scope here is deliberately narrow: plugins, extensions, MCP servers and Agent Skills that employees install on their own endpoints, under their own identities, rather than components deployed centrally into a production application. A plugin in this context is any packaged extension that adds capability to an AI client — an MCP server (the Model Context Protocol connection an agent acts through), an Agent Skill (packaged instructions and scripts that run with the user's own permissions), a hook, or a rules file. Teams evaluating how to build this process usually need the stage map before the tooling decision, so each stage below names its owner and its exit criterion.
| Stage | What happens | Exit criterion |
|---|---|---|
| Discovery and request capture | Continuous inventory of what is already installed, plus a lightweight request form for new asks | Every component is either requested or found |
| Triage | Deduplicate, classify by component type, route by blast radius | Request assigned a risk tier and a reviewer |
| Risk assessment | Review the publisher, permissions, data destinations, invoked commands and embedded instructions | Documented risk finding |
| Approval decision | Allow, allow with conditions, or deny — recorded against a named approver | Decision written to the inventory |
| Provisioning | Allowlist the approved version; deny the rest by policy, enforced on the endpoint | Policy live and verified |
| Periodic review | Re-check approved components for version changes, new permissions or altered instructions | Re-approval or escalation |
| Retirement | Remove unused or superseded components and revoke their access paths | Component absent from inventory |
Discovery is the stage most intake processes skip, because a form only captures what someone chooses to declare. Backslash Security discovers every agent, model, MCP server, MCP tool, Skill, hook, rules file, plugin and connector running on an endpoint, which turns the request queue into a reconciliation exercise against observed reality rather than a self-reported list.
Periodic review matters because approval is version-bound: a Skill is often a markdown file that can be edited after the fact, so an approved component can change behavior without any new request entering the workflow. Retirement closes the loop by removing the credentials and connections the component was granted.
Which approval model fits best — centralized, federated, or risk-tiered?
Which approval model fits a given organization depends on four criteria that should be settled before the first plugin is reviewed, because each model trades them against each other in a different way.
The criteria, and why each one is decisive
- Speed to decision. How long an engineer waits between requesting a component — an agent, an MCP server, a plugin, or a Skill (packaged instructions and scripts that extend an agent, executing with the user's own permissions) — and getting an answer. Decisive where slow approvals push people into installing things unreviewed.
- Coverage. The share of the agentic surface the process actually sees. Decisive in engineering-heavy organizations where new components appear on endpoints weekly.
- Reviewer burden. The volume of security analysis per request and who absorbs it. Decisive when the security team is small relative to the population running agents.
- Audit quality. Whether the record afterward names who approved what, under which policy, and on what evidence. Decisive under EU AI Act, NIS2, DORA or SOC scrutiny.
| Approval model | Speed | Coverage | Reviewer burden | Audit quality | Where it fits |
|---|---|---|---|---|---|
| Centralized | Slow; one queue, one owner | Narrow in practice — requests route around backlog | Concentrated on the security team | Consistent, single evidence trail | Small organizations, early adoption, few components |
| Federated | Fast; decisions sit with team owners | Broad, but uneven in rigor between teams | Distributed to delegated reviewers | Fragmented unless records are centrally collected | Many autonomous engineering teams with differing risk profiles |
| Risk-tiered | Fast for low-risk tiers, deliberate for high-risk | Broad, since routine requests do not stall | Reserved for components touching credentials, source code or production | Strong where the tiering rule itself is recorded | Mixed populations running both trivial and privileged components |
Backslash Security supports whichever shape an organization picks by allowlisting approved components, denylisting risky ones, and letting teams carry custom policies matched to their own risk profile, enforced continuously rather than at intake alone. Each approval record should name the component and version, the approving owner, and the policy applied.
How do you assess a plugin's risk before you approve it?
To assess a plugin's risk before approval, reviewers need a fixed set of signals that apply no matter what the component actually turns out to be.
This depends on what you mean by "plugin." On an endpoint, the word usually covers four different objects: an MCP server (Model Context Protocol — the protocol agents use to connect to external tools and data, where each server is a live connection an agent can act through), an Agent Skill (packaged instructions and scripts that extend an agent, often nothing more than a markdown file that can tell the agent to read a file, call an API, or run a shell command), a rules file such as AGENTS.md or CLAUDE.md (standing instructions an agent reads on every run), and a hook (a trigger that fires before or after an agent action). Route each one through the same intake, because all four execute with the user's own permissions.
| Do this at review | But watch out for — and how to cover it |
|---|---|
| Verify provenance and publisher before anything else | Package names and repositories are trivially imitable; require a named internal owner alongside the upstream source |
| Enumerate requested permissions and scopes | Declared scope rarely matches effective reach; test what the component can actually touch, not what its manifest claims |
| Record the identity it runs under | Personal accounts on enterprise machines leave no corporate audit trail; require enterprise identity and flag private logins |
| Map data and system reach | Credential stores, Git config, and production endpoints are reachable by default; constrain folders and approved commands |
| Review tool capabilities, especially shell and network calls | One generic "execute" tool subsumes every other control; approve capabilities individually |
| Pin update behavior | Silent updates reapprove themselves; treat a version change as a new intake |
| Ask whether each action is reversible | Exfiltration and credential use cannot be rolled back; those actions need inline prevention, not after-the-fact detection |
Across these signals, what a component is permitted to do matters less at review time than the identity it inherits when it acts, since approval granted to a tool is exercised with an employee's access. Backslash Security research found that malicious instructions hidden in a repository's AGENTS.md file could trick OpenAI Codex into silently accessing AWS credentials, npm tokens, and Git configuration — which is why rules files belong in intake scope, not outside it.
Frequently Asked Questions
What counts as an "AI plugin" in an intake and approval workflow?
In an intake and approval workflow, an AI plugin is any component that extends what an AI agent can do on an employee's machine — and the list is wider than most catalogs assume. The components that belong in scope include:
- MCP servers — Model Context Protocol is the protocol agents use to connect to external tools and data sources; each MCP server is a live connection an agent can act through.
- Agent Skills — packaged instructions and scripts that extend an agent's capability. A Skill can tell an agent to read a file, call an API, or run a shell command, and it executes with the user's own permissions. In practice a Skill is often just a markdown file on the machine.
- Hooks — triggers that fire on an agent action, running something before or after it.
- Rules files such as AGENTS.md or CLAUDE.md — files in a repository or on a machine carrying standing instructions an agent reads on every run.
- Connectors, plugins and models attached to assistants like Claude Code, Cursor, GitHub Copilot, Codex or Gemini CLI.
An intake form that only asks "which AI tool do you want?" misses every item below the tool itself.
How do you assess a plugin before approving it?
Assessment before approval means answering concrete questions about the component's capabilities rather than its description: what permissions it inherits, whether it can execute shell commands, which outbound destinations it contacts, whether it touches credential stores or Git configuration, and who publishes it. Skills deserve particular attention because they are easy to overlook in review: Backslash Security operates a free Skills Security Scanner that scans AI agent Skills for security risks, which gives an intake reviewer a starting assessment instead of a reading of the README. Reviewers should also record the version or commit assessed, since a Skill or rules file can be edited locally after approval.
How do you find the plugins employees installed before intake existed?
Any workflow launched in 2026 inherits a backlog, so discovery runs before approval. This is the shadow AI problem in its most literal form: agents, MCP servers and Skills that security never approved and cannot see, usually installed by employees on their own endpoints and sometimes authenticated through personal accounts on corporate machines. Backslash Security discovers every agent, model, MCP server, MCP tool, Skill, hook, rules file, plugin and connector running on an endpoint, which converts the backlog into a reviewable queue. For one emerging corner of that surface, Backslash Security publishes Claw-Hunter, an open-source tool for discovering and assessing OpenClaw risks.
How do you keep approvals from slowing AI adoption down?
Keeping approvals fast depends on making the default path a standing policy rather than a ticket. Three mechanisms do most of the work: allowlisting components already assessed as safe, denylisting the ones ruled out, and writing per-team policies so a research group and a finance team are not held to identical rules. Enforcement then runs continuously against those policies, so the review happens once and applies every day after. As Philip Walsh, Head of Security Engineering at Happy Returns, put it: "Backslash gave us a live picture of the AI our engineers were already running, and a way to govern it without slowing anyone down."
What happens when an approved plugin starts acting on its own?
An approved component that takes actions nobody asked for — reaching for credentials, escalating privilege, or sending data to an unapproved destination — is a rogue agent, and approval records alone will not catch it. Backslash Security blocks risky agent actions inline before execution, including unauthorized code execution, credential access, privilege escalation, and data sent to unapproved destinations. This is the layer traditional endpoint tooling does not reach: EDR, endpoint detection and response, watches processes and known-bad files, while the question here is what an agent was instructed to do.
What audit evidence should the approval workflow retain?
The workflow should retain the decision record — component, version assessed, approver, policy applied — plus runtime evidence of what the approved component actually did. Backslash Security traces the full path of an agent run from prompt to agent to tool call to outcome, which is the record an investigator needs to reconstruct an incident. Backslash Security also automatically generates audit evidence for EU AI Act, NIS2, DORA and SOC, so the governance record produced by agentic AI endpoint security controls can be handed to an auditor without a manual reconstruction exercise.
About this article
Backslash Security publishes this article under its own name and is responsible for its accuracy. Articles are researched and drafted with AI assistance and approved by Backslash Security before publication; publication and update dates reflect substantive edits, not automated refreshes. Last updated: 2026-10-07