AI Agent Governance Starts at Onboarding, Not Runtime

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. When Ged Ossman, founder and CEO of Interf, joined episode 99 of our podcast, he 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

Picture how a vendor agent usually enters a company 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 — 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: declare before deploy

Ossman’s proposed fix is what he calls an agent onboarding protocol. 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. 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 mobile app manifests, 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.

The benefit is that the risk conversation moves earlier, where it is cheaper to have. A declared, machine-readable request can be reviewed 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. For the runtime side of that pairing, see why agents need least privilege more than humans ever did.

Vendor agents vs. enterprise agents

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; you do not, until onboarding. This is where hidden requirements bite.

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

The onboarding protocol is really a handshake between the two. The vendor agent declares its requirements; your 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. 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:

• 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’ll 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 a risk to assess, not a feature to enable. 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 stop saying no. Governance at onboarding is what lets the answer be yes.

Open standards, and where this is heading

Ossman is building the onboarding protocol as open source, with a public registry of vendor dependencies, and points to Anthropic’s Model Context Protocol as the model to follow: published through an independent effort, then moved toward a neutral body 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 assess at scale. Until then, the principle stands on its own: make agents declare what they need before they run, and govern the declaration.

Ossman’s framing is a useful gut check. Trust, he said, 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.