Directory

Every AI surface is configurable. None of them is governable alone.

Your company runs 7 of these from 5 vendors, each with its own admin console, its own settings hierarchy and its own idea of what an artifact is. These pages take each one seriously — what it genuinely controls, then what it structurally cannot.

how these pages are written

Every native control listed on a surface page is one the vendor documents, cited to the vendor's own docs. Nothing is asserted about a competitor's roadmap, and where a mechanism varies by plan or is changing quickly, the page says so instead of stating a version.

The "gaps" sections are not criticism. They are the honest boundary of a per-machine configuration model — the questions a local settings file was never designed to answer.

The pattern that repeats across all of them

Read seven vendor security pages in a row and the same shape emerges. Each surface ships real controls over what the agent may do — permission rules, allowlists, admin toggles, sandboxing — and almost nothing over what the agent was told to do. The instructions, the retrieved knowledge, the connector definitions and the lifecycle scripts arrive through channels the vendor treats as user content.

That split is defensible from the vendor's side. A tool vendor governs its own product on one machine; it has no mandate over the other six tools in your company, and no view of your fleet. But it means the artifact layer — the part that actually determines agent behaviour — has no owner. Every surface assumes somebody else reviewed the skill.

The consequence is concrete and repeats verbatim across vendors: a file that changes what an agent does is installed by copying a folder, with no publisher identity, no pinned version, no diff on update, no scan, and no record of which machines have it. That is the state dependency management was in before lockfiles, applied to artifacts with more privilege than most dependencies.

The same artifact classes, on surface after surface

Counted from the 7 profiles below — these are the classes that appear on more than one surface, which is what makes governing them per-tool the wrong unit of work.

  • MCP servers6 / 7 surfaces
  • Custom instructions3 / 7 surfaces
  • Extensions2 / 7 surfaces
  • Projects2 / 7 surfaces

What a cross-surface answer requires

  • Vincosha Registry — distribute

    One versioned, signed source for the skills, rules, hooks, and connectors every AI surface loads.

  • Vincosha Assay — vet

    Scans everything your AI consumes before it reaches a laptop, and quarantines what fails.

  • Vincosha Corpus — recall

    Your organisation's knowledge, retrievable from inside any AI session over MCP.

  • Vincosha Ledger — measure

    Every token, every session, every dollar — attributed to a user, a project, and an asset version.

7 / 7 surfaces

Frequently asked

Isn't this what our AI tool's enterprise admin console is for?
It covers its own product on its own terms, and you should configure it fully — those controls are real. What no single console can do is tell you that the MCP server your engineers connected to Cursor is the same one connected to Claude Code, that the version differs between machines, or which artifact versions were live in the session you are investigating. Those questions span vendors, so the answer has to as well.
Do we need a separate policy per surface?
You need one policy expressed once and enforced everywhere it applies. The artifact classes overlap heavily across surfaces, so writing seven policies mostly produces seven versions of the same policy that drift apart. Where enforcement genuinely differs — a hook mechanism one surface has and another does not — the per-surface page says so.
Which surface should we govern first?
The one with the widest extension surface and the most local privilege, which in most organisations is the terminal-based coding agent rather than the chat assistant. A chat assistant with a misconfigured connector leaks data; a coding agent running an unreviewed hook executes code on a developer machine with their credentials.
We only run one AI tool. Does this still apply?
The artifact problem does, in full — a single tool still loads unreviewed skills, rules and connectors. The cross-surface argument is what will apply in a year, because organisations reliably end up with more than one, usually without a procurement decision.

Keep reading

One control plane across every surface you run

Vincosha Registry distributes the same reviewed, pinned artifacts to every AI surface in your company; Vincosha Assay vets them before they land; Vincosha Ledger tells you which versions were active, on which machine, at what cost.

Start freeRead the docs