This article is based on an interview with Matthew Wimberly, CTO and co-founder at Chiri.
A simple test for AI governance
Ask a company to describe its AI governance program. Most point to a slide deck, a values statement, or a vendor’s compliance page. Few can answer specific operational questions. What data can an agent reach today? What did agent usage cost last month? What happened the last time an agent failed, and what changed afterward?
Matthew Wimberly, Chief Technology Officer and co-founder of Chiri, argues that most governance claims fail this simple test. A policy document is not the same thing as a checked, current practice. He describes the pressure on technical leaders in plain terms. “Sometimes you think of it as literally the loneliest job in the world,” he says. Decisions get made without a clear precedent to follow. The consequences do not show up for months, and by then the decision is already locked in across the company.
The pressure is not paperwork. Wimberly points to real, unresolved gaps across the industry. Rules on prompt storage remain unclear at most vendors. Rules on whether a vendor trains its models on customer data remain unclear too. On top of that, new authentication vulnerabilities keep surfacing in the tools companies use to connect agents to their systems.
Rather than describe governance in the abstract, Wimberly lists five specific practices a company can check for today. None of them are future goals or roadmap items. Each one is a habit a team either has in place right now, or does not. None of them require a new department, a new title, or a new vendor contract. Each one is a decision a company has already had the chance to make.
Practice one: a live data schema
The first item on Wimberly’s list is a current, complete map of a company’s data. “I have a data schema of all of the data in our company, and it updates automatically, and it’s placed on my desk whenever it’s updated,” he says.
Matthew Wimberly
Wimberly frames this as the exception, not the norm, across the companies he has worked with. “I’ve never worked at a company that I’ve led data platforms for that had something like that,” he says. He adds that building it was a genuine milestone for his own team, not a routine box to check.
A static schema, built once and left to go stale, cannot support agent decisions made against live systems. An agent that reads from an outdated schema can act on structures that no longer exist. It can also miss new structures that do exist but were never added to the map. Both failure modes are silent. Neither shows up until an agent has already acted on bad information.
Practice two: data classification standards for agent access
The second practice is a classification standard that defines what category of data an agent can reach. Wimberly is direct that this is not a new discipline invented for AI. “This isn’t even an AI-enabled feature,” he says. “This is just good old-fashioned security work for the company, on behalf of the company.”
The distinction matters for how a company should staff and fund this work. Classification is not a task for a prompt engineer or an AI vendor. It belongs to the same security function that has always classified data for human access. A company that has never done this basic work has no foundation for agent governance. Nobody has decided what counts as sensitive, so nobody can decide what an agent should see. Classification comes first. Every access rule that follows depends on it.
Practice three: treat agent access like employee access
The third practice extends an existing discipline to a new kind of actor inside the company. Wimberly applies the same access standard to an agent that he applies to a person. “I treat an agent the same way as I treat an employee,” he says. “I make sure that agent can’t access things it shouldn’t on behalf of an employee.”
This standard closes a common gap in how companies roll out agents. Many grant a new agent broad access up front to move fast. Few come back later to narrow that access once the agent reaches production. Under Wimberly’s standard, an agent’s access ceiling matches the access ceiling of the person it works on behalf of. It never exceeds that ceiling by default. Any expansion needs the same review a new employee’s access request would get.
Practice four: cost quotas and controls
The fourth practice is financial, not technical. Wimberly ties agent rollout directly to budget discipline, not just security discipline. “Of course, we have cost controls, cost quotas across the company,” he says. “Sure, we’re rolling out AI, everyone has AI, but I want to know that it’s being used appropriately, and that we’re not going to surprise our CFO.”
Wide agent adoption without a spending ceiling produces exactly the surprise Wimberly describes. Usage scales quietly, one added workflow at a time, until a bill arrives that nobody planned for. A quota turns an open-ended cost into a bounded, reviewable one. That forces a useful question at the team level: is this specific use of an agent worth what it costs.
Practice five: post-mortems on agent failures and prompting
The fifth practice is a regular review of what went wrong and why. “We really ensure, and really drill down on, review post-mortem on agent failures and prompting techniques,” Wimberly says.
He splits the purpose of these reviews into two distinct parts. One part is efficiency. Teams learn to prompt in ways that use fewer tokens and cost less per task. The other part is a harder question about placement. “You really need to start honing in on where does the agent fit,” Wimberly says.
Many companies try to fit an agent into the exact shape of a person’s current job, task for task. Wimberly argues that this narrow substitution is not the real goal of adopting agents. A post-mortem that only asks “did the agent do the task correctly” misses the larger question. The larger question is whether that task was ever the right shape for an agent at all.
The MCP warning: an open garage door
Wimberly names one exposure he sees as underappreciated across the industry. It is the Model Context Protocol, or MCP: the connection layer many companies use to link agents to internal tools and data.
“MCP is like an open garage door in your house, and you’re just leaving all your nice cars out there,” he says. The analogy holds because of how broadly MCP access gets granted inside an organization. “You’re gonna give MCP to every single person in your organization, and the authentication gateway has zero days,” Wimberly says. “You’re just giving them a backdoor into your company.”
The warning is specific, not general. MCP adoption is often driven by convenience: one connection point that lets an agent reach many systems at once. That same convenience is what makes a single authentication flaw so costly. A gap in one gateway can expose every connected system at once. Anyone who already has access to that gateway can reach through it. Wimberly’s point is not that MCP should be avoided. Companies are rolling it out at the speed of a productivity tool. They are not yet treating it with the security scrutiny of one.
What AI native actually means
Wimberly draws a sharp line between adding AI to existing work and rebuilding work around agents. Fitting an agent into a person’s exact current job is the shallow version of this shift. “That’s not what AI native really is,” he says.
“AI native is really starting to question the premise, or the reason that we’re doing the work that we’re doing, and look to transform that into a way that maybe is mostly controlled by agents, or maybe there’s a handoff that happens,” Wimberly says. The starting question is not how an agent should do a given job. The real starting question is whether that job should exist in its current form at all.
Wimberly ties this back to a documentation gap most companies have not closed. “I would be shocked if I was talking to a client and they said, we have a workflow library where we have all of our SOPs stored in a central place,” he says. Without that library, a company cannot show which parts of a process should stay human. It cannot show which parts should move to an agent, or which need a handoff between the two.
Wimberly describes this as a full lifecycle, not a single build step. It runs from a recorded process or a written SOP, through the agent build, into live running, and on through cost tracking. Each new version of that agent changes the underlying SOP in turn. The documentation has to move with the agent, version by version. Otherwise the company loses track of what it actually automated and why.
This lands differently depending on where you sit
For a CTO or CISO: the five-item list is a real audit, not a policy exercise. A company that cannot produce a current data schema, a classification standard, an access parity rule, a cost quota, and a post-mortem cadence does not have AI governance yet. That is true no matter what its written policy claims.
For an operations leader: the MCP warning applies directly to any tool rollout that connects an agent to multiple internal systems through one gateway. A single point of connection is also a single point of failure. It deserves the same scrutiny as any new login system a company would deploy company-wide.
For an executive or board member: the cost quota point carries the most direct budget exposure. Wide, ungoverned agent adoption produces the kind of finance surprise Wimberly describes. A quota is the simplest available fix, and it is the one most likely to be missing today.
For a team evaluating its own workflows: the closing point is the hardest one to act on, and the most valuable. Adding an agent to a process built for a person is a smaller move than it looks like. Asking whether that process should exist in its current form at all is the harder, more useful question.
Which of these five practices could a company demonstrate today, not just describe?