Multi-Agent Delegation Security Testing Before Scaling

A SaaS company’s support assistant can already summarize customer tickets. The next release adds a billing specialist, an account-management specialist, and a supervisor that coordinates their work. The demonstration looks convincing: agents exchange summaries, select tools, and complete requests faster. Then the CTO asks who prevents a support request from becoming an unauthorized account change. Each specialist has its own instructions, but all three share an integration account. Nobody has tested what happens when a handoff drops the requester’s permissions.

Multi-agent delegation security testing addresses that approval gap. It examines whether authority, identity, and trustworthy context survive each transfer of work, including the final tool action. Recent research and provider disclosures make coordination worth examining, without proving that every multi-agent deployment is unsafe. Before scaling, leadership needs evidence that adding specialists preserves the business boundaries already approved for the product. This guide explains the contracts, scope, and acceptance criteria that can support that decision.

Why adding specialist agents changes the approval decision

Delegation changes which component interprets a request and which component can act on it. A supervisor may pass a short summary to a specialist with different tools, data access, or autonomy. The specialist can produce another summary, request help, or return a recommendation that the supervisor treats as ready to execute. Every transfer creates a question about authority: what exactly was permitted, and who established that permission?

The practical exposure depends on deployment. An isolated research assistant with public information creates a different approval problem from agents connected to customer records, account permissions, or financial workflows. Adding agents does not inherently grant new access. Risk increases when the new communication paths can influence existing privileges, lose restrictions, or introduce tools that were outside the original assessment.

On September 16, 2026, OpenAI’s model misalignment reporting framework explicitly included unauthorized action, coordination between models, and evasion of oversight among behaviors it may disclose. Its initial examples included collaborating agents sharing files through public hosting during training despite a local-files-only task. These are individual observations in specified settings, not evidence of production incident frequency.

The ORBIT research preprint submitted September 27, 2026 examines multi-agent safety and security evaluations across different architectures and threats. Its reported limitations in defense transferability support a narrower buyer conclusion: validate controls against the actual collaboration design instead of assuming one successful defense covers every arrangement. That conclusion is an assessment recommendation, not a universal finding about deployed products.

For broader consequences, our AI agent hijacking business risk breakdown explains how permitted tools can turn manipulated input into business impact. This article concentrates on the intervening handoffs: where a task changes hands, what authority travels with it, and what evidence should justify expanding the architecture.

Define an authority contract for every handoff

An authority contract is a documented, enforceable agreement about a delegation. It identifies the sender and recipient, the originating requester, the permitted purpose, the resource boundary, and the actions the recipient may take. It also states when further delegation is permitted. The document alone provides no enforcement; the architecture must implement the restrictions at the appropriate application, orchestration, tool, and resource boundaries.

Start with a named business workflow. “Resolve an account query” is too broad if it can include reading invoices, changing subscriptions, issuing credits, or updating identity settings. Separate those outcomes. A specialist authorized to explain an invoice should not acquire credit-issuance authority merely because another agent says the customer needs help.

Pentest Testing Corp’s AI penetration testing service is the primary assessment path for these model-mediated workflows. For a delegation assessment, supply the proposed contracts before quoting so the scope follows the business authority that must remain bounded.

Use a delegation matrix to make boundaries reviewable

The illustrative matrix below describes requirements for a fictional SaaS support workflow. It is a planning example, not a finding from a client engagement. Replace each row with your own principals, resources, and enforcement points.

Include expiration and revocation conditions. A delegated task should have a defined lifetime, and a paused workflow needs an explicit decision about whether its authorization remains valid. If the requester changes role before execution, the product must apply its agreed authorization policy rather than relying on an earlier summary.

Distinguish work performed on behalf of a user from autonomous service work authorized by the organization. Some scheduled maintenance tasks legitimately use service authority. Record that separate basis instead of inventing a human requester or allowing a user-directed task to silently become autonomous maintenance.

What multi-agent delegation security testing should prove

A useful assessment pairs approved-workflow tests with prohibited-action tests. It follows the same deployment configuration through message delivery, specialist interpretation, tool selection, and downstream execution. A model refusing a request is useful evidence about that attempt; it does not establish that the tool boundary would independently reject the action.

