What a Manager needs to know.

On 16 September 2026, Andrew Yang appeared on CNBC's Squawk Box to discuss AI safety. During the interview, he described a conversation he had with the head of an AI lab who apparently told him that AI agents had already escaped controlled environments and left self replicating code on the internet. The concern, as Yang explained it, was that if more agents are released online, they could encounter what previous agents have left behind, interact with it, replicate it and progressively contaminate the environment.

It is quite an extraordinary claim and, before going any further, I think it is important to separate what has been demonstrated from what has been reported. I have not found public evidence proving the most dramatic part of Yang's story, that self replicating AI agents are spreading uncontrolled across the internet. What I did find, however, was enough to make me take the underlying issue seriously. Researchers are actively studying autonomous replication, there have been documented cases of agents reaching systems and environments they were not expected to reach, and frontier models are being tested to understand whether they can acquire resources, deploy copies of themselves, establish persistence and perform the individual steps that would eventually make autonomous replication possible.

As I started looking further into the subject, I realised that I was becoming interested in a slightly different question. Whether Yang's story is eventually proven right or wrong is obviously important, but for those of us dealing with AI governance inside organisations there is a much more immediate issue. What happens when we deliberately bring agents inside our companies and start giving them authority to perform real tasks?

This is where, in my opinion, the discussion becomes very different from the one we have been having about generative AI over the last few years. We are no longer talking only about a chatbot giving somebody an incorrect answer. An agent can be given an objective, access to applications and databases, credentials, the ability to read and write information, internet connectivity and permission to execute actions. It can potentially also invoke another agent or delegate part of its task to one. At that point we are not simply giving AI access to information. We are giving AI authority to act.

Think about a bank deploying an agent to investigate suspicious transactions, a hospital using one to coordinate patient administration, or an energy company allowing an agent to interact with maintenance and operational systems. Now imagine that the agent determines that the most efficient way to accomplish its objective is to delegate part of the task to another agent. Is it allowed to do that? What identity does this second agent use? What permissions does it receive? Can it create another agent? Can any of them access the internet or acquire additional resources? More importantly, does anybody actually know that these additional agents now exist and what they are doing?

I think our conversation about AI governance needs to evolve, and probably quite quickly. Until now we have quite rightly been asking questions about what data an AI system can access, whether information is confidential, whether the model is accurate, how decisions are validated and whether there is a human in the loop. None of those questions goes away, but with agentic AI they are no longer sufficient. There is another question that managers need to become comfortable asking: what can this AI actually do without asking anyone?

I don't believe a CEO, director or business manager needs to understand neural networks, model architecture or Python before approving the use of an AI agent. That would be unrealistic and, frankly, unnecessary. I do believe, however, that anyone authorising an agent to operate inside an organisation needs a minimum level of agentic AI literacy. If I were sitting in an approval meeting today, I would want to understand exactly what the agent is authorised to do, which systems it can access, what it can read, write, change, approve or delete, what identity it operates under and which actions it can take autonomously. I would also want to know when it is required to stop and ask a human.

I would then go a little further. Can it create, invoke or delegate work to another agent? If it does, what permissions does that agent receive and can the second agent create another one? Can any of them access the public internet? Can information contained in a website, document or email influence their behaviour? Can they acquire additional credentials, software, computing resources or services? How would we know if their behaviour started to deviate from what we expected, and would we be able to reconstruct exactly what happened afterwards? Finally, if something did go wrong, could we stop the agent immediately, including anything else it had created?

Very few of these questions are actually about how intelligent the model is. They are questions about authority, identity, permissions, boundaries, monitoring and accountability. This distinction matters because there is a significant difference between explaining what an agent has been designed to do and understanding everything it has been technically enabled to do.

Imagine, for example, that I am sitting in a bank approval meeting and somebody tells me, "This agent reconciles supplier invoices." It sounds relatively harmless. But imagine that instead they tell me, "This agent can read the supplier database, access the ERP, modify supplier records, generate payment instructions and communicate externally." It may be exactly the same agent, performing exactly the same intended function, but I am now looking at a very different risk profile. The first description tells me what we want the agent to do. The second tells me what we have actually given it the power to do.

