Third-Party Agent Risk: How to Vet the Agents You Didn't Build

Table of Contents

• What "Third-Party Agent Risk" Actually Means
• Why an Agent Isn't Just Another SaaS Vendor
• The Risk Surfaces You Need to Map
• Access and Credentials
• Autonomy and Action Scope
• The Model and Prompt Layer
• The Agent's Own Supply Chain
• A Practical Vetting Process
• Contract and Liability Questions That Matter
• Ongoing Monitoring After You Sign
• Insights Most People Overlook
• Frequently Asked Questions
• Conclusion
• References

What "Third-Party Agent Risk" Actually Means

When you buy Agentic AI-as-a-Service, you're not buying a tool that waits for instructions. You're buying a worker that takes instructions, makes decisions, calls APIs, moves data, and sometimes spends money, on your behalf, inside your perimeter, often without a human watching each step. Third-party agent risk is the exposure you take on when that worker was designed, trained, and operated by someone other than you.

The phrase matters because it draws a hard line. There's the agent you build, where you control the prompts, the tool definitions, the guardrails, and the logs. And there's the agent you don't build, the vertical sales agent, the claims-processing agent, the procurement agent you signed up for last quarter. For the second category, you inherit a stack of decisions you never made and often can't see. You're trusting that the vendor scoped permissions tightly, that they handle prompt injection well, that their model doesn't hallucinate a wire transfer. You usually can't verify any of it directly.

This is the part teams underestimate. Traditional vendor risk assumes the software does roughly the same thing every time. An agent doesn't. Its behavior is probabilistic, its inputs are partly attacker-controllable (anything it reads can carry instructions), and its blast radius scales with the permissions you grant it. So "vetting the agents you don't build" is its own discipline, sitting at the intersection of vendor due diligence, identity management, and AI safety.

Why an Agent Isn't Just Another SaaS Vendor

Run a third-party agent through your normal SaaS procurement checklist and you'll miss most of what matters. The checklist asks whether data is encrypted in transit, whether the vendor has SOC 2, whether there's an SLA. All necessary. None sufficient.

A SaaS app has a bounded, predictable interface. You know what endpoints it calls because a human coded them. An agent decides at runtime which tools to invoke and in what order, based on natural-language reasoning over data you don't fully control. Gartner has repeatedly flagged that agentic AI introduces governance gaps traditional controls weren't built for, precisely because the action set isn't fixed in advance.

Three differences drive the whole risk picture:

It acts, it doesn't just store. A leaky SaaS database is a confidentiality problem. A misbehaving agent with write access is an integrity and availability problem, it can corrupt records, send emails to customers, cancel orders, or trigger downstream automation. The damage is active, not passive.

Its inputs are adversarial by default. Any document, email, web page, or API response the agent reads is a potential injection vector. This is the supply-chain-attack angle that doesn't exist for ordinary software: an attacker doesn't need to breach the vendor, they just need to get text in front of the agent. That's a much lower bar.

Its identity is non-human and often over-privileged. Agents authenticate with service accounts, API keys, or OAuth tokens that frequently carry broad scopes because narrow scoping is tedious. A non-human actor with a standing credential and autonomous decision-making is a genuinely new category of insider risk, closer to a contractor with a master key than to a piece of software.

The Risk Surfaces You Need to Map

Before you can vet anything, you need a map of where a third-party agent can hurt you. Four surfaces matter most.

Access and Credentials

Start here, because access is the multiplier on every other risk. What can this agent reach? Which systems, which data, which actions? The honest answer for most deployments is "more than it needs," because vendors default to broad scopes to reduce support tickets and customers rubber-stamp the OAuth consent screen.

Demand least-privilege scoping as a non-negotiable. The agent should hold the minimum permissions for its job and nothing else, ideally with short-lived credentials rather than standing API keys. Ask the vendor exactly which scopes their agent requests and why. If the answer is vague, or if the agent wants admin-equivalent access "to be safe," that's a finding, not a footnote. The credentials an agent carries are fast becoming the enterprise's most attractive attack surface, and a compromised agent identity hands an attacker everything that identity can touch.

Autonomy and Action Scope

How much can this thing do without a human in the loop? There's a meaningful difference between an agent that drafts a refund for a human to approve and one that issues the refund itself. The vetting question isn't "is autonomy bad", autonomy is the whole point of GaaS economics, it's "where are the stops."

Ask whether the agent has a configurable approval threshold (dollar amount, action type, risk score) above which it must escalate. Ask whether there's a kill switch you control, not just one the vendor controls. Ask what happens to in-flight actions when that switch is thrown. An agent vendor who has genuinely thought about emergency stops and graceful degradation will have crisp answers; one who hasn't will improvise.

The Model and Prompt Layer

You're inheriting the vendor's model choices and their prompt engineering, and both shape risk. Which foundation model sits underneath? Is it a frontier model with strong safety training, a fine-tuned open-weights model, or something the vendor won't disclose? Model opacity is itself a risk signal, not disqualifying, but it tells you how much you'll have to take on faith.

