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, and it is late. When Ged Ossman, founder and CEO of Interf, joined episode 99 of our podcast, he argued that governance actually breaks earlier: agents get deployed blindly, and the controls show up only after they already have the keys. His fix is older than AI. Make the agent declare what it needs, in a form a machine can read, before anyone lets it run. Then point the monitoring at the declaration.

Why runtime monitoring alone can’t govern AI agents

Picture how a vendor agent 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, which is exactly the wrong order.

Ged’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. He has the background for it: experimental operating systems at Microsoft Research, then six years building key-sharding custody at Copper for institutions that could not let one new hire move the fund.

“In order to create this environment where we will not have these problems in runtime, what if we let developers bring a standard for them to specify, in a deterministic way, what data, what interactions they expect to do with other applications. So the protocol, but also a data contract, or in Android, like certificates, where you define as an app developer all external dependencies that you may request in advance and you get permission to. And then when your application actually runs in runtime, it’s already pre-authorized to execute this, to get access to this shared context, to get access to these permissions.”

Ged Ossman, founder and CEO of Interf, on episode 99

The same reactive pattern shows up with the unmanaged AI tools employees adopt on their own, which we covered in Shadow AI: the risks, and how to govern it without blocking AI. Agents raise the stakes, 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.

There is a second cost, and it lands on buyer and vendor at once. Ged’s estimate on the show is that more than 60% of AI implementations never deliver meaningful ROI, and when one stalls, “enterprises will never say it failed because we were not ready. They would just say, vendors, they over-promised us.” Both sides end up doing governance work after the contract is signed.

What is an agent onboarding protocol? Declare before you deploy

Ged’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, and every action it takes can be checked against the list. In his words: “If vendor agents need something from the enterprise, it should be specified in a machine-readable form, in a way where compliance, security teams can quickly assess the risk, can quickly understand their current state of systems.”

The part vendors will enjoy least is the humility it demands of the pitch:

“Everyone thinks AI is a magic box. This agent, it magically does many things, it can do whatever, and everyone kind of believes in it. But I think it should be: this agent can perform certain capabilities. To do that, it needs A, B, C from the enterprise. And it’s the enterprise’s part to figure out how to get this in a compliant way, not for vendors to try to overpromise things and just say, of course it’s compliant.”

Ged Ossman, Interf, episode 99

He is upfront that the idea is borrowed, and every source he borrows from is one engineers already trust:

• Mobile app permissions. An Android app has to list every permission it might request in its manifest before it ships. Google’s documentation says why: “These declarations help app stores and users understand the set of permissions that your app might request” (Android Developers, Declare app permissions). Android also splits permissions into install-time grants and runtime prompts for the sensitive ones, a useful template for agents: pre-authorize the low-risk reads, and put a human prompt in front of the actions that, in Android’s words, “more substantially affect the system.”
• 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.
• A bill of materials. CISA describes an SBOM as “a nested inventory, a list of ingredients that make up software components” (CISA, Software Bill of Materials). An agent declaration is the same instinct pointed the other way: what the agent will consume rather than what it is made of, in the spirit of the AI data bill of materials the Bedrock Data team described on episode 95. On the show Jon called it a bill of materials for your runtime, which is still the fastest way to explain it to a board.

The benefit is that the risk conversation moves earlier, where it is cheaper to have. It also pairs naturally with 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.

What should an agent permission manifest contain?

Ged’s protocol was still being written when we recorded, so here is what the declaration needs to hold. We call it an agent permission manifest, the agent’s equivalent of the uses-permission block.

