Technology

Before Anyone Can Own an AI Agent, You Have to Be Able to See It

Before Anyone Can Own an AI Agent, You Have to Be Able to See It

By Tim Burke, President & CEO, Quest Technology Management

AI agents are showing up in mid-market companies faster than those companies have built the visibility and controls to manage them. That is the whole problem in one sentence. Everything else in this article follows from it.

I talk with a lot of mid-market leaders. Manufacturers, regional healthcare groups, and financial services firms with a few hundred employees. Increasingly, they have AI agents running somewhere in the business. A sales team turned on an assistant that reads the CRM and drafts follow-ups. Finance is testing a tool that reconciles invoices. A vendor pushed an update that quietly added agent features to software the company already owned. Each decision made sense on its own. Nobody stepped back to ask how many agents were now operating in the environment or what they could reach.

The governance frameworks are pointing in the right direction. NIST, ISO, and most major guidance documents say roughly the same thing: every AI agent needs an accountable owner. I agree. But you cannot assign ownership of something you have not identified. Before ownership means anything, you need to know four things about every agent in your environment. What exists. What it can access. What it is authorized to do. And how will you know when it does something else?

Many mid-market organizations cannot answer those four questions today. That is not a criticism. They lacked the staff or the mandate to answer them because, until recently, nobody was asking. The good news is that getting there is not exotic work. It is the same operational discipline we have applied to users, devices, and servers for decades, now applied to a new kind of actor on the network.

Ask every department head what AI tools their teams are using, including anything embedded in software the company already owns. Then check those answers against what your identity and cloud logs show, because the two lists may not match. Write it down. An imperfect inventory you maintain is worth more than a perfect one you never build. This is the foundation on which everything else stands.

Once you know what exists, assign a name to each agent. Not a department. A person. That person does not need to be technical. They need to be able to explain what the agent is for, what it is allowed to do, and when it should be turned off. In a mid-market company, that owner usually wears four other hats. That is fine. The point is that when something goes wrong, there is one phone number to call.

Every agent should start with the minimum access needed to do its job and nothing more. I have seen agents provisioned with the same broad permissions as the employee who set them up, simply because that was the easy path. An agent that can read every file in the company to answer one question is a breach waiting for a trigger. The zero-trust principles we already apply to people, where every session is verified and access is granted only when needed, apply to agents just as well. Access should grow only when the owner signs off.

Agents act at machine speed, and they do not take lunch breaks. If you are not logging what they touch and alerting on behavior outside their lane, you will hear about a problem from a customer or a regulator instead of from your own systems. This does not require a new category of tooling. It requires making sure agent activity flows into the monitoring and alerting you already have, or should have, and that somebody is watching it.

I have said for years that the right posture is to assume you will be compromised and build so you can recover. That applies here. One of these agents will eventually do something it was never authorized to do. Decide now how you will isolate it, revoke its access, and restore whatever it touched. Write that into your incident response playbook the same way you would for a compromised user account, because that is functionally what it is.

None of this requires a governance office. It requires a list, a few names, some access rules, a log for someone to read, and a plan. The frameworks tell you where to end up. This is the practical path for a mid-market company to get there, and it is work that a good security partner can help you stand up.

The agents are already in your environment. The only question is whether you can see them.

Comments

TechBullion

FinTech News and Information

Copyright © 2026 TechBullion. All Rights Reserved.

To Top

Pin It on Pinterest

Share This