Enterprise Networks Know Who Connected. AI Agents Make the “Why” Harder

We spent decades teaching networks to recognize people, devices, and applications. AI agents are about to make that considerably more complicated. A few years ago, I was on a troubleshooting call when someone asked a question every network engineer eventually hears: “Does anyone know what that device is?” We had a MAC address and an IP address. We knew which switch it was connected to, which network it belonged to, and where it was communicating. What we didn't know was why it was there. Eventually, someone figured it out. It was a perfectly legitimate device, installed long enough ago that nobody on the call remembered it. Mystery solved. I hadn't thought about that kind of incident in a while. Then I started thinking about AI agents, because we are about to introduce something much stranger into enterprise infrastructure. This time, the problem isn't an unknown device. We may know exactly what the agent is, who owns it, and how it authenticated. What we may not know is why it decided to do what it did next. And I don't think our current definition of network identity is ready for that. Networks Have Always Liked Predictable Things Networking is, in many ways, the art of putting things into boxes. An employee laptop belongs in one category, a guest phone in another, and a printer, camera, IoT sensor, server, or cloud workload somewhere else. Once we know what something is, we can begin answering the questions that actually matter: How should it authenticate? What should it be allowed to access? Where should it be segmented? What happens when its behavior changes? We have spent decades building increasingly sophisticated technologies around those questions. 802.1X, RADIUS, certificates, NAC, device profiling, segmentation, machine identities, role-based policies, and Zero Trust all approach the problem from different angles, but much of it ultimately comes back to establishing identity and deciding what that identity is allowed to do. That model works reasonably well when the thing connecting behaves predictably. A printer may be annoying, but at least it doesn't wake up one morning and decide that querying Salesforce would help it finish a task. An AI agent can. That difference seems small until you consider what an agent actually does. Unlike a conventional endpoint that performs a relatively defined function, an agent can interpret an objective, select tools, retrieve information, call APIs, interact with applications, and potentially delegate parts of its work to other agents. The sequence of systems it accesses may not have been explicitly specified by the person who initiated the task. That makes an AI agent a very different kind of network user. One Request Can Become Dozens of Transactions Imagine a fairly ordinary Monday morning. I ask an AI assistant to prepare me for a customer meeting the following day. To me, that is one request. To the infrastructure underneath it, it could become dozens. The agent might check my calendar to identify the customer, search my email for the latest conversation, retrieve a proposal from a document repository, review CRM notes, and look for outstanding technical issues. It might notice that I am traveling and retrieve an itinerary. A specialized research agent could gather information about the company while another agent summarizes previous support activity. Eventually, all of that information is assembled into a neat briefing. I asked one question, but the infrastructure may have seen multiple systems accessed, APIs called, credentials presented, policies evaluated, and perhaps other autonomous systems invoked. So if somebody later asks, “Who accessed this resource?”, what is the correct answer? It was associated with me, certainly. But I didn't manually make each request. The agent did, although it was acting on my behalf. The application hosting the agent participated too, as did the workload executing it. If another agent was invoked along the way, the chain becomes even less obvious. This is where I think enterprise architecture needs to become much more precise about something we often discuss together: identity and authority are not the same thing. I Don't Think an AI Agent Should Simply Become Me Suppose I give someone the keys to my office and ask them to grab a blue folder from my desk. Giving them the key establishes that they can enter the room, but the instruction carries an obvious boundary. I did not authorize them to open every drawer, photocopy everything, hand the keys to someone else, and return next Thursday if they think of something useful. Humans understand the difference between access and delegated authority almost instinctively. Computers require us to define it. That is why I don't think the long-term answer to agentic access is simply allowing an AI agent to inherit all the permissions of the human using it. Consider an employee who legitimately has access to 10,000 customer records because of their role. They ask an agent to summarize what happened with one particular customer before a meeting. Does that agent really need access to all 10,000 records simply because the employee does? Probably not. It needs a much narrower form of authority: access to certain information, for a specific purpose, for a limited period of time. Now suppose that agent delegates part of the research to another agent. Should the original permissions travel with it? What happens if the second agent invokes a third service? When does the delegated authority expire? More importantly, can we later reconstruct the chain well enough to explain why every system was accessed? Traditional access control asks whether an identity is permitted to access a resource. Agentic systems add another dimension: whether this particular action is appropriate for the task the agent was authorized to perform. We have spent years saying that identity is the new perimeter. Agentic computing exposes a limitation in that idea. Identity without intent may no longer be enough. Knowing who an agent is does not necessarily tell us why it is accessing something. Knowing who authorized the agent does not tell us whether its current action remains within the boundaries of the original request. And knowing that a human could access a resource does not automatically mean every autonomous system acting for that human should. Zero Trust Gets More Complicated When the Requester Can Think The principles behind Zero Trust still make sense. Explicit verification, least privilege, continuous evaluation, and minimizing implicit trust become even more important when autonomous systems are involved. The implementation, however, becomes considerably more interesting. Consider a simple interaction between an employee and a CRM. We understand that relationship reasonably well. Now place an agent between them. The employee asks the agent for information from the CRM, and the agent decides it needs additional context from a document repository. It then checks email, calls an external API, and delegates some research to another agent. The original request may still be nothing more than, “Prepare me for tomorrow's meeting.” At what point does the authority associated with that request stop applying? Least privilege was already difficult when humans were involved. People change roles, projects end, permissions accumulate, and service accounts sometimes survive longer than the applications that created them. Everyone intends to clean those permissions up later. Later is a very busy place. Agentic systems could require authorization to become far more dynamic. Instead of asking whether a particular user can access an application, policy may eventually need to determine whether a specific agent can access a specific resource, on behalf of a particular person or system, for a defined task, for a limited period, and whether it is permitted to delegate any of that authority elsewhere. That is more than identity. It is contextual, delegated authority. Maybe Agents Need the Digital Equivalent of Passports One analogy I keep coming back to is international travel. A passport establishes identity, but possessing one does not grant unlimited permission to enter every country or perform every activity. A visa represents another layer of authority. A boarding pass is narrower still: it says that a particular person is authorized to take a particular journey at a particular time. AI agents may eventually require digital equivalents of those different layers. An agent could have its own verifiable identity without impersonating the human using it. The system could separately understand who delegated authority to that agent, what capabilities were granted, how long those permissions remain valid, and whether they can be passed to another agent. Imagine the difference that would make to an audit trail. Instead of a log simply stating that a person accessed a financial system, we might be able to reconstruct that the person authorized a meeting-preparation agent, which delegated a defined research task to another agent, which then accessed the financial system under a specific, temporary authority. The important part isn't the naming convention. It is that the chain of authority remains visible. This becomes particularly important when agents start communicating across organizational boundaries. An enterprise agent could interact with an agent operated by a SaaS provider, which could invoke another external service. At that point, what looks like machine-to-machine communication is actually a chain of autonomous actors operating across several trust domains. Connectivity is the easy part. Preserving trust across that chain is much harder. Eventually, Someone Is Going to Open a Ticket All elegant architecture eventually meets production. One day, someone is going to open a ticket that says, “AI assistant not working.” The priority will be high, the description will say it worked yesterday, and somebody will suggest that it is probably the Wi-Fi. Of course they will. The funny thing about troubleshooting infrastructure is that completely broken systems are often easier to diagnose. An interface is down, a cable is bad, authentication failed, or a certificate expired. There is something tangible to find. The difficult incidents are the ones where every individual component insists that it is healthy. The client is connected. Authentication succeeded. DHCP succeeded. DNS resolves. The access point looks healthy. The switch looks healthy. The firewall looks healthy. The application team reports no problems. Yet the person standing in front of you is still asking the perfectly reasonable question: “Then why doesn't it work?” I have seen enough of those situations to know that troubleshooting complex infrastructure is often less about finding a broken component and more about reconstructing a story across multiple systems. Agentic AI makes that story considerably longer. When an agent can choose tools, retry operations, change endpoints, invoke other services, and delegate work, the operational question may no longer be simply, “What happened to this connection?” We may need to understand what sequence of autonomous decisions caused those connections to exist in the first place. That is where networking and AI observability start colliding. The Packet Can Tell Us What Happened, Not Why Networks already provide an extraordinary amount of evidence. Depending on the environment, we can observe source and destination, protocol, port, path, latency, packet loss, flows, authentication events, and policy decisions. We can often reconstruct a remarkable amount about what happened to a connection. Suppose the network observes Agent A communicating with API B. It can potentially tell us when the connection occurred, where it traveled, how it performed, and whether security policy permitted it. What it may not know is that an employee asked Agent A to complete a particular task, Agent A concluded that a certain capability was necessary, and that decision caused it to access API B using authority temporarily delegated by the employee. The packet tells us what happened. It doesn't tell us why it happened. Historically, that hasn't been the network's job, and I don't think routers should suddenly start interpreting natural-language prompts. They already have enough responsibilities. The more interesting architectural question is how much of that context the broader infrastructure needs to understand. Agent identity might belong in an identity platform. Delegated authority could be represented elsewhere. Applications may expose task context. Security systems can evaluate behavior. A policy engine might correlate those signals, while the network simply enforces the resulting decision. The exact architecture will evolve, but somewhere in that system, intent needs to meet identity. Otherwise, we can know exactly who accessed something without knowing whether that access made sense in the context of what the agent was supposed to be doing. Observability Is About to Become a Group Project Anyone who has worked a sufficiently complicated production incident has probably joined the meeting where every team says some variation of, “Everything looks good on our side.” The network team sees healthy connectivity. Security sees successful authentication and permitted policy. The application team sees successful transactions. Cloud infrastructure is healthy. Every dashboard is green, and the user is still broken. Each team may actually be correct. The failure exists somewhere in the relationship between the layers. Agentic systems introduce another set of layers. The AI platform may see agent decisions and tool calls, the application team sees transactions, security sees identities and policies, and the network team sees connectivity and performance. Every group could possess an accurate view of its own domain while nobody possesses the complete sequence of events. Useful observability in an agentic environment may therefore need to correlate human intent with agent decisions, delegated authority, application requests, security decisions, network behavior, tool responses, and whatever the agent decides to do next. That is no longer merely monitoring. It is reconstructing causality. And I suspect causality will become one of the most valuable things infrastructure platforms can provide as autonomous systems become more common. Real Infrastructure Is Messier Than the Architecture Diagram There is another assumption we should be careful about: that these agents will operate inside clean, predictable environments. Enterprise infrastructure hasn't looked like that for years. It extends into branches, retail stores, restaurants, clinics, warehouses, hotels, home offices, cloud regions, and tiny locations where the closest thing to an IT department is someone willing to unplug a cable and plug it back in. A clean architecture diagram might show a client, a network, a security boundary, and a cloud service connected by perfectly straight arrows. Production has other ideas. Wireless clients roam. Primary circuits fail. Traffic moves to backup connectivity. Remote locations have physical constraints nobody anticipated during design. Certificates expire at inconvenient times. Devices move. Someone unplugs the wrong cable. A tablet that worked perfectly in one part of a building walks twenty feet and suddenly becomes everyone's highest-priority problem. The diagram remains beautiful throughout all of this. AI agents will operate in the messy version. Imagine an executive asking an agent to retrieve confidential information while working remotely. The user's request originates from one environment, the agent executes in another, enterprise data lives somewhere else, and a downstream agent may execute in yet another cloud. Connectivity can change in the middle of that workflow. Does the identity survive those transitions? Does delegated authority? Does the security context? Can we still reconstruct what happened after the fact? AI does not make infrastructure disappear. It simply makes our dependence on infrastructure easier to forget, right up until something breaks. The Network Doesn't Need to Become an LLM There is an understandable temptation right now to attach AI to everything. We already have AI networking, AI security, AI operations, AI assistants, and increasingly creative combinations of all four. The AI coffee machine cannot be far behind. I don't think the answer is to make every piece of infrastructure "intelligent." The forwarding plane should continue doing what decades of engineering have made it extraordinarily good at doing: moving packets reliably and predictably. What may need to change is the context available to the systems making policy decisions around that infrastructure. An agent could present its own identity. An identity system could establish delegation. A policy engine could understand task scope. Security platforms could evaluate behavior, and the network could enforce the resulting decision. The details will vary, but that architecture is much more interesting to me than simply adding an LLM to another operations console. The fundamental problem isn't that our infrastructure lacks intelligence. It may be that our current definition of trust lacks context. We Need to Start Asking Why Twenty years ago, an unknown device on the network made us nervous because we didn't know what it was. The AI-agent era presents almost the opposite problem. We may know exactly what the agent is, who created it, how it authenticated, and even which person or application originally asked it to perform a task. Yet all of that information can still leave us with a surprisingly important blind spot: why did it decide to make the next connection? That distinction matters because identity tells us who or what is communicating, but it does not necessarily explain the intent behind the communication. An authenticated agent could be behaving exactly as designed while taking an action that falls outside the scope of what the user originally intended. As agents become capable of choosing tools, invoking APIs, delegating work, and adapting their own workflows, simply proving identity may no longer provide enough context to make a meaningful trust decision. The “why” question carries more weight than it initially appears to. It encompasses the task that triggered the action, the person or system that delegated the authority, the boundaries of that authority, whether it can be passed to another agent, and when it should expire. These may sound like application-layer concerns today, but the moment infrastructure is expected to enforce policy around autonomous systems, they become architectural concerns too. I suspect this question will ultimately have a greater impact on enterprise architecture than simply adding another AI assistant to the network operations console. The difficult part of the agentic era will not be connecting AI agents to our infrastructure. We already know how to connect things. The difficult part will be deciding what it means to trust something that can decide for itself what to do next.