1. Identity. Who the agent is: vendor, version, and the service account or workload identity it runs under. Never a borrowed human credential. One agent, one identity, so the logs mean something later.
2. Owner. The human accountable inside your company, plus the vendor contact. When the agent does something odd at 2 a.m., this is the name that gets paged.
3. Data. Every data source it reads, with your classification attached. Enumerate the sources and you can see what protection the agent needs before anything is connected.
4. Systems. Every API, database, SaaS application and MCP server it connects to. If the agent speaks MCP, list the servers and the tools on each; a secure MCP review is where we check that list against what the servers actually expose.
5. Actions. Read, write, execute or approve, per system. Writes get their own line, because write access is the rung most agents should not start on, and a manifest that says “read-only” is a promise your monitoring can hold the agent to.
6. Context prerequisites. The answers the agent needs from you to do the job at all. This is the section today’s paperwork misses. Questionnaires are “stage one,” Ged says, “but there are still a lot of requirements that are hidden, specifically around context dependencies,” which surface only “when the vendor’s forward-deployed engineers tell it, during the onboarding process.”
7. The default. Anything not declared is not available. This is the line that turns a document into a control, the same rule Android applies to an app that forgot to declare the camera.

That last line also answers the question we raised in Authorization is the last layer companies still build from scratch: who decides what an agent can see and do, and where is that decision written down? The manifest is the input; the authorization layer is where it gets enforced.

Vendor agents vs. enterprise agents: the handshake

Ged splits the world into two kinds of agents, and the distinction matters.

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, and the manifest doubles as the design review your security team runs before the first deploy.

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. A questionnaire asks the vendor about the vendor. The manifest asks the agent about the agent, and it asks in a format your tooling can read.

His ask of vendors is a change of posture:

“I understand vendors trying to build solutions, get attention, so they always oversell. Look what’s possible today with AI. But I would prefer we always think in a different way … To make this possible, this is the risk that our solution introduces. So please, share it with the industry, make this risk visible for everyone who plans to adopt this vendor solution. Let security teams, compliance teams figure out internally how they prefer to address this risk.”

Ged Ossman, Interf, episode 99

For the startups reading this who are the vendor, that posture is a sales asset. Show up with a manifest and you walk into the enterprise security review with the answers already written. We have watched a SOC 2 report do exactly this for the first hundred questionnaire answers; the manifest does it for the question that comes next, the one about your agent.

How to govern an AI agent before you deploy it

You do not need a finished protocol to apply the principle; push the governance decision to before deployment:

1. Require a declaration. Before an agent gets access, make the vendor (or your own team) state, in writing and ideally in a machine-readable file, every data source, permission, and external dependency it needs. No open-ended “we’ll figure it out during onboarding.”
2. Map it against your systems. Check the declared dependencies against what you actually have and are willing to expose. This is the pre-flight check, where you find the data that is not there yet while it is still cheap to fix, and it belongs before the money moves. We wrote the buyer-side checklist in AI Readiness Assessment: the pre-flight check before you deploy an agent.
3. Approve the risk, on the record. Someone with the authority to accept risk reads the manifest and signs. Ged’s framing is that any new solution introduces a risk to the organization, and the hard part is agreeing internally on how to address it. A named approver is how that agreement gets recorded.
4. Provision the minimum. Grant only what the declaration justifies, under the agent’s own identity. Anything not declared is not available by default. OWASP’s AI Agent Security Cheat Sheet says it in two sentences: “Grant agents the minimum tools required for their specific task. Implement per-tool permission scoping (read-only vs. write, specific resources).”
5. Log every interaction. Keep the audit trail so runtime monitoring has something to check the declaration against.

Build a sandbox too, and your engineers will thank you for it. Ged wants “engineering sandbox environments that make experimentation friendly,” because the alternative is what keeps landing in his inbox: “you install something in your CLI, give it root access, and then you get hacked the next day and you didn’t think about it.” A sandbox is a manifest with generous defaults and no production data behind it.

This is 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.

How runtime monitoring checks an agent against its declaration

Runtime governance is the second half of this, and a declaration changes what the monitoring is for.

