Playbooks
The work, written out — not the pitch for the work.
Every guide here is executable with no Vincosha account, and each one says plainly what the manual path costs before it mentions us at all. A how-to whose fourth step is "buy our product" is a landing page wearing a tutorial's clothes, and you would stop reading — rightly.
how to use this set
Do them roughly in the order below. The most expensive mistake in this work is sequencing: teams routinely write the AI usage policy first, because it is the deliverable an executive asked for, and end up with a document that prohibits things nobody can detect and permits things nobody has inventoried.
Inventory first. Then the reviews that inventory makes possible. Then the policy, which can now say something enforceable. Then the measurement that tells you whether any of it worked.
Why these are shaped as procedures rather than advice
Most published material on AI governance stops at the level of principle — *maintain an inventory*, *review third-party components*, *apply least privilege*. All true, and none of it survives contact with the specific question of what to type on Monday morning. The gap between a principle and a procedure is where programmes stall.
So each guide names the owner, gives an honest effort range rather than a fabricated one, and ends every step with the artefact you are holding when it is done. If a step produces nothing you could show someone, it is not a step — it is a paragraph pretending to be one.
Each guide also carries a copy-pasteable artifact: an approval checklist, a policy skeleton, a field set, a worksheet. That is deliberate. It is the half of the page worth arriving for, and keeping it inside the guide that teaches it means one page serves both the person searching how to do the thing and the person searching for the template.
Sequence
- Find out what you actually run
Shadow AI discovery and an MCP server audit. Everything downstream is guesswork until this exists, and it is the step most often skipped because it produces bad news.
- Make the reviews repeatable
A skill review procedure and an injection blast-radius assessment. These turn 'somebody looked at it' into a decision anyone can reproduce and disagree with.
- Write the policy the inventory can support
An AI usage policy drafted after discovery says enforceable things. Drafted before, it says aspirational ones, and everybody learns to route around it.
- Make it provable and measurable
An AI-BOM for the auditor, incident procedure for the bad week, and spend attribution for the quarterly conversation about cost.
8 / 8 guides
Nothing matches that. Try a different term or clear the filter.
- Assess
How to audit an MCP server before you approve it
An MCP server is not a library you call. It is a set of tools a model can invoke on its own initiative, described in text the model reads as instruction. That single difference invalidates most of a normal dependency review.
Whoever signs off third-party tooling — usually a security or platform engineer · Half a day for your first server. Under an hour once the checklist is habit.
- Assess
How to review an agent skill before it reaches a laptop
A skill is a folder: some markdown telling an agent how to behave, and often scripts the agent is expected to run. It is installed by copying it into place. There is no publisher identity, no signature, no version pin, and no diff on update.
The engineer who owns developer tooling, with security review on anything that executes · An hour or two per skill. Most of it is reading, not tooling.
- Govern
How to find and shut down shadow AI
Blocking AI domains does not remove AI from your company. It removes your visibility of it, moves usage to personal devices, and converts a governance problem you could measure into one you cannot.
Security operations, with the platform team owning the sanctioned replacement · Two to three weeks for a credible first inventory. The conversion work is ongoing.
- Govern
How to write an AI usage policy engineers will follow
A policy that names approved tools is out of date the month you publish it. A policy that classifies data and bounds actions survives the tool churn, because the tools change every quarter and the data does not.
Security or legal, drafted with an engineer who uses these tools daily · A week to draft, two to socialise. Rewrite it in six months — the first version will be wrong somewhere.
- Implement
How to build an AI bill of materials
Your SBOM lists the libraries your code imports. It does not list the model that wrote the code, the skill that told the agent how, or the MCP server that gave it database access. Those are the components that decide what your agents do.
Whoever owns your SBOM programme, extended to cover artefacts · A week for a first inventory of one team. The hard part is keeping it current, not creating it.
- Implement
How to defend an agent against prompt injection
There is no reliable way to make a model distinguish instructions from data, because both arrive as text in the same context. So the goal is not prevention. It is making a successful injection not matter very much.
Whoever designs the agent's permissions — platform or application engineering · The high-value controls are days of work. Treat the whole programme as continuous.
- Respond
How to investigate an AI agent incident
Agent incidents invert normal forensics. The action is usually well logged by the system that received it. What is missing is why the agent decided to do it — and that lives in artefacts and context nobody was recording.
Incident response, with the platform team supplying artefact and session data · Hours to days per incident. The instrumentation work is what determines which.
- Govern
How to track AI spend by team and by project
The invoice is a single number. The questions being asked of you are which teams are driving it, whether the expensive usage is the valuable usage, and what to do when the number doubles — and none of those are answerable from a bill.
Whoever owns the AI budget, working with platform engineering on identity · Two to four weeks to first credible attribution. Ongoing once the identity work is done.
Frequently asked
- Do I need to buy anything to follow these?
- No, and that is a design constraint rather than a marketing line. Every guide is written to be executable with the tools you already have, and each one carries a section stating what the manual path costs in time and where it breaks down at scale. If that section reads as an argument for doing it by hand in a ten-person company, that is because it is one.
- Which guide should we start with?
- Whichever inventory you are missing. In practice that is shadow AI discovery if you do not know which surfaces are in use, or the MCP server audit if you do. Both produce a list, and a list is the only thing that makes the later guides possible — a policy written without one is a wish.
- How current is this?
- Every guide carries the date its sources were last checked, and this set was compiled on 2026-07-25. The vendor-specific mechanics in this space move quickly, so where a control is changing we describe the mechanism rather than assert a current state, and we link the vendor documentation so you can verify rather than trust us.
- Can we adapt the templates for our own company?
- That is what they are for — 8 of the guides here end in a block written to be pasted into your own document and edited. They are deliberately generic on names and specific on structure, because the structure is the part that takes a week to get right and the names take ten minutes.
Reference these guides lean on
- MCP server directoryWhat each connector can reach, and what to restrict first.
- MCP setup by surfaceWhere every AI tool stores its servers, and which admin controls exist.
- AI surfacesWhat each tool natively controls, and the gaps it leaves open.
- GlossaryThe vocabulary these procedures assume, defined with sources.
When the manual version stops scaling
Everything above works by hand, and keeps working until the fleet grows. Vincosha Assay runs the reviews these guides describe before an artifact reaches a laptop; Vincosha Registry makes the approved version provably the installed one; Vincosha Ledger answers the questions the incident and spend guides can only answer manually.