Configuration
Access Through Human Identity
Access Through Non-Human Identity
Autonomous Action Control
Connected Tools and Functions
Enterprise Retrieval Access
External Communication Access
Model and Build Provenance
Model Objective Alignment
Orchestrated AI System
Persistent Memory Access
Standing Instruction Stack
Vendor-Embedded AI
- ID: CF011
- Created: 26th August 2026
- Updated: 26th August 2026
- Contributors: Nimer Kees, James Weston,
Orchestrated AI System
An orchestrated AI system is a deployment pattern where multiple synthetic subjects coordinate to complete a goal. This may involve an orchestrator that decomposes work and delegates tasks to worker agents, or peer agents that call each other across services, teams, or organizations.
This deployment pattern creates an elevated exposure condition because agents may share context, instructions, tools, credentials, or outputs over trusted internal channels. The effective synthetic subject is the whole agent graph, not only the individual agent that performs the final action.
The primary risk is distributed authority. One manipulated agent, poisoned input, or unsafe delegation may spread across the system and cause other agents to act on untrusted instructions. Because agents may treat each other’s outputs as trusted, a single injected instruction can propagate through the graph and influence tool-equipped workers.
A related risk is diffuse attribution. Actions may appear in logs as “the system,” an orchestrator identity, a shared service account, or the final worker agent, rather than the agent or input that originated the decision. This can make intent, origin, data movement, and responsibility difficult to reconstruct after an adverse outcome.
Investigators should review the system directive, orchestration logic, delegation graph, agent identities, inter-agent messages, shared context, tool access, credentials, provenance records, and cross-boundary data flows. Particular attention should be given to new agent-to-agent paths, repeated instructions appearing across agents, aggregate access that exceeds the task scope, and actions that cannot be traced to an approved source.
Investigative Relevance
Orchestrated AI systems are relevant because they allow synthetic subjects to behave like a coordinated internal team. Their combined reach may exceed the access, autonomy, and speed of any individual agent.
This section is especially relevant where orchestrators delegate to tool-equipped workers, agents share context or service identities, agent-to-agent links cross teams or trust zones, or a single workflow can touch multiple systems, data classes, or organizations.
Subsections (4)
| ID | Name | Description |
|---|---|---|
| CF011.002 | Cross-Boundary Agent Collaboration | Cross-boundary agent collaboration occurs when peer agents owned by different teams, vendors, tenants, or organizations call each other over shared protocols or integrations. Each agent may treat the other’s output as both useful input and trusted instruction.
This deployment pattern creates an elevated exposure condition because trust is extended across boundaries that no single human subject could normally span. An instruction, recommendation, file, record, or tool result produced in one environment may be accepted and acted on inside another.
The primary risk is boundary-crossing instruction propagation. A malicious or injected instruction may move from one agent to another and influence actions outside the original trust zone. Internal confidential information, customer data, intellectual property, or regulated records may also pass to another agent, vendor, tenant, or organization without human awareness, creating legal, contractual, regulatory, or confidentiality exposure.
A related risk is weakened attribution. Logs may show only local agent activity rather than the external agent, source content, or original instruction that caused it. This can make origin, authorization, data movement, and responsibility difficult to reconstruct.
Investigators should review the agents’ directives, inter-agent protocols, trust relationships, authentication model, message provenance, shared context, tool outputs, data tags, and cross-boundary logs. Particular attention should be given to new collaboration paths, externally originated instructions, data appearing outside its authorized trust zone, and actions that cannot be traced to an approved source.
Investigative RelevanceCross-boundary agent collaboration is relevant because it allows synthetic subjects to extend trust and action across teams, vendors, tenants, or organizations. A harmful instruction or sensitive data transfer may propagate through legitimate collaboration paths while appearing to each receiving agent as authorized input. |
| CF011.003 | Inter-Agent Context Propagation | Inter-agent context propagation occurs when an orchestrated AI system is configured to pass one synthetic subject’s output into another synthetic subject’s context. This may occur through inter-agent messages, delegated task records, summaries, shared memory, generated work products, workflow state, tool outputs, or orchestration-layer handoffs.
This configuration creates an elevated exposure condition because model-visible context can move across agents, roles, tools, and trust boundaries. A receiving synthetic subject may rely on inherited context without knowing its original source, trust level, or integrity.
The primary risk is unvalidated context transfer. Content first processed by a low-trust or attacker-influenced synthetic subject may be reformatted, summarized, copied, or embedded into another agent’s task context. As the context moves through the system, its original provenance may become less visible while its ability to influence downstream behavior increases.
A related risk is capability amplification through delegation. A synthetic subject with limited access may pass inherited context to a tool-equipped worker, privileged agent, or downstream workflow with greater operational reach. The downstream synthetic subject may then act on that context as if it came from the orchestrator, an approved task record, or another trusted system component.
Investigators should review the agent graph, context-sharing configuration, delegation paths, inter-agent message formats, shared memory stores, task handoff records, summarization steps, tool-output routing, provenance tags, and trust-boundary controls. Particular attention should be given to context copied between agents, missing source attribution, inherited instructions, repeated unusual text appearing across agents, and downstream actions that trace back to propagated context rather than an approved operator objective.
Investigative RelevanceInter-agent context propagation is relevant because context-sharing is a design decision that defines how synthetic subjects influence each other. In an orchestrated system, the risk is not only what an individual agent can access, but what context it can pass to other agents with different permissions, tools, or responsibilities.
This sub-section is especially relevant where agents summarize each other’s work, pass task instructions, share memory, consume generated records, exchange tool outputs, or delegate actions to tool-equipped workers without enforcing provenance, trust-level separation, and integrity checks. |
| CF011.001 | Orchestrator and Worker Agents | An orchestrator and worker agent pattern uses a central planning agent to decompose a goal and delegate subtasks to specialized worker agents. The orchestrator may coordinate tool use, pass context between workers, sequence actions, and determine when the overall task is complete.
This deployment pattern creates an elevated exposure condition because the orchestrator may hold broad credentials, connectors, or authority needed to drive the full run. Its identity may aggregate the reach of multiple workers, making it a high-privilege chokepoint inside the system.
The primary risk is that a single manipulated orchestrator can direct harmful activity across many connected workers and systems. If the orchestrator is compromised, misdirected, or influenced by poisoned input, its instructions may propagate through the agent graph without a human reviewing each delegation step.
Investigators should review the orchestrator directive, delegation logic, worker permissions, shared context, credentials, tool access, inter-agent messages, task graph, and execution logs. Particular attention should be given to unexpected delegation paths, worker actions outside assigned subtasks, aggregate access exceeding task scope, and actions that cannot be traced to an approved operator objective.
Investigative RelevanceOrchestrator and worker agent patterns are relevant because they concentrate planning authority and distributed execution in one coordinated system. The orchestrator may not perform every action itself, but it can direct workers that hold specialized access or tools.
This sub-section is especially relevant where a central agent can invoke multiple workers, coordinate cross-system actions, aggregate credentials, pass instructions between agents, or complete multi-step workflows without human review between steps. |
| CF011.004 | Shared Agent Memory | Shared agent memory occurs when multiple agents read from or write to a common context window, memory store, scratchpad, or shared state repository. This allows synthetic subjects to build on each other’s work across steps, tasks, or sessions.
This deployment pattern creates an elevated exposure condition because the shared store becomes a common influence surface. Data, assumptions, instructions, or task state written by one agent may later be inherited by other agents and treated as trusted context.
The primary risk is persistent context poisoning. A malicious instruction, false assumption, sensitive record, or manipulated output may remain in shared memory and influence later runs. This can blend tainted state into otherwise legitimate work and make it difficult to determine which agent introduced the harmful content.
Investigators should review the shared memory design, write permissions, retention rules, provenance records, agent access paths, stored context, and memory retrieval logs. Particular attention should be given to persistent instructions, sensitive data copied into shared state, unexplained changes in agent behavior, and missing attribution for memory entries.
Investigative RelevanceShared agent memory is relevant because it allows one synthetic subject’s output to shape the behavior of others beyond the original interaction. The adverse outcome may occur later, in a different task, or through a different agent than the one that first ingested or wrote the tainted content.
This sub-section is especially relevant where agents share scratchpads, task state, long-term memory, vector memory, project context, or reusable summaries without strict provenance, expiry, access controls, and validation. |