For CISO
AI security for CISOs
Your organisation adopted AI without a procurement decision. The exposure did not arrive through a vendor you approved — it arrived as extensions, CLIs and connectors installed by individuals, and most of it is not in your threat model.
What you are actually accountable for
You own the answer to 'are we exposed', and you own it without having chosen the tools that created the exposure. AI adoption in most organisations happened bottom-up and fast: engineers installed coding agents, teams bought seats on cards, and connectors were pointed at internal systems by people who had the credentials to do it. You are accountable for a footprint you did not design and cannot fully see, and the honest first move is inventory rather than policy.
What is landing on you right now
- A board question with no data behind it
'What is our AI exposure' is being asked at board level, and the available answer is usually a list of approved vendors — which is not an exposure assessment. It describes procurement, not access.
- Customer security questionnaires that now ask about AI
Enterprise buyers have added AI sections covering data handling, subprocessors, model training and agent access. These are contractual, not advisory, and a vague answer costs deals.
- A threat model that stops at the model
Most AI threat models cover prompt content and data leakage to a provider. They rarely cover the artefact layer — the skills, rules, hooks and connectors that determine what an agent does — which is where current exposure concentrates.
- Agents holding credentials nobody scoped
Coding agents typically run with a developer's own credentials: SSH keys, cloud profile, repository write. That is a privilege grant nobody reviewed, made implicitly by the act of installing a tool.
Questions you are being asked and cannot answer
the gap
- Which AI tools are in use across the company, including the ones bought on cards?
- Which MCP servers or connectors hold credentials to our production systems, and who approved them?
- If a malicious skill reached a developer machine, how many other machines have it and since when?
- For last Tuesday's agent-caused incident, which artefact versions were loaded in that session?
- Which agents can simultaneously read private data, ingest untrusted content, and make outbound requests?
The analysis, from where you are standing
The reason the standard AI threat model misses is that it inherited its shape from data-loss prevention. It asks what data goes to which provider under which terms — a real question, and one your legal team is probably handling. But the incidents that will actually reach you are not about a provider reading your prompts. They are about an agent, holding real credentials, being persuaded by content it read to do something it should not have. That is an authorisation problem wearing an AI costume.
The artefact layer is the part with no owner. Every AI surface loads instructions, rules, connector definitions and lifecycle scripts that determine its behaviour, and these arrive by copying files — no publisher identity, no signature, no version pin, no diff on update, no scan. It is the state dependency management was in before lockfiles, applied to components with more privilege than most dependencies. Your software supply chain programme does not cover it, because there is no manifest for a scanner to read.
The consequence that matters for your role is scoping. A compromised machine is one blast radius. A poisoned artefact is a blast radius that spans every machine that loaded it, for as long as it was present, and it re-arrives through the same channel after you rebuild the host. Most organisations currently cannot enumerate which machines hold which artefact versions, which means they cannot scope an incident of this class at all — and 'we cannot determine the blast radius' is a materially worse sentence to say to a board than any specific finding.
The useful triage frame is the lethal trifecta: private data access, exposure to untrusted content, and an external communication channel. An agent with all three can be made to read your secrets and send them somewhere. Auditing your agents against those three properties is a short exercise that produces a ranked list immediately, and it does not require you to have solved inventory first.
What to do — the end state
- Inventory AI surfaces from seven sources, not from procurement
Egress logs, OAuth grants, IDE and browser extension inventories, package-manager telemetry, expense data, repository search, and per-surface MCP configs. Procurement records show what you bought; these show what is running.
- Rank findings by data reach, never by user count
Forty people using a chat window is a policy conversation. One unsanctioned connector holding a production credential is an incident with a future date, and it sits at the bottom of any popularity-sorted list.
- Audit every agent against the lethal trifecta
Private data access, untrusted content exposure, external communication. Three yeses is an exfiltration path. Removing egress is usually the cheapest leg to break and buys more than any input filter.
- Establish whether agents run as people or as services
If your coding agents use developers' own credentials, every agent's blast radius equals that developer's access. Dedicated service identities with least-privilege scopes is the highest-leverage control available and it is pure configuration.
- Require a named approval route for artefacts
Skills, rules, hooks and MCP servers need a reviewer, a review standard and a version pin. Without this, individuals are making privilege decisions weekly with no record.
- Extend the threat model to persistent injection
Add poisoned tool descriptions, malicious skills and tampered rules files as their own category. They differ from runtime injection in the property that matters to you: they affect every session on every machine that holds them.
- Confirm you can scope an artefact-caused incident
Ask your team, today, which machines hold a given skill version. If the answer requires asking people, record that as a finding — inability to scope is the most consequential gap on this list.
- Verify data terms in writing per surface, per plan
Retention and training-opt-out differ by vendor, by plan and by whether someone used a personal account. Get it in writing per surface and store it where the questionnaire answer is drafted.
- Instrument before you need it
Tool calls with arguments, tied to a session identifier, plus artefact versions per session. Both must exist before the incident to be worth anything, which is the argument for funding them now.
- Write the gap list and put it in the risk register
Name what you cannot currently answer and what it would cost to close. An honest register entry is stronger with a board and an auditor than a control you have asserted but cannot evidence.
What to do first — the order
- Weeks 1–3 · See it
Run the seven-source inventory and the trifecta audit. Do not write policy yet. Produce a ranked list of real exposures and a candid statement of what you could not determine.
- Weeks 3–6 · Bound it
Fix credentials first — service identities, least privilege, read/write separation — then break an egress leg wherever the trifecta is complete. These are configuration changes with the largest risk reduction per hour spent.
- Weeks 6–10 · Route it
Stand up an artefact approval route with a named owner and a review standard, and a sanctioned surface that is genuinely easier than the shadow path. Prohibition without a better default just relocates usage.
- Quarter 2 · Evidence it
Close the instrumentation gaps in priority order: tool-call logging, then artefact versions per session, then per-machine placement. This is what converts assertions into evidence.
What to report upward, and the trap in each
- Percentage of AI surfaces under sanctioned management
The denominator is the hard part and the honest one. If it comes from procurement records rather than discovery, the number is decorative.
- Agents with a complete lethal trifecta
Should trend to zero. Unlike most security metrics this one is precise, cheap to compute and directly tied to an exfiltration path.
- Share of agents running as dedicated service identities
A direct proxy for blast radius. Watch for the reverse trap: a service identity granted broader scope than the human it replaced is worse, not better.
- Artefacts installed from a reviewed, pinned source
Measures whether the approval route is actually used. A high number with a slow route means people are waiting, not complying — check the turnaround time alongside it.
- Time to scope an artefact-caused incident
Test it with a tabletop rather than waiting for a real one. If the answer is 'we would ask people', the metric is not yet measurable and that is the finding.
Where we fit, in your order
- Vincosha Assay
Answers 'was this reviewed before it reached a laptop' with a scan rather than a promise, which is the control your artefact-approval route needs to be more than a ticket queue.
- Vincosha Registry
Produces the placement data that makes an artefact-caused incident scopeable: which machines hold which pinned versions, since when.
- Vincosha Ledger
Records which artefact versions were active in a given session, which is the question every post-incident review asks and almost no organisation can currently answer.
Frequently asked
- Is this not covered by our existing software supply chain programme?
- It is the same category of risk and none of the same tooling applies. SBOM and dependency scanning work by reading manifests and lockfiles; skills, rules files and MCP configurations are not declared dependencies, so there is nothing for those tools to parse. The concepts transfer, the instrumentation does not.
- Our AI vendors have enterprise admin controls. Is that not enough?
- Configure them fully — they are real and you are paying for them. What no single vendor console can do is tell you that the same connector is attached to three different surfaces, that versions differ between machines, or which artefact versions were live during an incident. Those questions span vendors, so the answer has to as well.
- What should I tell the board this quarter?
- Give them the discovery result and the trifecta count, both of which you can produce in three weeks, and be explicit about what you cannot yet determine. A named gap with a cost to close is a stronger board item than a maturity score, and it is the version that survives follow-up questions.
- How much of this needs a purchase?
- The inventory, the trifecta audit, credential scoping and the approval route are all configuration and process — do them first regardless. Tooling becomes necessary at the point where you need continuous, fleet-wide answers rather than point-in-time ones, which is typically the instrumentation phase.
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.