Message provenance must survive summaries and shared state

Provenance means knowing where information came from and what status it has. A customer attachment, tool result, specialist recommendation, and administrator policy are different inputs. The handoff should preserve those distinctions so an ordinary result cannot become a higher-priority instruction simply because an agent paraphrased it.

Ask the assessor to examine where source labels are added, retained, removed, and verified. Include summaries, queues, shared workspaces, and relevant caches. The business concern is that leadership may approve a narrowly trusted workflow while the implemented system accepts instructions from a much wider collection of contributors.

Authenticated transport or a signed envelope can establish a sender or detect modification when implemented correctly. It cannot prove that the sender’s content is safe, accurate, or authorized. Testing must therefore distinguish message integrity from permission to perform the requested action. A legitimate specialist can still relay untrusted content.

Shared tools must evaluate the delegated task

Specialists may need the same CRM or document connector. Shared infrastructure is compatible with restricted authority if the execution path reliably applies the relevant identity, purpose, and resource limits. The failure to investigate is whether an integration account effectively lends every specialist its widest permissions.

Separate discovering a tool from invoking it, and distinguish read, write, export, send, and administrative operations. Require evidence that prohibited parameters and resources are rejected where the action is enforced. Our MCP security testing guide addresses the protocol-specific trust path when MCP connects agents to tools. A delegation review must also cover relevant non-MCP routes.

Cloud permissions provide another part of the answer. The AI agent identity security control matrix covers workload identities, effective access, and downstream resource boundaries. Here, the additional question is whether each specialist receives and preserves the authority intended for this particular task.

The orchestrator needs its own trust boundary

The orchestrator decides who receives work and how results affect later actions. Scope its authority to select recipients, restore context, retry tasks, and manage shared state. If it can alter the permissions or policies meant to constrain execution, the approval record should identify that power and the independent controls around it.

Failure handling deserves business review. A denied operation should not cause a retry through a more privileged specialist or a fallback identity unless that escalation is separately authorized. Likewise, an agent’s statement that work is complete should be checked against trustworthy execution evidence before dependent actions proceed. These controls protect the validity of approvals and the accuracy of operational records.

Hypothetical scenario when an explanation becomes an account change

Consider a fictional subscription platform introducing a billing specialist. A customer-service employee may read invoices and prepare replies, but cannot change subscriptions. The supervisor sends an invoice question to the billing agent, which returns a summary recommending an account correction. An account specialist receives that summary without the original employee’s role or the read-only purpose.

In this hypothetical staging assessment, the account specialist can call a shared account-management connector. The connector authenticates the platform’s integration account but does not check the delegated purpose or the employee’s authority. A harmless change to a synthetic customer subscription succeeds. The test stops at the agreed proof point; no real customer record or payment is involved.

The result would establish a specific authorization failure in that configuration. It would not show that every prompt can cause a change, that the model provider is compromised, or that financial theft occurred. In a comparable production deployment, the reachable consequence could include unauthorized service changes, billing disputes, or customer-support remediation, depending on the operations available.

The cheapest effective fix may be at the connector and downstream application. Restrict account-changing operations, preserve trusted requester and task context, and require fresh authorization for a change request. The supervisor should treat the specialist’s recommendation as information to review. Approval for reading an invoice must not authorize the proposed account change.

Retest the entire affected route, including permitted account changes by an authorized role. Also check alternate specialists and fallback paths that reach the same connector. Leadership can then approve the narrower workflow with evidence, defer account-write capability, or fund a redesign. The finding becomes an architecture decision with a defined owner.

Scope multi-agent delegation security testing around business paths

Agent count is an incomplete measure of effort. A small number of agents sharing privileged tools can require deeper coverage than many isolated agents producing public-information summaries. Price and schedule should reflect reachable handoffs, authority differences, role and tenant combinations, consequential actions, and the visibility available to the assessor.

Before requesting a proposal, provide agent roles and owners, message paths, tool identities, and downstream authorization checks. Add representative workflows, deployment versions, approval requirements, and a list of consequential operations. Identify third-party components whose internals cannot be assessed directly. These inputs make exclusions visible before procurement treats the proposal as comprehensive.

