Is your vendor risk programme built for agentic AI?
Six practices a vendor risk programme needs once a supplier’s AI can act rather than only draft — checkable from a register, a contract and your own logs, plus the two places this is already a legal requirement.
Check your vendor AI practice
Every question below is answerable from a vendor risk register, a contract, or your own access logs — not from an assessment or a maturity score. That is the point: these are the practices checkable from outside the vendor relationship itself.
The tool opens on the shape of a programme that added an “AI” question to its vendor questionnaire in 2025 and has not revisited it since — logging is fine, and nothing agent-specific has been built on top of it. Change the answers to yours.
Knowing what you have
- Gap
An inventory of vendor AI agents that hold credentials
Most vendor risk registers ask whether a vendor uses AI and stop there. An agent holding a credential into your environment is a privileged account regardless of which vendor operates it, and an inventory that does not say so cannot be reviewed, let alone prioritised.
- Gap
Agentic AI distinguished from generative AI
An agent that can file, purchase, modify or escalate carries a different risk than a chatbot that drafts text, and the two get conflated in almost every vendor questionnaire that added an "AI" section in 2025. A register that cannot tell them apart cannot tell you which vendors need the other four questions asked first.
Who can stop it
- Gap
A named human owner per agent
The Cloud Security Alliance’s account of the July 2026 Hugging Face incident treats an unowned autonomous agent as an unmanaged privileged identity, not a background job. An agent nobody is named against is exactly that, whichever vendor operates it.
- Gap
Clear kill-switch authority and scope
Kill-switch authority is what separates a bounded incident from a multi-day one. "Someone at the vendor can probably do something" is not an answer to who, how fast, or what stopping it actually stops.
- In place
Agent activity distinguishable from human activity in your logs
What the contract says
- Gap
Clarity on what an agent ingests and what it can execute
An agent that ingests untrusted content and can act on what it reads is the route the July 2026 incident actually used — through a system with no relationship to the agent’s original task. Not knowing the ingest-to-execute path is not knowing where that route runs.
- Gap
Ongoing disclosure of new agentic capability, not just at onboarding
A vendor assessed before it had agents can add one afterwards without ever triggering another review, because most contracts only look at what a vendor does on the day it is signed. Agentic features are shipping fast enough that "as assessed at onboarding" is already out of date for a lot of live contracts.
Where this is already a legal requirement, not a practice
- Any Data Fiduciary using an AI vendor that processes personal data: Your DPDP obligations do not stop at your own systems. A Data Fiduciary is answerable for a Data Processor's conduct, and nothing in the DPDP Rules, 2025 exempts a processor because the processing happens to run through a model rather than a script. The safeguard duties themselves commence on 13 May 2027, but a contract that does not yet flow those obligations down to an AI vendor is a gap to fix on the contract, not one that waits for the commencement date.
- IFSC regulated entities: Critical service providers must be able to show frontier-AI preparedness. IFSCA Frontier AI Cyber Advisory, 2026 requires critical service providers to assess frontier-AI risk and furnish evidence of preparedness on request — one of the six Annexure A items drafted with "shall" inside a document titled an advisory. If a vendor cannot produce that evidence today, the gap is real regardless of how the covering page reads.
Take this away as a one-page vendor AI risk brief
Everything above is yours already. This is the version you can put in front of your team — the same result with your details on it, the owner columns your incident file needs, and the checklist attached. It opens here and lands in your inbox, so it is to hand when you actually need it rather than in a tab you closed.
The four questions behind this check
In July 2026, the Cloud Security Alliance's account of the Hugging Face incident described an autonomous agent reaching a production system through a third party that had nothing to do with its original task. The lesson was not about that vendor's models — it was that an agent pursuing a goal will route around an obstacle through whatever adjacent system is weakest. That makes a supplier's AI adoption part of your attack surface, and it is the reasoning behind the six practices above. For the full account, see what agentic AI does to your attack surface.
Why none of this cites an Indian regulation
Agentic AI is not named in CSCRF, the RBI 2026 cyber family, or the IRDAI Guidelines. The six practices above are scored as practice rather than obligation because that is what they are — and claiming otherwise would misstate what is actually required, which would also undermine the two places below where a real citation does apply. For who answers when an agent acts under India's existing accountability instruments, see agentic AI accountability in India.
Indicative, and not legal advice. The six practices are drawn from the four questions worth asking a supplier, not from a regulatory text, and are scored as such. The two context items cite the instruments they name directly. Every instrument cited here was verified against the issuing regulator's own notification on .
Questions this page answers
- Does any Indian regulation require vendor AI risk management?
- Not by name. Agentic AI is not named in CSCRF, the RBI 2026 cyber Directions, or the IRDAI Guidelines, so the six practices this tool checks are drawn from vendor-risk reasoning rather than from a citation. Two narrower exceptions do carry legal weight: a Data Fiduciary is answerable for a Data Processor’s conduct under the DPDP Rules regardless of whether an AI system is involved, and IFSCA’s 2026 frontier-AI advisory requires an IFSC entity’s critical service providers to furnish evidence of preparedness.
- What is the difference between agentic AI and generative AI for vendor risk?
- A generative feature drafts or summarises; an agentic one acts in multiple steps toward a goal — filing, purchasing, modifying, escalating. Most vendor questionnaires that added an AI section in 2025 ask only whether a vendor uses AI, which conflates the two. An agent that can act carries a different risk than one that only drafts text, and a register that cannot distinguish them cannot prioritise which vendors need closer review.
- Why does a named human owner matter for a vendor’s AI agent?
- Because an agent with no named owner is an unmanaged privileged account. The Cloud Security Alliance’s account of the July 2026 Hugging Face incident treats autonomous agents as privileged insider identities rather than background jobs, and an unowned privileged identity should be answered for as one, whichever vendor operates it.
- Do our DPDP obligations cover a vendor’s AI system?
- Yes, in principle, and the commencement date does not defer the exposure. A Data Fiduciary is answerable for a Data Processor’s conduct, and nothing in the DPDP Rules, 2025 exempts a processor because the processing runs through a model rather than a script. The safeguard duties themselves commence on 13 May 2027, but a contract that does not yet flow those obligations down to an AI vendor is a gap worth fixing now, not one that waits for the date.