By Tim Burke, President & CEO, Quest Technology Management
This week’s AI headlines have been about the frontier. Anthropic’s Dario Amodei called on the largest labs to slow the pace of capability gains, and the leaders of his biggest competitors agreed. Congress is debating whether to ban superintelligence outright. Most of the executives I talk to read those stories and reasonably conclude that this debate is happening several floors above them.
But the coverage hides a practical lesson that applies directly to a 400-person manufacturer or a regional healthcare group deciding whether to turn on an AI assistant.
What the rogue agent story is about
The incident that keeps getting cited is the one from this summer, when a group of AI agents running in a research environment went after targets outside their assigned task and reportedly tried to get into the system evaluating them.
Strip away the science-fiction framing and look at what happened mechanically. Software with a job to do had more reach than its job required, and nobody had drawn the boundaries tightly enough to stop it from wandering. That is not a superintelligence problem. That is an access problem. And it is the same problem I see in mid-market companies every week, at a much smaller and much more boring scale.
When a company turns on an AI assistant across the business, the tool does not create new risks. It finds the old ones. The service account nobody has reviewed since 2019. The shared drive where a confidential folder sits next to a public one with identical permissions. The contractor who left in March and still has a working login. AI tools are built to read everything they are allowed to read and act on everything they are allowed to touch, at machine speed, without the social friction that used to keep a curious employee out of a folder they should not open. So the gaps that were quietly tolerable for a decade show up in an AI-generated summary on the wrong person’s screen.
AI adoption is a stress test for identity, access, and data classification. Most organizations have not passed it because they never had to take it before.
The conversation to have before you flip the switch
The frontier labs are debating how to pace the models. The conversation an executive team needs to have is about pacing the deployment, and it comes down to three questions the CEO, the CFO, and whoever runs IT should be able to answer together.
Do we know who and what has access to our systems today, and is that access still justified? That includes people, service accounts, integrations, and the AI agents already running inside software you pay for. Do we know which of our data is sensitive, where it lives, and whether it is labeled in a way a machine can respect? A classification scheme that exists only in a policy document is invisible to an AI tool. And if something goes wrong, do we know how we would find out, and how fast?
If the honest answer to any of these is no, that is not a reason to avoid AI. It is the reason to fix the foundation first, because those same weaknesses are exposed to attackers whether or not you ever deploy a single AI tool. I have said for years that the right posture is to assume you will be compromised and build for resilience. This week did not change that. It raised the price of ignoring it.
What IT leaders and MSPs can realistically get done
None of this requires a new department or a governance committee that produces slides. It requires a few disciplines, done in order, at a pace a mid-market team can sustain.
Start with an access review. Pull every account, human or otherwise, and ask a department head to confirm each one still needs what it has. You will find things. Everyone does. Then apply least privilege going forward, so a new user or a new AI agent starts with the minimum and grows only with sign-off. This is the same principle behind the zero trust access controls we have applied to people for years, and it is the single most effective thing you can do before broad AI enablement. It is also, not coincidentally, the boundary that was missing in the incident everyone is talking about.
Next, classify the data that matters. You do not need to label every file in the company. Identify the handful of categories that would hurt if exposed, such as financials, customer records, contracts, and employee data, and make sure those are stored and tagged in a way your tools can enforce. Then make the activity visible. AI-driven access needs to flow into the same monitoring and alerting you already rely on, and your incident response plan needs a scenario for an AI tool doing something nobody authorized.
For a company without a large internal team, this is where a managed services partner can help. At Quest we run this discovery through a cybersecurity workshop, and the moment a client sees the list of accounts and permissions they did not know existed is usually the moment the AI conversation gets practical.
Where accountability actually lands
One of the more useful things in this week’s news was the labs committing to give outside evaluators deep access to their own systems. That is the vendors accepting accountability for what they build. I welcome it, and I expect regulators in Washington, Brussels, and the statehouses will eventually formalize some version of it.
But I want to be direct with executives about something the coverage tends to obscure. When an AI tool inside your company surfaces data it should not have, the vendor did not decide who could see that data. You did, through permissions you set or inherited. The platform provider is accountable for building a tool that respects the controls you configure. A partner, whether that is an MSP, a co-managed arrangement, or an outside advisor, is accountable for doing good work and telling you the truth about what they find. But the organization owns the environment and the decisions about who gets access to what. That is true whether IT is handled internally, externally, or somewhere in between, and no frontier lab pledge, no framework, and no vendor contract moves it off your desk.
That is not a burden. It is the part you control. The labs will pace the frontier or they will not, and Congress will pass something or it will not. Either way, the companies that treat AI governance as an identity, access, and data problem, and fix it now, will be ready. The ones waiting for the debate to settle will find that whatever rules arrive ask them for exactly the work they could have finished a year earlier.
About the author
Tim Burke is CEO of Quest Technology Management, a managed IT and cybersecurity services provider. He has spent nearly three decades helping mid-market organizations build practical, resilient security programs.