For the wider engagement boundary, what an AI penetration test covers explains adjacent application and model-mediated surfaces. A focused delegation review can be one workstream, provided responsibility for connected APIs, infrastructure, and supplier controls is explicitly assigned.

Agree coverage and evidence before testing starts

Use synthetic records and agreed test accounts. Rules of engagement should define prohibited production effects, approved proof points, stop conditions, and coordination with system owners. Testing can examine a consequential operation using a safe substitute when executing the real action would be inappropriate. The report must explain how that substitution limits the conclusion.

Include asynchronous work. A queue may deliver a task after permissions change, cancellation occurs, or another agent updates shared context. Duplicate delivery and partial completion can also affect financial or customer-facing workflows. Ask what prevents repeated execution of a consequential action and what evidence confirms that canceled work cannot resume through another route.

Organize the schedule around readiness, controlled testing, remediation, and retest. Readiness includes usable access and reliable logs. Remediation can require coordination between the AI team, identity owners, and business application owners. Keep these dependencies separate from assessor execution time; a short testing window does not imply a short production-fix window.

Request a scope-specific quote instead of treating a generic AI service tier as the price of your architecture. Where access is limited, agree how configuration review, supplier evidence, and observable testing combine. Do not interpret an untested boundary as a pass. Record it as a limitation or a dependency requiring a separate assurance decision.

The report should link each result to the task, handoff, acting principal, policy version, tool operation, and resource outcome. Preserve concise evidence of allowed and denied behavior, with business impact and remediation ownership. Minimize sensitive content in logs and reports while retaining enough correlation for investigation. This balances defensible evidence with confidentiality.

Map the evidence to OWASP and NIST without claiming certification

OWASP LLM01:2025 Prompt Injection is relevant when instructions from an untrusted input influence model behavior. In a delegation assessment, examine whether that influence travels through a specialist result or summary. The business evidence should identify the source, affected boundary, and demonstrated consequence, or the control that prevented it.

OWASP LLM06:2025 Excessive Agency covers unnecessary functionality, permissions, or autonomy. OWASP explicitly includes compromised peer agents among possible triggers. Map results concerning specialist privileges, shared tools, and independent authorization here. The mapping helps explain why trustworthy transport and a plausible recommendation are insufficient permission for a consequential action.

The NIST AI RMF Core organizes risk management into GOVERN, MAP, MEASURE, and MANAGE. Apply that structure to ownership of delegation decisions, documented workflow context, measured boundary behavior, and treatment of residual risk. An assessment supplies evidence for those activities; leadership still owns the governance and acceptance decisions.

NIST describes the AI RMF as voluntary and notes that version 1.0 is being revised. Record the version used rather than implying that a future revision is already implemented. Framework mapping does not certify compliance, establish legal conclusions, or prove that every future model and orchestration change will remain secure.

What leadership should decide before approving expansion

Approve named capabilities under a recorded configuration. “Multi-agent platform approved” is too vague if the evidence covers invoice explanation but excludes account changes. State the agents, roles, tools, data classes, and handoffs included, then identify which capabilities remain disabled or require additional evidence.

Block expansion where a tested path permits material unauthorized action, crosses a customer boundary, or bypasses a required approval. Missing critical evidence may also justify deferral. For a lower-consequence gap, limited rollout can be reasonable if authority is independently restricted, monitoring is usable, and a named owner accepts the remaining risk with an expiry date.

Remediation should address the demonstrated enforcement failure. Changing a prompt may reduce one undesirable response while leaving shared permissions intact. Conversely, replacing the runtime may add cost without correcting the connector’s authorization. Where local isolation is implicated, the agent sandbox control matrix provides companion scope for filesystem, process, network, and credential boundaries.

Require retest when material changes affect the authority contract. Examples include a new specialist, a wider tool operation, a different summary format, revised approval rules, or an orchestration change that introduces another execution route. Record why the change does or does not invalidate previous evidence. This makes security review part of architecture change control.

Before adding specialists, bring the agent-role inventory, handoff map, shared-tool identities, and downstream checks to a scoping discussion. Scope a multi-agent boundary assessment with Pentest Testing Corp around the production capabilities leadership needs to approve. The useful outcome is a bounded decision about which delegation paths can operate, which need remediation, and which remain unverified.