AI Agent Governance Starts at Onboarding: How to Control Vendor Agents Before They Deploy

What Is AI Agent Governance?

AI agent governance is how an organization decides what an AI agent can access, what it can do, and who signed off on it. It covers the permissions an agent holds, the data it touches, and the record of every action it takes. Done well, it lets you answer three questions at any moment: what is this agent allowed to do, why was it allowed, and what has it actually done?

Most governance tools answer those questions at runtime. They watch agents that are already deployed and already have access. That is necessary, but it is late. The harder and more neglected question is what happens before the agent runs at all. On the podcast, Ged Ossman, founder and CEO of Interf, argued that this is where governance actually breaks: agents get deployed blindly, and the controls show up only after they already have the keys.

Why Runtime Governance Alone Fails: The Onboarding Gap

Picture how a vendor agent usually enters an enterprise today. A team buys a tool, someone clicks approve, and the agent starts asking for access to systems and data so it can do its job. The requests come in during the work, not before it. Security and compliance end up reacting to access that has already been wired up, which is exactly the wrong order.

Ossman's point is that this is not a new problem. Software engineering solved a version of it decades ago. Operating systems did not let one process reach into another's memory on a whim; they made programs declare, in advance, what they needed. That declaration is the control. Without it, you are governing after the fact.

The same reactive pattern shows up with unmanaged AI tools employees adopt on their own, the problem we cover in shadow AI and how to govern it. Agents make it worse, because an agent does not just read data, it acts on it. If your only governance is runtime monitoring, you are watching a decision that was already made when you granted access.

The Agent Onboarding Protocol: Data Contracts and Pre-Authorization

Ossman's proposed fix is what he calls an agent onboarding protocol. The idea is straightforward: before an agent runs, it declares in machine-readable form exactly what data and interactions it needs. Security and compliance read that declaration, assess the risk, and pre-authorize only what is required. Then, at runtime, the agent is already scoped to what it was granted.

He draws the analogy to concepts developers already know:

• Data contracts: an explicit, structured statement of what data an agent expects and how it will use it, rather than open-ended requests made live.

• Pre-authorized permissions: like Android app certificates, where an app declares its external dependencies up front and is granted them before it executes, not while it runs.

• A bill of materials: a full list of what an agent needs, in the same spirit as a software or AI data bill of materials. Ossman used this exact comparison on the show.

The benefit is that the risk conversation moves earlier, where it is cheaper to have. A declared, machine-readable request can be reviewed by a compliance team in a structured way instead of reverse-engineered from logs after the agent is live.

This is the natural complement to runtime least privilege. Onboarding decides the ceiling on what an agent may ever be granted; least privilege keeps it at the floor of what it needs right now. If you want the runtime side of that pairing, see why agents need least privilege.

Vendor Agents vs Enterprise Agents: Who Declares What

Ossman splits the world into two kinds of agents, and the distinction matters for governance.

• Vendor agents come from a third party. They arrive wanting access to your data and systems. The vendor knows what the agent needs; the enterprise does not, until onboarding. This is where hidden requirements bite.

• Enterprise agents are built or run inside the organization. You control their code and their scope, so the declaration can be enforced internally.

The onboarding protocol is really a handshake between these two. The vendor agent declares its requirements; the enterprise agent, or the enterprise's controls, decide what to grant. Today that handshake is a mess of security questionnaires, sales calls, and forward-deployed engineers filing tickets once the contract is signed. Ossman's argument is that the requirements that surface painfully during onboarding, especially context and data dependencies, should be declared before anyone signs anything.

How to Govern an Agent Before You Deploy It

You do not need a finished protocol to apply the principle. The move is to push the governance decision to before deployment. A practical sequence:

• Require a declaration. Before an agent gets access, make the vendor state, in writing, every data source, permission, and external dependency it needs. No open-ended "we will figure it out during onboarding."

• Map it against your systems. Check the declared dependencies against what you actually have and are willing to expose. This is where you catch the data-quality and access gaps that otherwise derail the project mid-flight.

• Pre-authorize the minimum. Grant only what the declaration justifies. Anything not declared is not available by default.

• Log every interaction. Keep the audit trail so runtime monitoring has something to check the declaration against.

• Treat each new agent as risk to assess, not a feature to enable. The framing matters. A feature gets switched on; a risk gets reviewed.

This is also how you say yes to AI without losing control, the same balance we cover in why security leaders should enable AI instead of blocking it. Governance at onboarding is what lets the answer be yes.

Open Standards and Where This Is Heading

Ossman is not trying to own this as a proprietary product. He described building the onboarding protocol as open source, with a public registry of vendor dependencies, and pointed to Anthropic's Model Context Protocol as the model to follow. His read is that the protocol gained traction partly because it was published through an independent effort and moved toward donation to a neutral body like the Linux Foundation, rather than staying under one vendor's control.

That direction is worth watching for anyone responsible for agent governance. A shared, open way for agents to declare their data and permission needs would turn today's ad hoc onboarding into something security teams can actually assess at scale. Until then, the principle still applies: make agents declare what they need before they run, and govern the declaration.

Ossman's framing is a useful gut check. He said trust equals transparency divided by self-interest. An agent that hides what it needs until it is already inside your systems is failing the numerator. Governance at onboarding is how you demand the transparency up front.

Listen to the Full Episode

On this episode of the Security Podcast of Silicon Valley, host Jon McLachlan (co-founder of YSecurity and Cyberbase.ai) talks with Ged Ossman, founder and CEO of Interf, about why onboarding AI agents is a security problem, not a feature.

Ossman draws on his background as an early team member at Copper Technologies and years working alongside enterprise operations to explain why the missing layer in AI adoption is a structured, machine-readable way for agents to declare what they need before they run.

It is a practical conversation about moving governance to the front of the deployment, where it is still cheap to say no.