Companies are moving rapidly from experimenting with individual AI assistants towards deploying networks of specialised agents capable of accessing corporate systems, delegating tasks and taking actions without continuous human supervision. That transition could bring substantial productivity gains, but it is also creating a new enterprise governance problem: companies increasingly need to know not only what their AI is capable of doing, but exactly what each agent can access, which other agents it can communicate with and who remains responsible when something goes wrong.
Speaking at Ai4 2026 in Las Vegas, Angelik Laboy Torres, Senior Developer Advocate at Retool, argued that governing one AI agent is fundamentally different from controlling a network of them. One agent may have a clearly defined task, a limited group of tools and a relatively understandable set of permissions. Once companies begin deploying multiple agents capable of communicating and delegating work between themselves, they are no longer managing isolated software applications. They are managing an interconnected system.
The challenge is unlikely to come from a deliberate decision by companies to create poorly controlled AI environments. Agent networks can emerge gradually. A marketing department builds an agent for content, finance introduces another for expenses, operations deploys agents to automate internal workflows and developers create specialised systems for support or engineering. Individually, each project may appear manageable. Collectively, however, they can create a growing network of automated systems with different permissions, data access and responsibilities but no single view of how they interact.
The risk increases because multi-agent systems are often designed around specialisation. Rather than asking one general-purpose AI system to complete an entire process, companies can divide the work among several agents. One researches information, another checks it, another prepares a response and another approves or executes an action. An orchestrating agent determines which specialist should perform each task.
This can make AI systems more capable, but the number of relationships increases rapidly. Two agents have only one potential connection between them. Five agents can have ten. Ten agents can create 45 possible relationships before databases, software platforms, APIs and external services are even considered. The governance problem therefore grows faster than the number of agents themselves.
One of the most important risks is permission leakage between systems. An agent might legitimately receive access to a database because it requires specific information to complete a task. If that agent subsequently delegates part of its work to another agent, companies need to ensure that the second system does not automatically inherit access it was never authorised to have.
Traditional enterprise security already operates on the principle that users and applications should receive only the permissions necessary to perform their roles. Agentic AI makes enforcement more complicated because software systems can increasingly initiate actions and delegate work dynamically.
The stronger approach is to give each agent its own clearly defined identity and permissions. An investigative agent may be allowed to read operational metrics but prevented from modifying a customer database. Another agent may be permitted to communicate through collaboration software but prevented from reading engineering systems. The objective is to stop authority from travelling automatically with the task.
This becomes particularly important as AI begins accessing sensitive financial, customer or operational information. A system may need temporary access to specific data without receiving permanent permission to browse an entire corporate database.
The second major challenge is auditability. Conventional business applications usually create relatively predictable records. A user signs into a system, performs an action and leaves a transaction history behind. Agentic systems can be more complicated because one agent may consult several data sources before asking another agent to perform part of the work, which may then invoke further software tools.
When something goes wrong, reconstructing that sequence can become difficult. For regulated businesses in particular, being able to explain that an AI system produced a particular result is not enough. Companies may need to establish which information the system accessed, what action it proposed, which tools it used, whether another agent became involved and who ultimately authorised the decision.
A governed multi-agent system therefore needs centralised observability that records interactions, tool calls, inputs, outputs, approvals and actions. If this information is scattered through separate logs across several applications, the organisation may technically possess records but still struggle to reconstruct what happened.
The third governance problem involves escalation. Most companies agree that certain AI actions should continue to require human approval. The more difficult question is precisely where those boundaries should be drawn and how the approval mechanism works operationally.
An AI system recommending that someone review an invoice creates relatively limited risk. An agent authorised to approve a substantial payment creates a very different level of exposure. The same distinction applies to IT infrastructure. An agent can investigate why a service has failed and recommend rolling back a software deployment. Automatically executing that rollback could potentially create a much larger incident if the AI diagnosis is incorrect.
Torres demonstrated this through a multi-agent system designed around an overnight IT incident. Instead of an engineer manually opening monitoring, incident-management and collaboration tools, specialised agents can gather information, investigate the suspected cause and prepare a recommended response.
The critical point is that the system does not necessarily execute the highest-risk action automatically. It might identify a software deployment as the likely cause of a problem and recommend rolling it back, but a human engineer still provides final approval. This allows AI to perform much of the investigative work without removing human responsibility from decisions capable of causing significant damage.
The concept of human-in-the-loop AI is not new. The operational problem is that many organisations describe human oversight as a principle without designing a specific mechanism for it.
A functioning governance system needs to establish what causes an agent to stop, which person or team receives the escalation, what information they receive and what happens to the workflow while a decision is pending. Otherwise, the system risks moving in one of two undesirable directions. Either agents execute actions beyond the level of authority companies intended to grant them, or automated workflows repeatedly stop because the system cannot determine who should make the next decision.
This means companies may need to classify agent actions according to risk. Low-impact, reversible processes could be automated extensively. Higher-risk activities involving financial transactions, customer information, infrastructure changes or regulatory obligations would require progressively stronger approval mechanisms.
The broader issue is that enterprise AI governance cannot simply be added once a system has reached production. Permissions, auditability and escalation rules should be inherited by agents from a common governance framework rather than recreated separately for every new application.
This becomes increasingly important as businesses deploy dozens or potentially hundreds of agents. If each department builds its own security model, approval system and logging infrastructure, governance can become fragmented in exactly the same way that enterprise data and software systems became fragmented during earlier technology cycles.
A central governance layer provides one alternative. New agents can inherit existing authentication, role-based controls and data-access policies instead of developers rebuilding them for every project.
There is an important commercial consequence to this approach. Security departments are frequently portrayed as barriers to rapid AI deployment because they raise questions about data exposure, permissions and accountability. Properly designed governance could produce the opposite effect.
If security teams can understand exactly what an agent is permitted to do, review its historical activity and stop sensitive actions until a person approves them, organisations may be more comfortable allowing AI systems to operate closer to core business processes. Governance therefore becomes an enabler of adoption rather than simply another compliance requirement.
That is especially important as enterprise AI moves from producing content towards controlling workflows. The risk associated with a chatbot generating an inaccurate paragraph is relatively contained. The risk associated with an autonomous agent changing a database, approving a transaction, modifying production software or sending customer information outside the organisation is considerably greater.
The relevant question consequently changes from whether the model gives good answers to whether the entire system operates inside clearly defined boundaries. That requires companies to understand the identity of every agent, the information it can access, the software tools it can operate and the other agents with which it is permitted to communicate.
It also requires clear accountability. AI systems themselves cannot assume legal or corporate responsibility. Even when decisions are largely automated, responsibility ultimately remains with the organisation deploying the technology and the people who designed the controls around it.
This is likely to become increasingly important for boards, insurers and regulators as AI agents gain greater autonomy. Companies may eventually need an inventory of agents similar to the asset inventories they already maintain for software systems, employees and devices.
Each agent could have an identifiable owner, defined business purpose, approved data access, specified autonomy level and documented escalation path. The organisation would then be able to answer basic questions that may become increasingly important during audits or incidents: which agents were operating, what were they authorised to do, which systems did they access and which human remained accountable for their actions?
The practical governance test can therefore remain relatively straightforward. Businesses should be able to define the data boundaries for every agent, require human approval for sensitive actions, reconstruct agent activity when necessary, apply existing enterprise permissions rather than creating uncontrolled parallel security models and introduce those controls at the beginning of development rather than after deployment.
The technology itself will continue evolving rapidly, and the architecture of agentic systems is unlikely to remain static. But the governance principles are familiar.
Companies have spent decades controlling access to financial systems, databases, industrial infrastructure and confidential information. AI agents introduce a new type of software actor, but they do not eliminate the requirement for permissions, accountability, auditability and human responsibility.
The difference is scale. A company may understand the behaviour of one experimental agent reasonably well. Understanding dozens of agents interacting continuously across hundreds of systems is much harder.
That could make multi-agent governance one of the most important infrastructure questions in the next stage of enterprise AI. The companies that solve it may not necessarily be those deploying the most agents. They could instead be those capable of allowing increasingly autonomous systems to operate without losing visibility over what the machines are doing, what they can reach and who ultimately remains in control.
Source: CIJ.World Research & Analysis Team