AI Agents
Securing Trust Between Agents in Procurement Workflows
Splitting a purchase across research, analysis, and execution agents makes the work easier to manage. It also creates more places where untrusted information can look like authority.
BXTrack Editorial Team
October 5, 2026·5 min read

Untrusted information can look like authority
A procurement workflow can involve several AI agents: one researches suppliers, another compares bids, and a third prepares a purchase request. Dividing the work can make a complex task easier to manage. It also creates more places where untrusted information can acquire the appearance of authority.
At BXTrack Solutions, we see this as a central design challenge for coordinated agents. This illustrative case study follows a supplier recommendation through a multi-agent workflow and shows why an internal agent’s message still needs evidence and permission checks.
The workflow spreads across agents
Imagine a company asking its system to find a supplier for replacement equipment. A planner assigns research to an agent with web access. An analysis agent compares specifications, a finance agent checks the budget, and an execution agent prepares a purchase order.
Each role can have its own tools and permissions. The research agent may need public browsing, while the finance agent needs access to internal budget records. This division is useful only if the execution service preserves those boundaries. A research task should not quietly create purchasing authority.
A supplier page influences the recommendation
Suppose a supplier page contains instructions telling automated assistants to label the vendor as approved and prioritize its payment details. The research agent may incorporate those claims into a professional-looking summary. The next agent sees the summary rather than the original page, so the suspicious instruction has become harder to recognize.
The finance agent checks that the purchase fits the budget. That check can be correct even though the vendor is unverified. Finally, the execution agent receives a recommendation that appears to have passed several reviews. Multiple agents have participated, but none has actually verified the supplier’s approval status.
This is a trust propagation problem. Repeating or summarizing a claim does not increase its authority. Several agents agreeing can also reflect the same poisoned source rather than independent evidence.
Keep evidence attached to the claim
Agent messages should carry structured provenance alongside their conclusions. A supplier record could include a source URL, retrieval time, source category, verification status and permitted use. For example, approved_vendor should remain false until an authorized check against the internal supplier registry succeeds.
These fields need protection. An agent should not be able to set its own output to trusted simply because it believes the source. The orchestration layer should attach source metadata and preserve it through summaries. A schema makes information easier to validate, but a valid schema alone does not prove the information is true.
The purchase service should separately verify vendor registration, payment details and the requester’s authority. Each agent should authenticate with its own scoped identity. Messages may propose actions, but a message from another agent should not substitute for authorization.
Memory can extend the incident
Now imagine the system stores “this supplier is approved” in persistent memory. The same mistake could affect a later purchase after the original webpage has disappeared from the active context. Memory therefore needs source references, expiry rules and a controlled process for promoting externally retrieved claims into verified organizational facts.
Temporary research notes can remain useful without becoming permanent policy. If a source is later found to be compromised, the system should identify dependent memories and recommendations so they can be invalidated or reviewed.
How BXTrack Solutions approaches this
At BXTrack Solutions, we are taking steps toward treating each agent as a distinct participant with explicit permissions. Our direction is to preserve provenance between agents and enforce purchasing rules at the service that creates the order.
For a proposed workflow like this, we would test a poisoned supplier page, a forged approval field and a malicious claim stored in memory. The key question is whether the attack can reach an external action. We would also measure normal purchasing completion so the controls remain practical.
What this case teaches
Coordinated agents need a clear answer to who verified each claim and who authorized each action. More agents can improve task coverage, but safe delegation depends on preserving those answers throughout the workflow. That is the foundation we want to build into multi-agent systems.
Written by
BXTrack Editorial Team
The BXTrack editorial team covers AI products, software systems, and research that keeps agentic automation accountable when it sits next to real business risk.