Many enterprises spread AI workloads across OpenAI, Gemini, and Copilot, believing vendor diversity buys safety. Recent adversarial testing suggests otherwise: different models, different companies, and strikingly similar execution failures. The missing layer is not another model. It is deterministic runtime governance.
At a glance:
- What happened: In recent adversarial testing, the same multi-turn privilege escalation techniques produced comparable defensive failure modes across multiple frontier AI platforms.
- What it exposes: Buying from several vendors reduces vendor concentration risk. It does not necessarily reduce execution risk, because the boundary that decides what an agent may do still lives inside software you neither own nor control.
- What to examine: Who actually controls execution between your AI agents and your production systems, and how you would prove it.
Two Different Risks, One Confused Strategy
Most organizations think buying multiple AI vendors reduces risk.
It does, in one specific sense. If a single provider raises prices, changes terms, suffers an outage, or deprecates a model your workflows depend on, having a second provider keeps you running. That is vendor concentration risk, and diversifying across providers is a sensible way to manage it.
But many enterprises have quietly stretched that logic further than it reaches. They deploy OpenAI for one workflow, Gemini for another, and Copilot for internal productivity, and they assume that multiple providers create independent security boundaries. The reasoning feels intuitive: different companies, different models, different safety teams, so surely the failure modes differ too.
That assumption deserves scrutiny.
Key quote: “Provider diversity is not the same as security diversity.”
What the Testing Showed
In recent adversarial testing, the same multi-turn privilege escalation techniques produced comparable defensive failure modes across multiple frontier AI platforms.
Pause on the shape of that result. The techniques did not need to be reinvented for each platform. A multi-turn approach, one that builds context, establishes trust, and escalates privilege gradually across several exchanges, found similar classes of execution weaknesses wherever it was tried. Different models. Different companies. Similar classes of execution challenges.
This is CSI’s own reported testing, and it should be read with the limits that implies: an observed pattern, not a universal law, and not a claim about which platform failed in which way. But the pattern points at something structural rather than incidental. When the same approach works in comparable ways across independently built systems, the shared weakness is probably in the shared architecture, not in any one vendor’s implementation.
Which raises the question every enterprise leader should be asking: if the defensive failure modes are similar across vendors, what exactly is the second vendor protecting you from?
Three vendors, three workflows, one shared execution path into corporate systems. Illustrative artwork.
Why the Same Techniques Work Everywhere
Key quote: “If your security strategy depends on a model’s internal alignment mechanisms preventing unauthorized actions, then your execution boundary ultimately resides inside software you neither own nor control.”
Frontier AI companies optimize models. They train them to be helpful, to refuse harmful requests, and to behave within broad safety guidelines. That work is real, and it reduces certain kinds of harm. But it operates at the level of behavior, inside the model’s weights and its system instructions.
Here is the structural problem. If your security strategy depends on those internal mechanisms to prevent unauthorized actions, then your execution boundary lives inside software you neither own nor control. You cannot inspect the weights. You cannot pin the behavior across model versions. You cannot encode your organization’s unique authorization policies, operational tolerances, regulatory obligations, or risk appetite inside someone else’s alignment process. Those responsibilities remain yours, but the mechanism enforcing them belongs to the vendor.
And vendors, quite reasonably, optimize for their own objectives: capability, generality, and broad safety. They cannot enforce your organization’s specific authorization policies, because your policies are not their product. When every frontier platform shares this architecture, behavioral safeguards plus a direct path to your systems, it should not surprise anyone that the same multi-turn techniques find comparable purchase everywhere. The models differ. The architecture of trust does not.
Adding vendors changes the logos. Adding an external authorization check changes the security architecture. Conceptual diagram.
Ask What the Second Vendor Actually Adds
Consider a concrete scenario. Your team runs a capable agent on Vendor A with credentials that can read a customer database. You add Vendor B for a second workflow, with credentials that can modify billing records. You now have two vendors. How many independent execution boundaries do you have?
If the answer is “two,” look closer. Each agent’s ability to act still depends on its own model’s internal judgment about what is appropriate. Neither vendor enforces your rule that billing changes require a manager’s approval, or that the customer database is read-only after hours, or that no agent may touch both systems in the same session. Those are your policies. Neither model was built around them.
This is the question that matters, asked in its useful form: not “which model should we buy,” but “what determines whether a specific action is authorized, and where does that determination happen?” If the honest answer is “the model’s judgment, inside the vendor’s software,” then adding vendors multiplied your attack surface while adding no new control. You diversified your suppliers. You did not diversify your security.
Now extend the scenario one step further. If a multi-turn technique persuades one model to escalate its privilege, what in your architecture stops the same technique from working against the next vendor’s model? If the answer is nothing structural, just the hope that a different safety team caught it, then your multi-vendor strategy is a procurement plan wearing a security costume.
Where the Execution Boundary Should Live
The missing layer is deterministic runtime governance.
Instead of asking an LLM whether an action is safe, an external Runtime Governor independently evaluates each consequential request against five questions: identity (who is asking?), authority (what is it permitted to do?), policy (which organizational rules apply?), context (under what conditions?), and admissibility (is this action allowed at all?). For high-consequence operations, execution proceeds only when those conditions are satisfied. Otherwise, the request fails closed before it reaches the operating system.
An alignment-dependent boundary asks the model to behave. A runtime-enforced boundary checks the action before it executes. Conceptual diagram.
Notice what changed. The decision about whether an action executes no longer depends on the model’s behavior in that moment. It depends on an independent check, defined by you, running outside the model’s context, against your policies. The model can still be clever, still be helpful, still misunderstand an instruction. What it cannot do is convert a misunderstanding into a production change, because the governor stands between the request and the operating system.
Key quote: “Observation explains what happened. Constraint determines what is allowed to happen.”
Monitoring tells you what the agent did. Logging tells you what happened. Both are valuable, and you should have both. But neither one stops the next action. Only a constraint, evaluated before execution, determines what is allowed to happen next. That is the difference between watching the boundary and being the boundary.
Intelligence Can Be Rented. Execution Authority Should Remain Yours.
As organizations expand their use of agentic AI, the strategic question is shifting. It is no longer “which model should we buy?” It is becoming “who actually controls execution?”
That is an architectural dependency, not merely a vendor choice. Rented intelligence is a reasonable procurement decision. Rented execution authority is an abdication, because the party that decides what runs in your environment is the party that governs your environment, whatever the contract says.
So ask the question directly, and answer it concretely: what architectural controls are you putting between your AI agents and your production systems? If the list reads “we use three vendors,” you have answered a procurement question, not a security one. The fix is not to consolidate back to one vendor. It is to add the layer no vendor can sell you: your own deterministic check on what executes, under your authority, before it reaches your systems.
What to Do Next
Inspect what your agents can reach, test whether the boundary holds across vendors, then decide where enforcement lives. Proposed verification steps.
1. Inspect. Have your platform owner inventory every agent across every vendor deployment. For each one, record the production credentials it can reach and the actions those credentials permit.
2. Test. In a controlled environment, run the same multi-turn privilege escalation technique against each vendor path your organization uses. Record whether the boundary stopped each attempt, and which layer made the decision.
3. Decide. If authorization still depends on each model’s internal judgment, scope a pilot that places an external authorization check between agents and production. Verify that legitimate work still completes before you expand it.
Find Your Exposure First
Free AI governance assessment, instant score, no sales call required.
