For Platform engineering
AI tooling for platform teams
You will be handed two incompatible requirements: make AI tools available to everyone, and make them safe. The trap is solving the second with a ticket queue, because a ticket queue loses to a shadow install every time.
What you are actually accountable for
You own the paved road, which means you own whether the safe path is also the fast path. Security will hand you controls and engineers will hand you complaints, and both are legitimate. The specific failure to avoid is building a governance process whose latency exceeds the cost of going around it — at that point you have not added a control, you have added an incentive, and you will lose visibility of exactly the usage you most needed to see.
What is landing on you right now
- N surfaces, N configuration mechanisms
Every AI surface has its own config location, format and settings hierarchy. Standardising anything means doing it N times and keeping N copies in sync, forever.
- Artefacts spreading by copy-paste
Skills, rules files and MCP configs propagate through gists, DMs and blog posts. There is no publisher identity, no version pin and no diff on update, so you cannot tell what is actually deployed.
- Becoming the connector help desk
If adding an MCP server requires you, you are now a bottleneck on everyone's daily work — and the queue behind you is the argument for bypassing the queue.
- Onboarding that silently degrades
A new engineer's environment is assembled from whatever the last person shared. Six months in, no two machines have the same artefact set and nobody knows which one is correct.
Questions you are being asked and cannot answer
the gap
- What artefacts are actually installed across our fleet right now, and at which versions?
- When someone fixes a rules file, how does that fix reach the other 200 machines?
- Which MCP servers are configured on developer machines, pointed at which internal systems?
- Is a new engineer's day-one environment the same as a five-year engineer's, and which is right?
- If we needed to pull one skill version company-wide today, could we — and how long would it take?
The analysis, from where you are standing
The structural problem is that AI artefacts have every property that makes configuration management hard and none of the properties that make it tractable. They are text files that change behaviour, they live in per-user locations, they differ in format per surface, they have no version metadata, and they are shared socially rather than distributed. If you tried to manage application config this way you would call it an outage waiting to happen; the only reason it feels survivable is that the failures are quiet.
The instinct is to build a golden config and push it with your existing device management. That works for exactly as long as nobody needs anything you did not anticipate — which is about a week, because the value of these tools is that engineers extend them. A locked config produces a shadow config, and now you have two problems and visibility into neither. The design constraint is that people must be able to add what they need, which means your control point has to be *what is available and pinned*, not *what is permitted to change*.
The leverage point most teams miss is that the artefact classes overlap heavily across surfaces. The same MCP server gets attached to three different tools; the same coding standard is expressed as a rules file in each. So the unit of work is not 'configure each surface' but 'maintain one reviewed set and distribute it to every surface', which is one job instead of N and is also the only version that stays consistent.
One thing worth being blunt about internally: version pinning is where you will get pushback and it is the control worth defending. Unpinned artefacts mean the reviewed thing and the installed thing drift apart with no event to notice, so every review your security team does decays to nothing. Pinning is also what makes rollback possible, which is the argument that lands with engineers — it is a reliability feature that happens to be a security control.
What to do — the end state
- Enumerate every surface and its configuration mechanism
Config file location, format, settings hierarchy, and what each surface can enforce centrally versus per-machine. This table is the map for everything else and it does not exist anywhere by default.
- Find the overlap across surfaces
List artefact classes per surface and mark the ones that recur. The overlap is your standardisation target — those are the items where one reviewed source replaces N drifting copies.
- Inventory MCP servers on developer machines
Per-surface config files, via endpoint management or repository search. This is the highest-risk and least-inventoried category, because these connectors often point at internal systems with real credentials.
- Pin every artefact and make rollback work
Version or content hash, recorded and enforced. Sell it internally as rollback rather than as security — it is both, and only one of those framings gets adopted.
- Build an approval route with a latency budget
Write down the turnaround time you are committing to. If adding a reviewed connector takes longer than installing an unreviewed one, your route will lose and you will not be told.
- Give agents service identities, not developer credentials
Dedicated identities with least-privilege scopes, read and write separated where both are needed. This is the single largest blast-radius reduction available and it is yours to implement.
- Make day-one onboarding produce the correct environment
A new engineer should get the reviewed artefact set automatically, not inherit whatever a colleague shared. Onboarding drift is how fleets diverge, and it compounds silently.
- Own the update path deliberately
Decide how a fixed artefact reaches every machine and how you would verify it arrived. If the answer is a message in a channel, your fix reaches whoever read it.
- Configure each vendor's native controls fully
Permission rules, allowlists, sandboxing, org policies. They are real, you are paying for them, and they bound what the artefact layer can do when it goes wrong.
- Instrument placement, not just availability
Knowing what is approved is not knowing what is installed. Per-machine artefact versions with timestamps is the data that makes both incidents and drift visible.
What to do first — the order
- Weeks 1–2 · Map
Build the surface/mechanism table and the artefact-class overlap matrix. Cheap, unglamorous, and it determines whether everything after this is one job or N jobs.
- Weeks 2–4 · Discover
Inventory what is actually installed, MCP configs first. Expect to find connectors pointed at internal systems nobody remembers approving — that finding is what funds the rest.
- Weeks 4–8 · Pave
Stand up one reviewed, pinned artefact set and distribute it to the highest-overlap surfaces. Measure adoption honestly; if engineers are not switching, the paved road is slower than the dirt one.
- Ongoing · Keep the road faster
Track approval turnaround as a service level you owe. The moment it exceeds the cost of a shadow install, you are losing visibility rather than gaining control.
What to report upward, and the trap in each
- Artefact approval turnaround time
The metric that predicts whether governance holds. Everything else on this list depends on it staying low, and it is the one nobody tracks.
- Fleet convergence — machines on the current reviewed set
Measures whether distribution actually works. A high approval count with low convergence means you are approving things that never arrive.
- Share of artefacts version-pinned
Directly proportional to how long a security review stays valid. Unpinned artefacts make every review a point-in-time snapshot of a moving target.
- Time for a fix to reach the whole fleet
Test it deliberately rather than discovering it during an incident. This is also your rollback time, which is the framing that gets it prioritised.
- Day-one environment correctness
Whether a new engineer gets the reviewed set automatically. Watch this rather than trusting it — onboarding drift is invisible until you compare two machines.
Where we fit, in your order
- Vincosha Registry
One versioned, pinned source that distributes the same reviewed artefacts to every surface over a single endpoint — which replaces maintaining N copies with maintaining one.
- Vincosha Assay
Scans artefacts before they reach a laptop, so your approval route is a check rather than a queue you personally staff.
- Vincosha Corpus
Puts internal knowledge inside AI sessions over the same endpoint, which removes a common reason engineers build their own unreviewed connectors.
Frequently asked
- Can we not just manage this with our existing device management?
- For pushing a baseline, yes, and that is a reasonable start. Where it runs out is the part that matters: device management pushes files but has no concept of an artefact version, no review state, and no way to let an engineer add something without leaving your baseline. You end up enforcing a config that people work around rather than distributing a set they want.
- How do we avoid becoming the bottleneck for every new connector?
- Separate approval from installation. Maintain a reviewed catalogue engineers can self-serve from, and reserve your review for things entering the catalogue. The failure mode is per-request approval, which makes your queue length the org's velocity ceiling.
- Is standardising artefacts across surfaces actually realistic?
- For the overlapping classes, yes — the same connectors and the same coding standards genuinely recur, and those are the majority of what matters. Surface-specific mechanisms like hooks will not standardise, and you should not try; keep those per-surface and documented rather than forcing a false uniformity.
- What is the highest-value thing to do first?
- Inventory MCP configurations on developer machines. It is a day of work, it needs no new tooling, and it typically surfaces connectors with credentials to internal systems that nobody approved — which is both the most urgent finding and the most persuasive one internally.
Sources
Written 2026-07-25. Nothing on this page asserts a statistic we did not gather ourselves, and where a regulatory or standards obligation is mentioned it is described in prose and left to your counsel to confirm against the current text rather than paraphrased as fact.