For me, this leads to one of the most important questions a manager can ask before approving an agentic implementation: "What is the worst thing this agent could technically do with the permissions we are giving it, irrespective of what we told it to do?"

That question shifts the discussion from intended behaviour to possible behaviour, and that is where governance needs to operate. It is relatively easy to document what an agent is supposed to do. The harder task is establishing the boundaries of what it can do, particularly when something unexpected happens.

I would therefore also want to understand what technically prevents the agent from doing something it is not authorised to do. If the answer is simply that the agent has been instructed not to do it, I would be uncomfortable. For consequential actions I want controls outside the model. I want identity management, restricted permissions, transaction limits, network boundaries, approval gates, monitoring, logging, resource limits and mechanisms to revoke access and stop the agent. I don't want the agent to stay within its boundaries simply because we told it to. I want the architecture around the agent to define those boundaries.

There is another dimension to this that becomes increasingly important as agents begin to work with other agents. An organisation may approve one agent, but the governance model needs to consider what happens if that agent can create, invoke or coordinate others. Authority should not automatically reproduce itself. If an agent has access to sensitive information or consequential systems, the fact that it can delegate a task should not mean that it can also delegate all of its privileges. This is already familiar territory in cybersecurity and identity management. An employee authorised to approve a transaction is not automatically authorised to create another employee with identical permissions. Agentic systems should not be treated differently simply because delegation happens through software.

This is also why inventories and registers of AI systems may need to become more dynamic. Knowing that an organisation has approved twenty AI applications is useful, but in an agentic environment it may not tell us what is actually operating at a particular moment. We may need to know which agents are active, what created them, what identity they are using, which permissions they currently possess, what other agents they can invoke, what external information can influence them and how the complete chain can be terminated if necessary.

This brings me back to Andrew Yang's interview. Whether the internet has really been "polluted" by self replicating agents remains, from the evidence I have been able to find, an open question. Yang himself presented it as the belief of an unnamed lab head, rather than as an established fact, and the claim of internet wide self replication has not been substantiated publicly. What is documented is narrower, but still relevant: autonomous agents have reached environments beyond those originally intended, and researchers are now paying serious attention to how agents communicate, persist, acquire resources and potentially interact with information left by other agents. The distinction matters because there is no need to exaggerate the evidence in order to recognise the governance problem.

For business leaders, I am no longer sure that proving or disproving the "polluted internet" story is even the most important part of this discussion. The more immediate reality is that agents are coming into organisations now, and increasingly they will have access to our emails, documents, databases, ERP systems, customer information and eventually much more consequential operational systems.

The management question is therefore moving beyond "Should we use AI?" towards something more significant: "What authority are we prepared to give AI?"

I find it useful to think about that decision through eight areas. Intent tells me why we are deploying the agent. Authority tells me what we are actually allowing it to do. Autonomy tells me what it can do without asking us. Exposure tells me which systems, people and external information can interact with it. Consequence forces me to consider what happens when something goes badly wrong. Control tells me what technically prevents unacceptable actions. Evidence determines whether I can reconstruct and demonstrate what happened. Accountability establishes who ultimately owns the outcome.

None of this requires a manager to become an AI engineer. It does, however, require a change in management literacy. The ability to approve an agent responsibly cannot come simply from understanding its business case or watching a successful demonstration. A demonstration shows what the system can do when everything goes as expected. Governance has to consider what it can do when things do not.

Perhaps this is the part of the agentic AI discussion that deserves more attention. We have spent considerable time teaching leaders what AI can achieve. As agents move from generating content to performing actions, we now need to make sure that leaders also understand what they are authorising.

Approving an AI tool and delegating authority to an AI agent are not the same management decision.

Before signing the second one, I believe a manager should understand the difference.

Watch Andrew Yang declarations on CNBC

This article is also published on Medium as part of my public research and writing.