The adoption of multi-agent systems based on large language models (LLMs) is transforming the way companies automate processes, analyze information and serve their customers. These systems, however, introduce a layer of complexity that traditional security metrics do not capture. When an organization deploys a pipeline made up of a planner and an executor, security outcomes can vary for reasons that have little to do with the architecture itself and more to do with how instructions are phrased, how authority is distributed and how an original request is interpreted. Security in multi-agent systems cannot be reduced to a single number. More and more companies rely on architectures where a planning agent breaks a request down into tasks and an executing agent carries them out. In that environment, comparing a direct response with the pipeline output and reporting the difference as an 'architecture effect' is a dangerous oversimplification. That difference can hide opposing mechanisms that cancel one another out and therefore create a false sense of stability. In this article we analyze those mechanisms from a technical and business perspective, and propose a more granular evaluation approach for those building critical software.
The first such mechanism is operational reframing. A planner can take a request with problematic intent and turn it into a sequence of steps that, viewed in isolation, look like legitimate operational work. This phenomenon is not exclusive to LLMs; it also appears in traditional automation, but in multi-agent systems its impact is greater because the executor receives the task already reformulated, without enough context to detect the original intent. During our evaluations of AI agents for clients in different sectors, we have observed that the design of the planning prompt is just as relevant as the underlying model. A seemingly harmless request can become an operational instruction that the executor follows without question. That is why security starts well before the final response: it starts in how intent is transformed along the chain of agents.
At Q2BSTUDIO we work on custom software and artificial intelligence platforms, and we know that security cannot be an added layer at the end. When we integrate AI agents into business processes, the first step is to define evaluation criteria that separate the behavior of the planner, the behavior of the executor and the behavior of the delegation environment. Otherwise, an aggregate metric can show an acceptable result while hiding a real vulnerability: that the system is unsafe when asked to reformulate the original request. This nuance is especially important in enterprise environments where agent errors are not only a technical problem, but also a compliance, reputational and operational risk.
The second mechanism is planner behavior. In some cases, the planner rejects the request or rewrites it by removing harmful elements. In others, it transforms it into a series of steps that the executor interprets as a legitimate order. The difference between these two behaviors is not a stable property of the model: it depends on the prompt, the context, the temperature, even the paired model. Therefore, evaluating only the complete pipeline makes it impossible to know whether a safe result is due to good filtering by the planner or to the absence of a truly dangerous request. This ambiguity is especially relevant in corporate environments on AWS/Azure cloud, where automated decisions scale quickly and a small interpretation error can affect thousands of users.
The third mechanism is delegation framing. When the planner hands a subtask to the executor, it often adds phrases that imply prior approval or authority. Those phrases can make the executor assume that the task has already been validated and that its responsibility is simply to complete it. Our internal analyses show that changing a single line in the delegation prompt — for example, adding an explicit skepticism instruction — can drastically reduce compliance with unsafe instructions. This finding has direct implications for software development: security is not managed only with better models, but also with better communication protocols between agents. The way authority is granted within a system is a design decision, not a minor detail.
An important consequence of this complexity is that rankings based on direct responses do not predict behavior well in a deployed multi-agent system. A model that responds very safely to a direct request can become much more permissive when it acts as an executor under a planner that reformulates the request. Another model can show an almost zero aggregate effect, but only because the planner rejects many requests: if the planner is modified, the risk appears. This variability must be taken into account when selecting technology vendors and when designing cybersecurity evaluations. There is no universal model hierarchy; what exists is a complex interaction between capabilities, prompts and agent architecture.
For companies, this means that governance of AI agents must be as rigorous as that of any other critical system. It is not enough to monitor dashboards in Power BI or configure cloud alerts; it is necessary to instrument the behavior of each agent, record its intermediate decisions and subject it to controlled tests that reveal how it responds to reframings, ambiguous delegations and adversarial contexts. At Q2BSTUDIO we apply these principles in process automation projects, integrating control mechanisms that go beyond the final response. The combination of generative AI and automation can deliver real value, as long as it is implemented with proper governance. To learn more about building robust AI agents, we recommend reviewing our artificial intelligence practice. If the goal is to reduce operating costs, software process automation also benefits from this security-by-design approach.
Model variability is an argument for continuous evaluation. Certifying a model at a single point in time is not enough; vendors update their systems, change their security policies and adjust their weights. A multi-agent system that is safe today can stop being safe tomorrow without the application code changing. For this reason, companies need an observability layer that records not only final responses, but also intermediate reformulations, rejections and uncertainty signals. This security telemetry is as valuable as the business data that feeds BI/Power BI dashboards, and it must be treated with the same level of rigor. In AWS/Azure cloud environments, this telemetry can be integrated with existing monitoring systems to generate early warnings about anomalous patterns.
To avoid misdiagnosis, we propose an evaluation design with several controlled conditions: direct response; planning without execution; execution after neutral delegation; execution after delegation that assumes approval; and execution after skeptical delegation. This matrix makes it possible to isolate the effect of operational reframing, the planner’s tendency to reject or transform, and the executor’s sensitivity to the authority frame. It is a demanding approach, but it is the only way to know whether the risk lies in the model, the prompt, the integration or a combination of all of them. In custom software projects, this type of testing is just as important as unit or integration testing. In fact, it should be part of the development lifecycle, not only the final audit.
Q2BSTUDIO’s role in this context is to help organizations translate these risks into engineering decisions. Our team works at the intersection of AI, cybersecurity and custom application development, and has developed its own methodology for evaluating multi-agent systems before they go into production. That methodology combines LLM-specific penetration testing, prompt injection analysis and detailed tracking of the authority flow between agents. It is not a generic checklist, but a process adapted to the client’s architecture and sector. This approach allows companies to deploy AI agents with greater confidence, knowing that risk has been identified, quantified and mitigated before it becomes an incident.
In summary, security in multi-agent systems is neither a static attribute of the model nor an emergent property of the architecture. It depends on how intent is formulated, how authority is delegated and how instructions are interpreted in the operational context. Evaluations that report a single aggregate effect are insufficient. It is necessary to publish breakdowns by mechanism, by condition and by model pairing. Only then can the origin of a failure be correctly attributed and effective countermeasures designed. At Q2BSTUDIO we believe that the next frontier of custom software is not only about generating better responses, but about building systems that know when they must refuse to respond.
