Agents are increasingly doing more themselves. How do we keep them manageable?

Agents are evolving rapidly. Where they used to mainly look up information or draw up a concept, they are increasingly gaining access to data sources, applications and processes. They can combine information, determine a next step and sometimes also carry it out independently.

That offers many possibilities. At the same time, something essential changes as soon as an agent not only supports, but also acts. Access to information then takes on a different meaning. An error can have an impact on a process. And if something goes wrong, you want to be able to find out exactly what an officer did and why.

That's why we don't just look at what is technically possible with agents. Governance and security must grow with the space you give an agent. We already know many principles for this from identity, security and information management. With agents, they only get a new application.

First know which agents are active

Good management starts with overview. Which agents are used within the organization? What are they for? What data sources and systems do they use? And who is responsible for their operation?

That overview is less obvious than it may sound. In our recent benchmark (only available in Dutch) of commercial organizations already using Microsoft Copilot, 45 percent said they don't know how many agents are active or don't yet have an active policy to manage them. This is becoming more relevant now that employees can build agents themselves more easily and existing agents are getting more and more options.

Moreover, an officer can start small. For example, within one team, for one specific task. As usage grows, the same agent can gain access to more information or become part of a process that other agents now rely on. That's why it helps to clearly define what an agent exists for, who owns it, and what systems are needed to perform their job from the start. This prevents agents from growing into an important part of the organization without anyone having a good view of it.

Access alone doesn't tell enough

When it comes to security, we traditionally look a lot at access rights. Who is allowed to view which information and under what conditions? This remains important for agents, but it is not enough. An employee with access to a hundred customer files can view that information and then decide for himself what happens to it. An agent with the same access rights can process all files one after the other, add information from other systems and immediately perform a next step.

On paper, the employee and the agent may have the same access. In practice, their impact can vary greatly. That is why we also look at the space to act with agents. What task does the agent perform? What information does he need for this? Which systems should he be able to use? And what actions can he perform independently?

An agent summarizing information poses different risks than an agent modifying records, sending messages, or initiating actions in a business-critical process. By consciously demarcating that room for manoeuvre, you can give an officer sufficient opportunities to do his job well without automatically opening up all available technical possibilities.

Not every action requires human control

Agents become interesting because they can perform tasks independently. When an employee has to approve every step, a large part of that added value disappears. Human control therefore does not mean that someone has to watch all the time. The point is that you determine in advance which actions an officer can continue independently and when an extra check is wise. The possible impact of an action plays a role in this.

Collecting or classifying information can be done independently in many situations. Modifying large amounts of data, sharing sensitive information, or performing an action with financial consequences may require more control. That doesn't have to be a complicated model. It already helps to consciously look at the task for each agent, the possible consequences of errors and the extent to which an action taken can be reversed. This prevents all agents from falling under the same rules, while their role and impact can differ greatly in practice.

Can we find out why an officer did something?

Even with a well-equipped officer, something can go wrong. A source may contain incorrect information, a document may have been manipulated, a link may react differently than expected, or an agent may arrive at an outcome based on a combination of information that no one had anticipated.

At such a moment, a technical log line that only states that an action has been performed successfully is of little use. You want to be able to reconstruct what assignment the agent received, what information he used for this, which systems were consulted and what actions were subsequently performed. That context becomes increasingly important as agents work more independently.

With a deviating employee account, many steps within security are now known. You can block access, end sessions, and investigate what activity has occurred. With an officer, you also want to understand how an action came about and what follow-up steps might have resulted from it.

In our benchmark (only available in Dutch), 83 percent of organizations said they had no visibility into incidents involving agents. This does not automatically mean that incidents will occur, but without sufficient visibility, it will be more difficult to determine with certainty what is happening. Monitoring agents therefore goes beyond just checking whether an account or link is functioning technically correctly. The context of actions must also be sufficiently visible to be able to investigate deviations.

Stopping an agent can also affect a business process

Another point of attention arises when agents become a structural part of daily work. What happens if you need to temporarily disable an agent?

With an officer who only looks for information, this is probably easy to absorb. But an agent can also process requests, adjust schedules, synchronize information between systems, or perform other operational tasks. In such a situation, a security measure directly affects business operations. That's why it's wise to look at dependencies for key agents as well. What processes use the agent? What happens if he is temporarily unavailable? Can someone take over the work? And how do you check which actions were still ongoing at the time the officer was stopped? These are the same kinds of questions that organizations have been asking for some time about critical applications and systems. As soon as an officer is given a structural role in a process, he also belongs in that continuity picture.

Agent governance doesn't have to become a separate program

With the arrival of agents, there is a tendency to set up a completely new governance and security model. This is not always necessary. Many building blocks are already in place. Identity governance can also take into account agent identities. Existing access control processes can be extended to include the actions an agent is allowed to perform. Monitoring can make agent activities visible in addition to users and applications. Incident response can include scenarios in which an agent is involved. And for critical processes, you can account for agent dependency. This is also in line with existing obligations regarding digital resilience, including the Cybersecurity Act. Topics such as risk management, access, incident response and business continuity are already important parts of this.

For agents, there is no need for a separate world to be created next to it. It is especially important to review existing agreements now that a new digital actor is being added that can process information and perform actions independently.

More autonomy requires better visibility

Agents will increasingly become part of daily work in the near future. That is exactly where a large part of their value arises. At the same time, with that autonomy comes the need to know what is happening within your environment. Which agents are active, what space have they been given, where do processes depend on them and can you reconstruct what happened if something goes differently than expected?

Well-designed governance doesn't have to slow down agent development. It provides clear boundaries within which you can further use them. Because the more an officer can do independently, the more important it becomes that you know where that independence begins and ends.