The prompt layer is where injection lives. Anthropic's own guidance on building safe agentic systems stresses isolating untrusted input from instruction context, and you want evidence the vendor does this. How do they separate the agent's system instructions from data it ingests? Do they sanitize tool outputs? Have they tested against known prompt-injection patterns? "We use a really good prompt" is not an answer; a documented input-handling architecture is.

The Agent's Own Supply Chain

Your third-party agent has third parties of its own. It may call other models, other APIs, other agents. It may use the Model Context Protocol to reach external tools, each of which is its own trust boundary with its own known weaknesses. When you onboard one agent, you're often onboarding a small network of dependencies you can't see.

Map the chain as far as the vendor will let you. Which sub-processors handle your data? Which external services does the agent call to do its job? If it hands work to other agents, how is custody of your data tracked across that handoff? The chain-of-custody problem in multi-agent workflows is real: when five agents touch a record, "who did what" can become genuinely unanswerable unless someone designed for it up front.

A Practical Vetting Process

Mapping risk is half the work. Here's a process you can actually run, roughly in order.

1. Classify the deployment by blast radius. Before any vendor conversation, decide what this agent will be allowed to touch and how bad a worst-case action would be. An agent that summarizes support tickets is low-radius. An agent with write access to your billing system is high-radius. The depth of vetting should scale with that number. Don't run a six-week security review on a read-only research agent, and don't fast-track a finance agent because the demo was slick.

2. Send a real security questionnaire, built for agents. Not your generic vendor form. Add the agent-specific questions: permission scopes, autonomy thresholds, injection defenses, model provenance, sub-processors, logging granularity, kill-switch control, incident history. The quality of the answers is itself signal, vendors who've done the work answer precisely.

3. Verify certifications, then read past them. SOC 2 Type II, ISO 27001, and any sector-specific attestations are table stakes for an enterprise buyer. But a SOC 2 report covers the vendor's controls, not your specific agent's behavior. Read the report's scope and exceptions, don't just check that one exists. The AICPA's SOC 2 framework was designed for service organizations broadly; it was never designed to certify that an autonomous agent won't take a harmful action.

4. Run a bounded pilot with full logging. Before production, run the agent in a sandbox or limited-scope environment where you can watch every action it takes. Feed it edge cases. Try to make it misbehave, including light adversarial testing, like embedding instructions in documents it processes. You learn more from one week of observed behavior than from any questionnaire.

5. Insist on audit logs you can read. You need a tamper-evident record of every action the agent took, every tool it called, and ideally the reasoning trace behind consequential decisions. If the vendor can't give you exportable, queryable logs, you've lost your ability to investigate when something goes wrong, and with autonomous systems, something eventually will.

6. Assign a human accountable owner. Every third-party agent in your environment should have a named person responsible for it, not a team, a person. Shadow agents, deployed by an enthusiastic employee with a corporate card and no review, are how unvetted autonomy enters the building. A named owner is the cheapest control you can put in place.

Contract and Liability Questions That Matter

Vetting doesn't end with security; it ends with the contract. When a third-party agent makes a costly mistake, the question of who pays is settled by paper signed months earlier, and most GaaS contracts today are written to favor the vendor.

Read the liability section first. Many agent vendors cap liability at fees paid and disclaim responsibility for the agent's autonomous decisions, which is precisely the risk you're worried about. Push on indemnification: does the vendor stand behind the agent's actions, or does all the downstream risk land on you? Ask what the liability waiver actually covers, because "the agent did it" is not a defense you want to discover the limits of during litigation.

Get the incident terms in writing too. How fast must the vendor disclose a breach or a rogue-action incident? What's their obligation to preserve forensic data so you can investigate? Does the contract acknowledge the regulatory frameworks you operate under, and as obligations like the EU AI Act's provider requirements harden, does the vendor commit to keeping pace? A vendor who treats these as reasonable asks is a vendor who's thought about governance. One who balks is telling you something.

Ongoing Monitoring After You Sign

A clean vetting at onboarding is a snapshot, and agents drift. The vendor updates the underlying model, expands the tool set, changes a prompt, and the thing you vetted six months ago isn't the thing running today. Third-party agent risk is a continuous-monitoring problem, not a one-time gate.

Set up review triggers: any change to the agent's permissions, any new tool it gains access to, any model swap. Re-run a slice of your vetting on a schedule, quarterly for high-radius agents. Watch your own logs for behavioral drift, actions the agent never used to take, escalations that stopped happening, data flows that changed shape. And keep the kill switch tested. An emergency stop you've never exercised is a hope, not a control.

The teams that handle this well treat third-party agents the way mature organizations treat privileged human contractors: scoped access, named ownership, continuous oversight, and a clear off-boarding path. The agents change faster than contractors do, which only makes the discipline more important.

Insights Most People Overlook

The riskiest agent is the one nobody decided to buy. Most third-party agent risk doesn't enter through procurement, it enters through an employee who signed up for a tool, connected it to the company Google Workspace, and never told anyone. Your vetting process is irrelevant to agents that bypass it entirely. The highest-leverage move many organizations can make isn't a better questionnaire; it's discovering the unsanctioned agents already running, then governing those. Vetting assumes you know the agent exists.