Without a declaration, runtime tooling has to infer normal from behavior: baseline the agent’s calls, flag the statistical outliers, hope the first week was representative. With a declaration, normal is written down. Every tool call, read and write either appears in the manifest or it does not, and the ones that do not are the alert. OWASP’s cheat sheet puts logging first (“Log all agent decisions, tool calls, and outcomes”) and anomaly detection second; the manifest is what makes the second step a comparison instead of a guess.

Four drifts to watch for:

• Scope drift. The agent touches a system, table or tool that is not declared. Deny by default, page the owner, ask the vendor why.
• Action drift. A declared read becomes an attempted write. The OWASP Top 10 for Agentic Applications, released in December 2025 with input from more than 100 researchers, practitioners and organizations, names “Tool Misuse and Exploitation” and “Identity and Privilege Abuse” among the top agentic threats; both are what action drift looks like from the attacker’s side.
• Version drift. The vendor ships a new agent version with new dependencies. New version, new manifest, new approval, the way an app update that wants new permissions has to ask you again.
• Owner drift. The accountable human changes roles or leaves. Reassign before the next renewal, or the manifest becomes a document nobody is responsible for.

Then run the check in reverse: usage against grant. If the agent was granted twelve systems and has used four in ninety days, the other eight come off. That is the usage-based trimming Graham Neray argued for on episode 89, and it only becomes possible once you have a list to trim against.

For a framework to hang this on, NIST’s AI Risk Management Framework, voluntary and released in January 2023, organizes the work into four functions: Govern, Map, Measure, Manage. Onboarding is where you Govern and Map; runtime is where you Measure and Manage. The manifest connects them, and it is the record an ISO 42001 auditor asks for when they want to see how each AI system’s permissions were decided. Our monitoring and response team’s favorite customers hand us that list on day one.

Open standards for agent onboarding: the registry and the Linux Foundation plan

Ged is building the onboarding protocol as open source, starting with visibility rather than enforcement: “What I’m working on now is just making vendors’ requirements more visible to everyone. So we’re building this open registry of vendors’ dependencies.” The registry publishes what each vendor agent needs, in machine-readable form, before an implementation starts, so enterprises can assess the risk “in a more organized way, not hoping that forward-deployed engineers will come and help figure it out.”

For the governance model, he points at the Model Context Protocol:

“Model Context Protocol, Anthropic, now it’s the most popular. I noticed the trend that it’s published not by Anthropic from their repository, but it’s actually an independent organization that’s being donated to the Linux Foundation today. And I believe this is the standard I’m taking as reference. So if I’m releasing the protocol or industry solution, I already have in mind that it’s not a proprietary protocol that we will just figure out how to commercialize. I think about, okay, when can we donate it to the Linux Foundation, and our job is to make the adoption the fastest way possible.”

Ged Ossman, Interf, episode 99

On December 9, 2025 the Linux Foundation announced the Agentic AI Foundation, anchored by MCP from Anthropic, goose from Block and AGENTS.md from OpenAI, as “a neutral, open foundation to ensure this critical capability evolves transparently, collaboratively” (Linux Foundation press release). An onboarding protocol needs the same path, because procurement will only require a manifest in an RFP if the format does not belong to any single vendor.

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, and something procurement can ask for the way they ask for a SOC 2 today. Until then, the principle stands on its own: make agents declare what they need before they run, and govern the declaration.

Ged’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. A published manifest is the numerator.

The decision: make every agent declare what it needs

If you buy agents, add one line to your vendor intake form: send the manifest. Data, systems, actions, identity, owner, in a file. Pre-authorize exactly that, under the agent’s own identity, and point your monitoring at the file. If you sell agents, publish yours before the buyer asks, and watch the security review get shorter.

Either way, the first step is knowing what your agents (and your people) can already reach today, because most companies are surprised by the answer. An AI access control audit gives you that list in a few weeks, and it becomes the baseline every new manifest is checked against. If you would rather hear it from the person building the protocol, Ged and Jon go through it in under 50 minutes on episode 99.