Why partnerships teams need Granur to govern vendors and AI agents

The vendor and agent sprawl problem

Vendor sprawl was already a known problem. Fortune 500 companies now route roughly 75% of total spend through external suppliers, and the average company runs more than 100 SaaS applications — more than any spreadsheet realistically tracks. But the bigger shift is what's arriving next to that traditional vendor list.

By the end of 2026, Gartner expects 40% of enterprise applications to ship with a task-specific AI agent built in, up from less than 5% in 2025 — and that's before counting the standalone agents a team adopts on its own. A recent OutSystems survey of 1,900 IT leaders found 96% of enterprises are already using AI agents in some form, but only 12% have any centralized way to govern them, and 88% have already had a security incident connected to one.

Much of that gap is invisible by design. Microsoft's own research found 71% of UK employees admit to using AI tools their company never approved, more than half of them weekly — and it isn't only individual contributors doing it quietly: the same reporting cites an UpGuard survey finding that 90% of security leaders use unauthorized AI tools themselves, and 69% of CISOs work them into their daily routine. Every one of those tools is, functionally, a new vendor with access to company data and no formal record anywhere.

Why this is now a security and policy problem

The consequences of ungoverned vendors and agents aren't hypothetical, and they aren't limited to IT. Verizon's 2026 Data Breach Investigations Report found that 48% of breaches now involve a third party, and SecurityScorecard's Global Third-Party Breach Report puts the share of 2024 breaches that originated from a third-party compromise at 35.5% — up 6.5 points from the year before, with third-party breaches overall rising roughly 60% year over year.

Most organizations are still governing this risk with a process built for a slower-moving problem. SecurityScorecard found that 67% of organizations still rely on static security audits to assess their vendors, even as 86% of leaders say they're concerned about supply chain risk. Gartner's own forecast is blunt about where this leads: it expects 40% of organizations worldwide to experience a security breach tied to shadow AI by 2030.

The policy side lags in a similar way. In the same OutSystems survey, 82% of executives said they believed their existing policies already covered unauthorized use of AI agents — while their own data showed 81% of organizations had agents in active production or testing, and only 14.4% of those had gone through full security approval. The policy people believe they have and the policy actually being enforced are, for most companies right now, two different things.

What actually needs governing now

For a partnerships team, governing this well means treating a vendor and an agent as the same kind of object moving through the same kind of process — even though they don't look alike on the surface. Both get proposed by someone, both need a security and policy review before they touch anything real, both carry ongoing risk that doesn't stop the day they're approved, and both need someone accountable for them after the fact.

In practice that means three things a spreadsheet or an intake form in a shared drive can't do well. First, a single structured record for every vendor and every agent, so "what has access to what" is a lookup, not an investigation. Second, a lifecycle that doesn't end at approval — tracking whether a vendor's certifications are still current, or whether an agent approved for one narrow task has quietly been given broader access since. Third, proactive surfacing of exactly the gaps the numbers above point to: an approval still pending after a tool is already in use, a review that hasn't happened since onboarding, a policy that assumes coverage it doesn't actually have.

None of this is really about paperwork. It's about being able to answer, at any moment, exactly what vendors and agents the company relies on, what each one can touch, and whether that's still something the company actually agreed to.

Best practices for governing vendors and agents

These hold whether the thing being governed is a vendor contract or an AI agent someone spun up last week — the discipline doesn't change, only the object does.

• Give every vendor and every agent the same front door. If an agent piloted by one team can go live without passing through the same intake as a vendor contract, it will — quietly, and usually without anyone deciding that was acceptable. One path, no side doors, is the only version of this that holds up.

• Treat security review as a gate, not a formality. A review that happens after something is already in use isn't a review, it's documentation. Security needs the actual ability to block or delay a vendor or agent going live — not just log a concern after the fact.

• Make compliance monitoring continuous, not point-in-time. A vendor or agent that passed review a year ago isn't guaranteed to still meet the same bar today — certifications lapse, ownership changes, an agent's permissions get expanded. Recheck on a schedule instead of assuming an initial approval holds forever.

• Write the policy down, then check it against what's actually happening. A stated policy nobody has tested against real usage tends to be more aspirational than actual — the gap between what leadership believes is covered and what's really in production is exactly where the risk sits.

