Governing AI Usage Inside Third-Party Apps

Governing AI in third-party apps is the practice of applying identity governance, least privilege, and runtime monitoring to the AI your vendors ship inside their own products. It is not the old "the vendor holds our data" concern. It is newer and stranger: the vendor's AI now acts inside your environment, on behalf of your users, with credentials you never issued and tools you never approved.

Nearly every enterprise SaaS platform now embeds agents, copilots, or connected tools that run with the vendor's identity and your data. When a platform like Salesforce Agentforce, Microsoft Copilot Studio, or ChatGPT Enterprise turns on inside your tenant, those agents inherit user permissions, OAuth scopes, and connector authorities. One agent can chain actions across five apps in seconds. Your third-party risk program does not see a single step of it.

That is the shape of the problem. An agent is a non-human identity with real authority and no lunch break. It reads, writes, forwards, and calls other agents faster than any person, and it does so under permissions someone granted once and forgot. Treat it as a vendor feature and you miss it. Treat it as an identity with a blast radius and you can start to govern it.

Traditional third-party risk management captures a vendor at one point in time: a questionnaire, a SOC 2 letter, a penetration test summary. That model breaks the moment a vendor enables an AI feature, because the risk it measures stops being static.

Here is the failure in plain terms. A questionnaire asks, "Do you use AI to process customer data?" The vendor answers "yes" and names a model provider. That answer tells you nothing about how many agents your own employees built inside that vendor last week, which of them run with admin-level credentials, what tools those agents connect to, whether an agent whose creator left the company still runs on inherited access, or what data any of them actually touched at runtime.

Static review sees theoretical configuration. It cannot see effective access. Security teams end up chasing what could go wrong with no evidence of what did, which is expensive and unsatisfying in equal measure.

The direction the discipline is heading is dynamic: a third-party risk practice that answers runtime questions instead of paperwork questions. Was the agent used? Who triggered it? What data was reached? Did the action succeed? Answering those means watching agents where they run, not where they were declared. That is a directional shift in how TPRM works, not a box you buy off a shelf.

Governing AI in third-party apps holds up when you run it as a repeatable workflow rather than a one-time audit. Five stages, in order:

1. Discovery. Inventory every agent across every platform in use: Copilot Studio, Agentforce, Bedrock, Vertex, ChatGPT Enterprise, Snowflake Cortex, ServiceNow Now Assist, Moveworks, n8n, and the rest. Then inventory the connected tools those agents call, sanctioned and shadow alike.

2. Ownership. For each agent, name the creator, the current owner, and the business reason it exists. Flag any agent whose owner has been disabled. Orphaned agents do not stop running when their creator's account does.

3. Effective-access mapping. Correlate each agent's configuration to the entitlements its underlying identity actually holds inside each connected app. This is where a low-privilege user quietly operating a high-privilege agent finally becomes visible.

4. Risk scoring and toxic combinations. Rank by combined factors. A shadow agent with org-wide reach into sensitive data is a critical finding even when each factor on its own would rate as medium.

5. Continuous monitoring. Watch behavior over time. Alert on privilege escalation, unauthorized tool calls, data movement, and confused-deputy patterns where one agent's authority gets borrowed for a request it should never serve.

Skip a stage and the program leaks. In practice, organizations that run discovery for the first time routinely find thousands of agents already created with no prior oversight, and hundreds of copilots that no one had recorded. You cannot govern what you have never counted.

Write your vendor-facing policy against effective access, not against attestations. The useful question is not "does this vendor have a SOC 2 report" but "what can an agent inside this vendor actually do to our data."

Effective access is concrete. It is not the permission the vendor's configuration page implies an agent might have. It is what the agent's identity can genuinely reach: which service account it authenticates as, which Salesforce objects or Snowflake tables that account can read, which actions it can trigger (export, delete, share, post to an outbound connector), and which other agents it can call. An agent can look harmless on its config screen while its service account holds read access to a table of customer records and write access to a channel that leaves your tenant. Correlating that agent's runtime activity to its real effective access, not to the vendor's theoretical configuration page, is the difference between governance and paperwork.

A workable policy has four layers, each written so it maps to something observable:

Policies at this layer are enforceable because they describe behavior you can actually see at runtime. Policies written only against a questionnaire describe a document, and documents do not act.

An assessment gives you a starting posture. Continuous monitoring gives you runtime truth. You need both, and only one of them updates itself.

Monitoring third-party app AI has to capture new agents as they are created, configuration changes to existing ones, the tools an agent adds and then calls, the data it reads, writes, moves, or forwards, and the moments one agent invokes another with elevated permission. Periodic scans cannot do this. A tool inside a connected server is only visible when the agent actually calls it, so a configuration snapshot misses it and a retroactive log review cannot reconstruct it, because vendor logs are siloed and often incomplete.

One control plane across platforms is the operational payoff. A security engineer should answer "what did this agent touch yesterday" from a single view, not by logging into eight consoles and stitching the answer together by hand. Fewer fire drills, less swivel-chair archaeology.

Reporting and Compliance Evidence

Boards ask direct questions now. How many agents run in our environment? What have they accessed? Who owns them? A security leader who cannot answer inherits the escalation.

Several frameworks already reach vendor-embedded AI, not just models you build in-house. The NIST AI Risk Management Framework applies its govern, map, measure, and manage functions to AI wherever it runs. ISO/IEC 42001 sets management-system requirements that cover vendor AI use. The OWASP Low-Code/No-Code risks speak directly to account impersonation and misconfiguration, which is exactly where over-permissioned and public agents land. MITRE ATLAS catalogs adversary techniques against AI systems, agents included. Check the current text of each before you cite specific control identifiers in an audit; they revise.

Board-level reporting that lands tends to include total agents by platform, agents by risk tier, toxic combinations opened and closed, orphaned agents remediated, and runtime incidents with resolution status. The point of a continuous system is that this evidence generates itself instead of being reassembled by hand the night before the meeting.

Detection without a way to stop an action is just expensive logging. Enforcement puts deterministic guardrails around probabilistic agents, cutting off the option to act at the point where the action happens.

Be exact about what is live. Autonomous runtime enforcement today runs for Anthropic Claude and Microsoft Copilot only. For every other platform (Agentforce, Snowflake Cortex, ServiceNow Now Assist, Moveworks, Bedrock, Vertex, n8n), the model is discover and govern: full inventory, effective-access mapping, policy, and reporting available now, with runtime blocking on the roadmap rather than in production. Do not let a vendor slide from "we can see and govern it" to "we can block it in real time" for platforms where blocking is not yet shipping.

Where enforcement does run, the patterns are specific. Deny an agent invocation when the person triggering it could not have reached the data the agent is about to return. Block a tool call aimed at an unregistered destination. Interrupt a confused-deputy action where an agent's elevated permission is being spent on an unauthorized requester. Stop cross-classification data movement at the instant of the call.

This is not an inline proxy or gateway sitting in the request path. The decision engine works on an Intel Inside model: it hooks into the AI platform's own APIs and returns an allow-or-block decision at the point of action, so the platform stays the platform and the guardrail rides along inside it. Governing AI in third-party apps ends here for a reason. Detection alone leaves the blast radius intact; enforcement is what finally shrinks it, and it does so first for the platforms where the hooks exist today.