The Questions Never Change

AI agent governance becomes complicated when the conversation begins with technology: models, prompts, grounding, orchestration, autonomy, connectors, copilots, tools, and increasingly sophisticated ways for software to act on our behalf. But the technology is new; the governance questions are not. 

All of that matters, but there's another way to look at the problem. Strip away the AI terminology for a moment and ask the questions enterprise IT has always asked when a new asset class enters the environment. 

• What do I have? 

• Who is accountable for it? 

• What can it reach? 

• What is it actually doing? 

• How does it go away? 

Those questions haven’t changed; only the subject has. Together, they form a six-question governance framework for agents: inventory, accountability, access, observation, protection, and retirement. 

What do I have? 

Every governance program starts with visibility. You can't govern what you can't see. 

• For people, organizations built directories and identity inventories. 

• For devices, they built management and inventory systems. 

• For applications, they built application catalogs and registration processes. 

• For data, they built classification, discovery and information governance capabilities. 

Now we're facing the same fundamental question with agents: What agents exist in my environment? Not just the ones IT knows about, and not just the ones that went through a formal project. The actual population. 

• What was built? 

• Who built it? 

• What is it called? 

• Where does it run? 

• What is it connected to? 

This is why I think agent inventory is the first control, not an administrative exercise. Before an agent can be secured, owned, scoped, observed, or retired, the organization must know it exists. Inventory is what makes every later governance control possible. 

Who is accountable for it? 

Inventory tells you what exists, it doesn't tell you who is responsible. That's the second question we've asked across every enterprise asset class: Who owns this? 

• With a person, accountability may sit with a manager. 

• With a device, there may be a primary user or assigned administrator. 

• With an application, there's typically a business or technical owner. 

• With data, ownership may sit with a business function or information owner. 

Agents need the same clarity. Accountability should not rest only with the technical creator or the person who happened to build the workflow. Every agent needs a named sponsor and a named owner. 

That's an important distinction. The person who builds an agent today may not be the person responsible for its business outcome six months from now. If nobody owns the agent, nobody is accountable for deciding whether it should continue to exist. And that becomes particularly important when the agent is no longer experimental. It has become part of your infrastructure. 

What can it reach? 

This is where agent governance starts to intersect directly with security. Every asset has a scope. 

• A user has permissions. 

• A device has policies. 

• An application has delegated access. 

• Data has access controls. 

So, the question for an agent is straightforward: What can this thing reach? 

• Which applications? 

• Which sites? 

• Which files? 

• Which mail? 

• Which systems? 

• Which identities? 

And perhaps most importantly: Does it need all of that access? 

This is where least privilege becomes more than a security principle. It becomes an agent design principle. The goal isn't to make an agent powerful enough to do everything. It's to make it capable of doing what it is supposed to do—and no more. 

That probably sounds familiar, because it is. We've been solving this problem for identities and applications for years. The subject has changed, the question hasn't. 

What is it actually doing? 

Inventory tells us what exists; ownership tells us who is accountable, and access controls tell us what an agent can do. But there's another question every operations and security team eventually asks: What is it actually doing? 

This is where observation matters. A static permission assignment only tells you what an agent could reach. It doesn't necessarily tell you what it does with that access. So agent governance needs visibility into usage and activity. 

• Which agents are active? 

• What are they connected to? 

• How are those connections being used? 

• Are their behaviors consistent with their intended purpose? 

• Are there security signals that require investigation? 

This is the move from simple inventory toward an agent map and usage insights. Inventory identifies which agents exist. An agent map reveals their relationships and dependencies. Usage insights show how those connections are actually being used. 

That's an important shift because an inventory answers: What do we have? An agent map starts answering: What is this connected to? And telemetry begins answering: What is it doing? 

Those are different questions, and you need all three. 

How does it go away? 

This may be the least glamorous question in technology, but it may also be one of the most important. How does it go away? 

• We've built employee offboarding. 

• We've built device retirement. 

• We've built application decommissioning. 

• We've built data retention and disposal processes. 

Agents need an exit strategy too. 

• What happens when the business process changes? 

• What happens when the owner leaves? 

• What happens when the underlying data changes? 

• What happens when an agent is replaced? 

• What happens when nobody uses it anymore? 

An agent shouldn't remain in the environment simply because nobody remembered to retire it. A lifecycle isn't complete until it has a defined ending. Creation without retirement becomes accumulation, and accumulation becomes governance sprawl. 

The first five questions establish whether an agent is known, owned, appropriately scoped, observable, and removable. A sixth question connects those controls to the security and data governance foundations beneath the agent: How do I keep it from hurting me? 

This sixth question is addressed through two complementary disciplines. Threat detection identifies harmful or anomalous agent activity. Data protection safeguards the information agents read, generate, and send. Together, they extend governance beyond the agent itself to the underlying control plane and operating environment. 

An agent may be perfectly identified, it may have an owner, its permissions may be scoped, its activity may be observable, and it may even have a retirement process. But if the information it can access is poorly governed, the organization still has a problem. 

Which brings us back to something from the first article: The agent lifecycle depends on the lifecycles underneath it, same questions and the same control plane. 

This is why I don't think organizations need to invent an entirely new philosophy for agent governance. They need to extend the one they've already developed. The vocabulary might look different: Agent registry. Agent identity. Least privilege. Agent map. Usage insights. Lifecycle workflows. 

But the underlying disciplines are familiar. 

 
That's the fifth lifecycle. Agents aren't identical to users, devices, applications, or data; they introduce new characteristics and operational considerations. But they belong in the same enterprise governance conversation: they must be known, owned, controlled, observed, protected, and eventually retired. The mistake is treating every agent as an exception. 

There's a temptation with new technology to create an entirely separate governance universe. 

• A new committee. 

• A new policy. 

• A new vocabulary. 

• A new process. 

• A new dashboard. 

Maybe some of that will ultimately be necessary, but I'd start somewhere simpler. Take the questions your organization already knows how to ask and apply them to agents, then identify where the existing controls are not sufficient. 

That changes the conversation. Instead of asking, “How do we govern this completely new thing?” organizations can ask, “Which parts of our existing governance model already work, and where do agents require something different?” 

That's a much more useful starting point because the objective isn't to make agents fit yesterday's technology; it's to make sure tomorrow's technology doesn't escape the disciplines we've already learned. The questions never change. 

• What do I have? 

• Who is accountable for it? 

• What can it reach? 

• What is it actually doing? 

• How do I protect it? 

• How does it go away? 

We've asked these questions of every major enterprise asset class. Agents may be the fifth, but the most important lesson comes from the first four: Governance doesn't begin when something goes wrong. It begins when you can answer the questions. 

Inventory it. Identify it. Own it. Scope it. Watch it. Retire it. 

The subject is new; the questions aren't. 

This is the second article in a series exploring the "fifth lifecycle" of enterprise IT: the governance of AI agents alongside identity, devices, applications and data.