A SOC 2 report can make you less safe by creating false confidence. Buyers see the badge and stand down. But SOC 2 attests to a vendor's operational controls over a period; it says nothing about whether their agent resists prompt injection or scopes permissions tightly. Treating a compliance certificate as proof of agent safety is a category error, and a common one. The certificate is necessary and almost completely beside the point for the risks that are specific to autonomy.

You should vet the agent's inputs as carefully as the agent. Everyone focuses on the vendor and the model. But the actual attack surface is whatever the agent reads, and that's often your data, your customers' messages, your documents. An attacker who can get text in front of the agent doesn't need to compromise the vendor at all. This flips the usual supply-chain frame: sometimes the poisoned link in the chain is content flowing through your own systems, which means securing the agent's tools and data sources matters as much as securing the agent.

"Human in the loop" quietly becomes "human rubber-stamping the loop." Approval gates look like a strong control on paper. In practice, when an agent generates fifty approvals an hour and forty-nine are fine, the human approves the fiftieth without reading it. Alert fatigue turns oversight into theater. If you're relying on human approval as your safety net, you have to design the workflow so the human can actually exercise judgment, which usually means the agent should escalate rarely and meaningfully, not constantly.

Cheaper per-task pricing can mean a thinner safety budget. GaaS economics push toward the lowest-cost provider per outcome. But the safety work, injection testing, scoped permissions, audit infrastructure, incident response, costs money and shows up nowhere in the per-task price. When a vendor undercuts the market dramatically, ask what got cut. Sometimes it's margin. Sometimes it's the security engineering you're now inheriting the absence of.

Frequently Asked Questions

How is vetting a third-party agent different from a standard vendor security review? A standard review assumes deterministic software with a fixed interface. Agent vetting has to account for probabilistic behavior, runtime tool selection, adversarial inputs (prompt injection), non-human identity with standing credentials, and autonomous actions with real blast radius. You add agent-specific questions about permission scopes, autonomy thresholds, injection defenses, and kill switches, none of which appear on a normal SaaS form.

What's the single most important thing to check? Access scope. Everything else is a multiplier on what the agent can reach. An agent with tightly scoped, least-privilege, short-lived credentials has a small blast radius even if it misbehaves. An over-privileged agent turns any failure, injection, hallucination, vendor compromise, into a major incident.

Do I really need to worry about prompt injection from a reputable vendor? Yes. Injection isn't a flaw in a specific vendor's code; it's a structural property of agents that read untrusted text. Even strong vendors can only mitigate it, not eliminate it. Ask for their input-isolation architecture and test it yourself in a pilot. The risk scales with how much external content the agent ingests.

Who should own a third-party agent inside my organization? A named individual, not a committee and not "IT." That person is accountable for the agent's scope, its behavior, its monitoring, and its off-boarding. Anonymous ownership is how agents drift out of governance and how shadow agents proliferate.

How often should I re-vet an agent I've already approved? On a schedule tied to blast radius, quarterly for high-radius agents, plus event-driven re-reviews triggered by any model swap, permission change, or new tool the agent gains. Agents change faster than traditional software, so a one-time gate goes stale quickly.

What contract terms protect me if a rented agent causes harm? Look for indemnification that covers the agent's autonomous actions, a liability cap you can live with (many default to fees-paid, which is often inadequate), fast breach-and-incident disclosure obligations, forensic data preservation, and commitments to relevant regulatory compliance. If the contract disclaims responsibility for exactly the autonomous behavior you're buying, that's a problem.

Can I outsource the vetting itself to a third party? Increasingly, yes, there's an emerging market for agent trust certifications and independent assessments, and they can reduce your workload. But treat external certification the way you'd treat SOC 2: useful evidence, not a substitute for understanding your own deployment's blast radius and running your own pilot.

Conclusion

The center of gravity in enterprise AI is shifting from agents you build to agents you rent, and that shift moves the risk from your codebase into someone else's autonomy. Third-party agent risk is its own discipline because an agent isn't a tool that stores data, it's a non-human actor that holds credentials, reads adversarial inputs, makes probabilistic decisions, and acts inside your perimeter with a blast radius set by the permissions you grant.

Vetting it well means mapping four surfaces, access, autonomy, the model-and-prompt layer, and the agent's own supply chain, then running a process that scales with blast radius: classify, question with agent-specific depth, verify certifications without over-trusting them, pilot with full logging, demand readable audit trails, and assign a named human owner. The contract closes the loop, and continuous monitoring keeps it from going stale. Across the broader work of agent trust, safety, and governance, this is the practical front line: you can't write the agent's code, but you can absolutely control what it's allowed to touch, prove what it did, and decide who answers for it when it gets something wrong.

References

• Gartner, What Is Agentic AI and Why It Demands New Governance
• Anthropic, Building Effective (and Safe) Agents
• AICPA & CIMA, SOC 2 Examination Framework