• Keep an audit trail nobody has to reconstruct by hand. When an auditor, a regulator, or a customer asks who approved a vendor or an agent, when, and under what conditions, the answer should be a record, not somebody's memory of a Slack thread from eight months ago.

What to look for in the system itself

The best practices above are achievable by discipline alone, in theory. In practice, they hold up far better with a system built to enforce them automatically. Six capabilities matter most:

• A single intake for vendors and agents alike — one record type, one process, whether what's being proposed is a new supplier or a new AI tool.

• Review tracks that route to the right people automatically — infosec, legal, and the business owner each see what's relevant to them, without someone having to manually loop them in.

• Checklist-driven approval, not a single sign-off — the specific requirements for a stage (a security questionnaire completed, a DPA signed, a certification current) have to be met before the record can move, not just acknowledged.

• Continuous compliance tracking — certifications and review dates that surface again when they're due, not just at onboarding.

• A visible audit trail — every approval, exception, and policy override logged against the vendor or agent it applies to.

• Reporting built for the questions that actually get asked — what's out of compliance right now, what's pending approval, what agents are in production without full sign-off.

This is close to the shape Granur is built around: every vendor and every agent moves through the same stage-based pipeline, with infosec, legal, and business review tracks attached directly to the record, and a checklist gating each move instead of a single approval. It's less about adding a new tool to the stack and more about giving partnerships teams one governed path for everything that used to come in through five different doors.

Why this lands on partnerships teams specifically

Partnerships teams are usually the first to know about a new vendor relationship or a new agent pilot, often before infosec, legal, or even IT are aware it exists — a conversation with a potential partner, a demo of a new tool, a pilot someone on the team wants to try. That makes partnerships the natural first checkpoint, whether or not the team was ever set up to be one.

That position comes with real leverage, if it's used. A partnerships team that routes every new relationship through the same governed intake — instead of letting some vendors in through a formal process and others in through a Slack message and a credit card — sets the standard the rest of the company follows. It's also the team best positioned to notice when a "vendor" is really an AI agent wearing a vendor's clothing, or the other way around, since they're the ones fielding the pitch either way.

And when something does go wrong — a vendor's security posture turns out weaker than represented, an agent gets more access than anyone intended — partnerships is typically the team that has to explain how the relationship started and who signed off on it. Being able to answer that with a record instead of a reconstruction is the difference between an uncomfortable meeting and a genuinely bad one.

Choosing a system that will actually get used

The system that looks best in a demo isn't always the one that survives contact with a real organization, real vendors, and a growing list of agents six months in. A few things are worth weighing before committing to one:

• Integration with identity and access systems. As agents start acting with real permissions, a governance system that can't connect to single sign-on or an identity provider can only ask what something has access to — it can't confirm it.

• Whether infosec and legal will actually use it, not just the business team. The teams doing the real review work need a workflow that fits how they already operate, or the record they're supposed to keep current quietly falls out of date.

• Audit-ready reporting. The report an auditor or a customer's security team will actually ask for — what's approved, what's pending, what's overdue for review — should already exist, not require an afternoon of assembly.

• Room for a growing and changing list. A system sized for 50 vendors and no agents can struggle at 500 vendors plus a few dozen agents that each need a different kind of review than a standard contract.

• The provider's own security posture. A governance system holds the most sensitive record a company keeps about its external relationships — it deserves at least the same scrutiny it's about to apply to everyone else.

The shift worth making

None of this requires solving the whole problem on day one. Most teams get here the same way: an agent that turned out to have more access than anyone intended, an audit that took longer than it should have, a vendor conversation that started as a demo and ended up live in production with no formal record. Each of those is a sign that the old process — proposal, informal review, done — has outgrown what it's actually being asked to govern.

The shift is from reactive to proactive, and from vendors-only to vendors-and-agents: from finding out what's already in production to knowing what's being proposed before it goes anywhere. That's the problem Granur was built to solve — one governed pipeline for everything a partnerships team brings into the business, with security and policy built into the process instead of bolted on after something's already live.

If any of this sounds familiar — an agent nobody remembers approving, a vendor review that hasn't happened since onboarding, a policy that assumes more coverage than it actually has — it's worth a closer look at how vendors and agents are actually entering the business today, and where a single governed record would have caught it sooner.