.avif)
%201.svg)
HIPAA Compliance Checklist for 2025
Ask a security lead which SaaS tools they've approved, and they'll pull up a clean list. Ask which tools can see confidential data and might be feeding it into an AI model, and most go quiet.
This happens more often. People feed contracts and other confidential material into tools their company already pays for, with no real read on where that data ends up once it's in, tools that already cleared procurement and legal long before any AI feature showed up.
That's the actual shape of the problem, and it's what most AI vendor risk assessment programs still miss. A tool you already trust can pick up a new capability that was never part of what got approved in the first place. The agent didn't need a new approval. It inherited yours.
TL;DR
- Vendor AI agent access almost always comes from inheritance.
- This is already live in tools you use daily: default-on releases, scope-expanding prompts, agents chaining into Slack or Drive, and agents that outlive the employee who set them up.
- Two questions determine your exposure per vendor: can the AI feature be disabled, and does the vendor train on your data.
- A real AI vendor risk assessment treats every embedded agent release as its own approval event.
- CloudEagle.ai surfaces vendor-connected identities and access scope, so security teams can act before an audit finds it first.
1. Your Vendor's Agent Reaches Your Data Because It Inherits Access You Already Granted
Your vendor's agent reaches your data because it runs inside the same OAuth token, service account, and the same integration your security team already approved for the product itself. It doesn't trigger a new review because it doesn't look new.
The systems built to catch unapproved access, SSO logs, provisioning alerts, security review triggers, never see it that way.
Four paths make this possible:
1. OAuth inheritance:
A vendor integration connected through OAuth holds a token with a defined scope.
When the vendor later ships an AI agent that runs inside that integration, the agent operates under the same token; no separate grant is required.
2. Service account inheritance:
Enterprise integrations often run on service accounts IT provisioned during onboarding. When a vendor's new AI agent uses that same account, it inherits whatever broad or admin-level permissions the account was scoped for, not what an AI agent reasoning over your data should have.
3. In-product permission expansion:
Agents frequently ask for more access on first run, calendar, email, files, "to give you the best experience," and a user clicks allow inside the vendor's UI without security ever seeing the request.
4. Third-party chaining:
Agents extend outward on their own, sending summaries to Slack, pulling context from Drive, logging outputs to an analytics platform. Each connection is a data pathway that the original vendor relationship never covered.
This mechanism has a real security cost. Nearly a fifth of cloud intrusions in 2025 involved a compromised third-party relationship, with SaaS integrations and OAuth tokens among the most common entry points. That's the exact inheritance path a vendor's own AI agent uses to reach your data, just without the intrusion.
"I'm putting all sorts of stuff into an approved tool to get my output. Lots of contracts, lots of confidential stuff. Is it proprietary? I have no idea."
A security leader at a mid-sized software company, describing a tool her company already pays for.
This is also why the mechanism is invisible to the controls built for a different problem:
- Shadow AI gets caught by browser plugins and SSO discovery because it looks like new, unapproved activity, an employee going around IT to use a public AI tool.
- A vendor's embedded agent doesn't get caught because the app is already approved, the traffic goes to an already-whitelisted domain, and the employee didn't do anything differently. CloudEagle.ai has covered that distinction in depth separately.
The vendor didn't change. What changed is that the product now contains an identity that can act on your data, one that was never part of any AI vendor risk assessment.
2. Four Ways This Shows Up Inside Tools You Already Approved
Each one is a pattern of security, and IT teams are already seeing inside tools that passed their original review, and each one is exactly the kind of exposure an AI vendor risk assessment is supposed to catch before it becomes an incident.
1. The enabled-by-default agent:
A vendor ships an AI assistant turned on by default in the next release.
Gartner estimates that fewer than 5% of enterprise applications carry embedded task-specific AI agents today, and projects that share will reach 40% by the end of 2026. The agent activates for every user at once, using the integration's existing access, with no change notification to IT and before anyone reviews it.
2. The scope-expanding setup prompt:
An embedded agent inside an HR platform asks for payroll data and performance records during configuration, plus internal communications, and the HR admin clicks through.
The resulting scope ends up broader than what the original HR platform approval, Legal, or Security ever signed off on.
3. The integration-chaining agent:
A vendor's AI agent connects onward to Slack for summaries, to Drive for context, and to a third-party analytics tool to log outputs.
Each hop is a new data pathway that sits outside the original vendor risk assessment, and the combined footprint of all three routinely exceeds what any single approval covered.
4. The orphaned vendor agent:
The employee who configured a vendor's AI agent leaves the company. Offboarding revokes their personal access.
The agent, authenticated on its own service account, keeps running and keeps processing data. No human is accountable for it.
The common thread across all four: the agent is operating on data it inherited, and there's no clean way to claw that access back without restricting the whole product.
3. The Two Questions That Determine Your Exposure
Two questions carry most of the weight in any AI vendor risk assessment: can you turn the feature off, and does the vendor use your data to train its models?
Can the feature be disabled at the admin level?
Some vendors expose a tenant-wide switch. Others bury it behind a support ticket or don't offer one at all, in which case the only lever left is restricting the whole product.
Does the vendor train on your data?
This is a DPA and terms-of-service question, not a settings-page question, and the default answer is often yes unless someone opts out.
Salesforce's Main Services Agreement has permitted this since 2018, and a self-service toggle only became visible in its Spring '26 release. Atlassian is rolling out a similar default for Jira and Confluence in August 2026, with in-app data on by default at the Free and Standard tiers.
Mapping any vendor's AI feature against these two questions is the fastest version of an AI vendor risk assessment you can run today:
Most organizations can't answer both questions for more than a handful of their vendors.
In financial services, 72% of institutions report only partial awareness of which vendors are using AI at all, which means the majority of any given vendor portfolio hasn't even cleared the first question of a basic AI vendor risk assessment, let alone been scored against both.
4. What to Add to Your AI Vendor Risk Assessment
An AI vendor risk assessment built for this problem treats every embedded agent release as a new approval event, separate from the vendor approval that already happened, and adds a short set of questions no standard vendor questionnaire currently asks.
At the program level, four changes matter most for any team updating its AI vendor risk assessment process:
- Treat agent releases as new approval events: A vendor shipping or materially updating an AI agent should trigger its own review: what identity did it create, what access did it request, what data can it now reach.
- Inventory vendor-connected identities as NHIs: Every embedded AI agent creates at least one non-human identity inside your environment. That identity needs an owner and a review cadence, the same governance already applied to internally built service accounts.
- Re-check DPA scope against what the agent actually does: If the agent reasons over data the original DPA never contemplated, the agreement needs updating or the agent's access needs restricting. Don't assume the original DPA still applies just because the vendor relationship predates the agent.
- Monitor for permission expansion after go-live: Agents request more access over time through in-product prompts that never reach IT. A monitoring layer that flags new permission grants for already-approved vendors catches this before it becomes an incident.
At the document level, five questions turn this from a program principle into something you can send a vendor this week:
- Does the product include embedded AI features or agents, and are they enabled by default or opt-in?
- What data can the AI feature access, and is that covered under our existing DPA or does it require a separate agreement?
- How will you notify us when a new AI feature changes what data it can access?
- Does the AI feature create new identities, service accounts, OAuth connections, or API keys in our environment, and what is their documented lifecycle?
- Has the AI feature undergone a security assessment separate from the core product, and can that assessment be shared?
This is also where third-party AI agent risk assessment differs structurally from traditional vendor risk work. Traditional TPRM assesses how a vendor handles data it processes.
An embedded agent creates an identity that can act on that data independently, which is a different risk model than a questionnaire about data handling was ever built to catch.
5. How CloudEagle.ai Identifies Vendor AI Agent Access Across Your Stack
Security teams can't run an AI vendor risk assessment, or manage third-party AI agent risk, on identities they can't see. CloudEagle.ai closes that visibility gap without claiming to rate vendor risk itself.
a) Every app with embedded Gen AI, flagged and scored automatically:
Most security teams have no inventory of which apps in their stack even have embedded Gen AI, let alone whether it can be turned off. Manually checking product documentation and terms of service across hundreds of vendors doesn't scale, and it goes stale the moment a vendor ships an update.
How CloudEagle.ai solves it:
- Flags every application in your inventory with embedded Gen AI capabilities, separated from apps that don't have it
- Surfaces whether the admin-level disable option exists for each flagged app, pulled from vendor documentation and terms
- Pulls the vendor's current data training policy directly from the DPA and terms of service
Every flagged app lands with a Gen AI risk score, built from disable status and training policy, plus data residency and the vendor's security certifications. A security team gets a prioritized list instead of a database to read manually. CloudEagle.ai's AI Governance capability covers the GenAI risk scoring mechanics in more depth.
b) Every vendor-connected identity, inventoried alongside your internal ones:
Vendor-connected AI agents create identities that most security teams never inventory as identities at all, because they sit outside the human-user review process entirely and nobody set up a person to own them.
How CloudEagle.ai solves it:
- Surfaces every OAuth token, service account, and API key a vendor's product connects to your environment, alongside internally created NHIs in one inventory
- Flags when a vendor-connected identity's access scope has expanded past what the original vendor approval covered
- Detects new identity creation the day a vendor's AI agent spins one up, not at the next scheduled audit
Machine identities already outnumber human identities by more than 100 to 1 inside the average enterprise, and most of those credentials are created automatically and rarely revoked. A vendor-connected AI agent is one more identity added to that pile, usually without an owner attached from day one.
c) Vendor-connected access, revoked the moment the employee who owned it leaves:
Offboarding processes revoke a departing employee's own access, but they weren't built to catch a service account that employee authorized on a vendor's behalf.
How CloudEagle.ai solves it:
- Ties every vendor-connected identity to the human who set it up, at the moment it's discovered
- Flags vendor-connected access still active after that employee's own offboarding date
- Routes orphaned vendor identities into the same review queue as internal service accounts, instead of a separate manual process
CloudEagle.ai's research found that 48% of companies had former employees retaining access to active tools, and vendor-connected identities are the category most likely to survive an offboarding cycle undetected.
Bloom & Wild saved 2,890 hours a year and eliminated the lingering access that manual deprovisioning had been leaving behind after automating onboarding and offboarding through CloudEagle.ai. That's the same gap that lets an orphaned vendor agent keep running today.
CloudEagle.ai doesn't assess vendor risk directly. It gives security teams visibility into which vendor-connected identities exist in their environment and what access they hold, which is the prerequisite any real AI vendor risk assessment needs before it can move past guesswork.
48% of Former Employees Still Have Vendor Agent Access After Leaving
6. FAQs
1. How do you prevent AI agents from becoming insider threats?
Make agent ownership and access scope part of your AI vendor risk assessment, then review that scope on a set cadence instead of at renewal only.
2. How does AI work in embedded systems?
An embedded AI agent runs inside the host application and typically inherits that application's existing data access and permission scope.
3. How to secure your AI agent?
For vendor-shipped agents specifically: disable the feature where an admin control exists, restrict access where it doesn't, and monitor for permission changes after setup.
4. How to prevent AI systems from misusing personal data?
Confirm the vendor's DPA explicitly excludes personal data from model training, and use admin-level opt-outs where the vendor provides them.
See how CloudEagle.ai gives your AI vendor risk assessment the visibility it's missing today → book a demo.
The Vendor Was Approved. Their Agent Wasn't.
.avif)
.avif)
.avif)
.png)
