In the modern digital world, large organizations rely on software programs that act on their behalf. For decades, these programs were predictable: a human engineer would write the code, install the program, and give it a specific set of instructions. If the program needed to send an email or move money, it would do exactly what it was told, nothing more and nothing less. To keep these programs safe, companies built systems to check their identity and log their actions, much like a security guard checking a badge at a door. However, a new kind of software has arrived that changes the rules. These are autonomous agents, programs that do not just follow a fixed script but use artificial intelligence to decide for themselves what to do next. They can appear and disappear in seconds, they can choose from a vast array of possible actions that no human wrote down in advance, and anyone with an internet connection can create one. Because these agents are so different from the old, predictable programs, the security systems designed for the past fail to protect against them.

A team of researchers at Aurite AI has spent time building a new way to manage these unpredictable agents while they are running. They argue that trying to control these agents by fixing their code before they start is impossible, because the agent decides its own actions at the last moment. Instead, they propose a system that watches every single action the agent tries to take and stops it if it is not allowed. To make this work, they identified five essential questions that must be answered for every action. First, the system must know the agent exists. Second, it must prove who the agent is. Third, it must decide if the agent is allowed to do what it is asking. Fourth, it must create a permanent, unchangeable record of what happened that anyone can check later. Fifth, it must verify what the agent is made of to ensure it has not been secretly altered. The researchers built a system that answers the first four questions in real time and is currently developing the fifth as a separate tool. They found that while this approach is necessary, it comes with a cost: it slows down the system slightly and requires a small helper program to run alongside every agent.

The core problem the researchers faced is that traditional security relies on knowing exactly what a program will do before it starts. If a human employee is hired, they are given a badge and a list of rules. If a service is installed, it is given a specific job description. But an autonomous agent is different. It is like a traveler who arrives without a visa, claims to be a citizen, and then decides on the spot which country to visit and what to do there. The researchers found that old security tools, which were built for people and fixed services, cannot handle this. A standard security check might verify that the agent is who it says it is, but it cannot stop the agent from choosing a dangerous action that no one anticipated. Similarly, a security guard who only checks the list of approved actions cannot stop an agent from inventing a new, harmful action on the fly. The researchers concluded that the only way to govern these agents is to intervene at the exact moment they try to act, checking their request against a set of rules before letting them proceed.

To solve this, the team designed a system built around five distinct parts, or primitives, that work together. The first part is discovery. Because agents can appear anywhere and at any time, the system must be able to find them. The researchers realized that simply listing known agents is not enough, because the most dangerous agents are the ones that have not been registered yet. Their system is designed to notice when an agent tries to do something the system does not recognize. Instead of just blocking it, the system records the attempt and alerts a human operator, who can then decide if this new action should be allowed in the future. This turns a potential failure into a way to learn and update the rules.

The second part is identity. In the past, a program might claim to be a specific service, but the researchers found that agents can lie about who they are. Their system requires the agent to prove its identity using a digital credential that is generated automatically based on where the agent is running and what it is made of. This proof is checked at the very moment the agent tries to connect, ensuring that the system is talking to the real agent and not an imposter. This proof is short-lived and changes constantly, so even if a hacker steals a credential, it will expire quickly.

The third part is governance, which is the actual decision-making process. Before an agent can send an email or transfer funds, it must ask for permission. The system checks the request against a set of rules that are specific to that organization. If the action is allowed, the agent proceeds. If it is not, the request is blocked immediately. This happens before the action takes place, which is the only way to truly control the agent. The researchers also included a "kill switch" that can stop an agent instantly if it starts behaving badly, without waiting for its digital credentials to expire.

The fourth part is attestation, which is about creating a trustworthy record. In the past, companies kept logs of what their programs did, but those logs were written by the same programs that were being watched. If a program went rogue, it could also change the logs to hide its tracks. The researchers built a system that writes every decision to a special, unchangeable chain of records. This chain is signed with a secret key that only the organization holds, and it is designed so that anyone, even outside the company, can verify that the record is real and has not been tampered with. This provides a way to prove what happened in a court of law or during an investigation.

The fifth part is supply chain verification, which asks what the agent is actually made of. Even if an agent is identified and its actions are approved, it could be running on a compromised version of its software. The researchers have built tools to check the ingredients of the agent—its code, its data, and its dependencies—but these tools currently operate separately from the real-time security checks. While the researchers argue this verification is essential because a perfectly identified agent built on broken parts is still dangerous, this specific check does not yet block actions in the moment they occur; it remains a separate development step rather than an integrated part of the immediate authorization process.

The researchers tested their system in private trials with a few organizations. They found that four of the five parts are fully built and working, while the fifth is still being developed as a separate tool. They were honest about the costs of this new approach. Because the system checks every request before it happens, it adds a small delay to the process. It also requires a small helper program, called a sidecar, to run alongside every agent to manage its identity. Most importantly, if the security system itself goes down, the agents must stop working to stay safe. This means that a failure in the security system causes a stoppage in the business, which is a trade-off the researchers believe is necessary to prevent harm.

One of the most surprising findings was that the system must also govern itself. The researchers realized that the tools they built to manage the agents are themselves automated programs. They decided to run their own management tools through the same security checks as the customer agents. This means the system checks its own identity, decides if its own actions are allowed, and records its own decisions in the same unchangeable chain. This ensures that the people who built the security system cannot bypass the rules they created for others.

The researchers emphasize that their work is not about changing how the artificial intelligence models think or behave. They assume the models are working as intended and focus instead on the rules that govern what the models are allowed to do. They argue that trying to fix the problem by only improving the models is not enough, because even a well-behaved model needs limits on what it can access and change. Their solution is a practical framework that organizations can use to manage these new, unpredictable agents today. By breaking the problem down into five clear questions, they provide a roadmap for anyone trying to bring these powerful tools into a safe, controlled environment. The work is not finished, and the fifth part of the system is still being integrated, but the core idea—that these agents must be watched and checked in real time—has been proposed as a necessary architectural approach, with the design rationale validated through implementation rather than measured outcomes across a broad deployment population.