
IMAGE: Alcatel-Lucent Enterprise
An AI agent does not have to break into an enterprise to cause damage. It may already have permission to enter, credentials to use and a legitimate task to complete. The security failure begins when the actions it takes exceed the authority its human operator intended to delegate.
That gap between access and authority is becoming a defining challenge for enterprise security. A connection can be permitted while the activity travelling through it is inappropriate. An agent can pursue an approved objective through steps nobody explicitly authorised.
Speaking to Deeptech Times at GovWare 2026 in Singapore, Charles Matthews, senior vice president of portfolio strategy at Alcatel-Lucent Enterprise, described the shift as a separation between the person commissioning work and the software deciding how to execute it.
“Before, the humans were in charge of the action. So now you have a decoupling of the actor and the action,” Matthews said. “We want them to act on behalf of us, and that’s what they do, but they also have agency: they can make decisions on their own. And I think that’s what we’re trying to control for.”
For business leaders, the implication is uncomfortable. Giving an agent access does not establish that every subsequent decision is acceptable. Yet the productivity case for agents depends on letting them make at least some decisions without waiting for a person.
The network offers an important means of containing that freedom. Matthews’ account also exposes where its authority ends.
Access does not establish permission to act
Matthews argues that familiar network access control principles remain useful. Enterprises have already adapted from managing PCs to accommodating multiple mobile devices per employee and then large populations of connected equipment. Each transition required better ways to identify what was connecting and decide what it could reach.
Agents introduce another kind of actor. They can operate through existing applications and credentials, making the relationship between a connection and the entity behind it less straightforward.
Matthews points to several possible clues: calls to model services, client software fingerprints and patterns of activity. Automated traffic may have a cadence that differs from human work, helping defenders establish a baseline and investigate deviations.
But recognising likely agent traffic is not the same as identifying an individual agent, its owner or its delegated authority. An approved model connection does not reveal whether the task is approved. Several agents sharing an application or credential further complicate attribution.
That distinction matters for procurement. A system that detects AI-related traffic should not automatically be treated as one that can enforce policy against each agent individually. Matthews describes the work as early.
“There’s always been a gap between new entities getting to the network and the security and governance framework for it. We’re at the beginning of that for agents,” he said.
Behaviour offers clues but not the whole answer
For network enforcement, Matthews argues, defenders need not first resolve whether harmful behaviour was deliberate. An agent pursuing a legitimate task can still take an unacceptable step. If the activity violates an enforceable policy, containment should not depend on establishing motive.
“The network doesn’t have to understand a device’s intention, whether it’s a camera or a blood pressure monitor. It just has to understand its behaviour. Is it doing what it’s supposed to be doing?” Matthews said. “The network has a lot of different levers that it can pull, but it doesn’t necessarily need to understand intent.”
This is a useful operational principle. Security teams cannot afford a prolonged investigation into intent while information is leaving the organisation. Network controls can restrict destinations, segment traffic or interrupt sessions where their visibility and enforcement capabilities permit it.
The harder problem is deciding what counts as bad behaviour inside an otherwise approved service.
Consider a hypothetical customer service agent authorised to retrieve a customer’s record. If it instead attempts to export thousands of records through the same application, the destination alone cannot establish whether the request is legitimate. The application needs to enforce the permitted action and data scope.
Matthews acknowledges that boundary.
“The network has a lot to offer AI governance, but it can’t do it alone. It’s not the only assurance lever,” he said. “It can look at what happens in the ingress to an application, what happens at the egress of an application. But what goes on inside the application, whether or not credentials are authorised or not, whether certain actions are authorised or not, that really needs to sit with the application itself.”
His distinction is consequential: the network can observe and control traffic entering or leaving an application, but authorisation for activity inside that application must also be enforced there. Network admission cannot substitute for checks on what an agent is allowed to read, change or transmit.
OWASP’s guidance on excessive agency reinforces this point. It identifies excessive functionality, permissions and autonomy as sources of risk, and recommends enforcing authorisation in downstream systems rather than relying on the language model to decide whether an action is allowed.
For an enterprise, this means an instruction telling an agent to behave responsibly needs to be backed by restrictions in the systems it uses. Otherwise, the organisation is relying on the component making the decision to police its own authority.
The limits of a kill switch
Asked whether an agent can be stopped, Matthews offered a striking proposition with an explicit caveat.
“If you’re able to, and I’m not saying we’ve done this, but if you could see the agent activity live, I think the ultimate kill switch is the network,” he said. “The question is, can you do it in time? That’s really the problem.”
The qualification matters as much as the phrase. He presented this as conditional on being able to see and interrupt the relevant activity, not as a claim that a universal agent shutdown capability had already been delivered.
Cutting a connection may prevent further traffic across that point. It does not reverse an action already completed. Matthews also cautioned that a broad network intervention could cut access for other users and devices, turning containment into a wider operational disruption.
He identified another limitation: an agent operating inside a software-as-a-service application may require controls within that service. The enterprise network may have no useful intervention point for the internal workflow. Credentials, authorisation and application-level controls then become critical.
The practical test is therefore whether an organisation can stop a specific agent’s activity across the systems it uses. Can it terminate sessions, revoke access and halt delegated work without disabling unrelated operations? What continues after the first connection is cut?
Those are questions to demonstrate in a controlled exercise before deployment. A shutdown procedure that has never been tested offers little assurance about how quickly it will work under pressure.
AI defence still needs defined boundaries
Matthews sees a role for AI-assisted network operations in closing the visibility gap. Such tools can establish traffic baselines, flag anomalies and support diagnosis and remediation. He argues that these capabilities could help defenders keep pace with agent activity, while acknowledging that they need adapting for this purpose.
The proposition deserves scrutiny. A deviation from normal traffic is a signal for investigation, not proof of wrongdoing. Equally, activity resembling an established pattern may still exceed an agent’s authority.
Adding automated defence also raises a second delegation question: what is the defensive system itself permitted to do? Flagging a suspicious session and autonomously disconnecting a business-critical service carry different consequences. The authority to respond needs boundaries just as the authority to act does.
Matthews frames the broader challenge as a balance between autonomy and guardrails. More capable agents require stronger controls, but excessive restrictions can undermine the value that justified deploying them.
For enterprises, that balance should be established task by task. An agent drafting an internal summary and one changing operational settings should not inherit the same permissions simply because both use AI.
Accountability begins before deployment
Matthews outlines four areas of preparation: an inventory of agents, policies defining their boundaries, visibility into behaviour, and a response model for when something goes wrong.
The sequence is sensible but its value depends on specificity. An inventory needs to connect an agent to a responsible owner and intended purpose. Policies need to become enforceable restrictions. Monitoring needs enough context to distinguish the agent from the application hosting it. Response procedures need someone with the authority to activate them.
“I think people should be accountable. The agents take agency on their own but humans need to be accountable for it,” Matthews said. “It’s not necessarily a blame game. But I think you would have to start with: what was supposed to happen? What policies did we have in place for the users, for the actors and for the creation of the agents?”
He locates that responsibility across the people designing and deploying agents, the network controls expected to contain them, and the applications expected to enforce permissions. An investigation should establish what each layer was supposed to do and where it failed.
That requires records linking the original task, the identity used, the tools invoked and the resulting actions. Without that chain, an organisation may know which account accessed a system while remaining unable to explain why the action occurred.
Matthews also connects governance to business value. Enterprises need to know whether agents are doing the work they were designed for and whether that work delivers the expected benefit. Even useful agents need to be inventoried and monitored.
“Most of us can’t really say how many agents are on our network and what are they doing. We need to be looking at what the agents were designed for and are they doing that,” Matthews added.
For APAC enterprises expanding agent deployments, the immediate challenge is to make that governance operational. Network security remains a powerful control point but its limits must shape the deployment from the outset. Before granting an agent more freedom, an enterprise should be able to identify whose authority it carries, show where that authority ends and demonstrate how it can be withdrawn.













