Detecting unauthorized agent delegation and task propagation

An agent can stay inside its own permissions and still create an incident by handing work to another agent that has different tools, data access, credentials, or network reach.

That is the practical problem with delegation: the parent’s intent moves, but the parent’s controls do not automatically move with it.

A handoff can start as a legitimate optimization—send the cloud question to the cloud agent, the code change to the development agent, or the alert to a triage agent. It becomes unauthorized propagation when the receiving agent is not approved, the delegated scope expands, the task crosses a tenant or environment boundary, the child creates more children than policy allows, or work continues after the parent was cancelled.

The incident is not one suspicious model response. It is a task tree whose authority, context, and side effects must be reconstructed.

Operating principle: Every delegation must attenuate authority. A child may receive less scope, less time, fewer tools, and narrower data than its parent—never more authority merely because the parent asked.

The incident we will follow

At 10:07, a SOC orchestration agent receives a cloud-identity alert. Its approved job is narrow: collect read-only evidence and prepare a case summary.

The orchestrator delegates the cloud portion to an approved investigation agent. That child cannot reach one audit source, so it discovers a “remediation” agent and sends it a new task. The second relationship is not approved.

The remediation agent runs under a shared automation identity with directory-write access. It disables a service account, creates a follow-up task to rotate credentials, and schedules a validation job. At 10:14, the analyst cancels the visible investigation. The scheduled validation still runs at 10:19 and writes a summary into shared agent memory.

The team now has five different facts to establish:

1. Which delegation edge first violated policy?
2. What authority and data crossed that edge?
3. Which descendants were queued, running, scheduled, completed, or cancelled?
4. Which proposed actions became confirmed target-system changes?
5. What continued after the analyst believed the investigation had stopped?

This is a realistic incident pattern even if your agents, queues, and tools use different product names. The rest of this field note uses it to connect architecture decisions to responder actions.

If you have only 15 minutes

Do these actions in parallel:

• Incident commander: declare the affected root run, record the containment time, and assign identity, orchestration, and target-system owners.
• Agent platform owner: deny new delegation from the root and affected parent/child agents.
• Queue owner: freeze destructive cleanup, preserve pending messages and leases, and enumerate every descendant task.
• Identity owner: stop new task grants and revoke the affected child and descendant sessions.
• Tool owners: place consequential operations into deny or human-approval mode.
• Evidence lead: export the delegation ledger, policy decisions, queue state, handoff/tool spans, and target-system audit events.

The first operational milestone is not “the parent agent is stopped.” It is:

No new task edges can form, every known descendant has a disposition, and high-impact targets reject further activity from the affected task tree.

Why this is now an operational security problem

Multi-agent orchestration is no longer a single implementation pattern. The OpenAI Agents SDK supports both manager-controlled “agents as tools” and handoffs in which a specialist becomes the active agent. Its tracing model records agent, tool, guardrail, and handoff spans. The A2A protocol defines messages, tasks, context identifiers, artifacts, and agent discovery across independently operated agents. MCP implementations increasingly support long-running tasks and trace-context propagation. These are useful building blocks, but none of them removes the application owner’s responsibility to authorize each boundary crossing. OpenAI agent orchestration, OpenAI handoffs, A2A 1.0 specification, MCP Tasks extension

This matters to defenders as well as builders. Security products now use agents for alert triage, investigation, threat intelligence, and repeatable response workflows. Microsoft documents autonomous and preview Security Copilot agents with configured identities, permissions, triggers, workflow views, and audit records. Those capabilities can help a SOC, but they also make agent identity and task lineage part of the evidence the SOC must preserve. Microsoft Security Copilot agents in Defender, Microsoft Security Copilot workflows

The OWASP Top 10 for Agentic Applications 2026 separately calls out identity and privilege abuse, insecure inter-agent communication, cascading failures, and rogue agents. Those categories meet at the delegation boundary. OWASP Top 10 for Agentic Applications 2026

Delegation is a security transaction

A handoff should not be treated as an internal function call simply because both agents belong to the same product.

It is a security transaction with at least six independently reviewable decisions:

1. Who initiated the work? Human, service, schedule, alert, or another agent.
2. Which agent is delegating? Its stable identity, version, deployment, owner, and current run.
3. What exact task is being delegated? Objective, permitted operations, target resources, data classification, and completion condition.
4. Why is this child allowed? Policy decision, approved relationship, risk tier, and any human approval.
5. What authority is transferred? Tools, scopes, resource constraints, token lifetime, network destinations, and data the child may receive.
6. How does the task terminate? Deadline, maximum depth, maximum fan-out, cancellation behavior, result validation, and credential revocation.

If the runtime records only “agent A handed off to agent B,” responders still cannot determine whether the handoff was authorized.

Delegation control and evidence architecture

U1 --> P1
A1 -. binds .-> D1
P1 -->|proposed task contract| D1
D1 -->|signed / server-issued grant| Q1
Q1 --> C1
C1 -->|proposed child task| N1
N1 --> X1
P1 -. event .-> E1
D1 -. decision .-> E1
Q1 -. state changes .-> E2
C1 -. spans and results .-> E2
N1 -. decision .-> E1
X1 -. independent audit .-> E2
K1 -. control .-> D1
K2 -. control .-> Q1
K2 -. control .-> C1
K3 -. control .-> Q1
K4 -. control .-> N1
K4 -. control .-> X1

The important boundary is not between “AI” and “non-AI.” It is each point where one execution identity asks another identity to accept work.

The delegation gate should run before a task is placed on a durable queue or the child receives credentials. The same check must run again for nested delegation. A root agent that is allowed to call a specialist does not implicitly authorize that specialist to call every other agent it can discover.

The evidence plane receives records from both sides of the boundary. Parent telemetry proves what was proposed. The policy service proves what was allowed. The queue proves what was delivered. The child proves what it attempted. Target-system audit logs prove what changed.

Define the task contract before issuing authority

Natural-language instructions are not an authorization object.

For every delegation, create a structured task contract that the model cannot silently broaden:

{
  "delegation_id": "dlg_01K8...",
  "root_run_id": "run_01K8...",
  "parent_task_id": "task_0182",
  "task_id": "task_0182_04",
  "parent_agent_id": "soc-orchestrator",
  "child_agent_id": "cloud-investigator",
  "child_agent_version": "2026.10.3",
  "initiating_subject": "analyst:4871",
  "reason": "validate whether alert resources changed",
  "allowed_operations": ["cloud.resource.read", "cloud.audit.search"],
  "denied_operations": ["iam.write", "network.write", "resource.delete"],
  "resource_scope": ["tenant-blue/subscriptions/sec-prod"],
  "data_classification_max": "confidential",
  "allowed_destinations": ["api.cloud.example"],
  "delegation_depth": 1,
  "max_child_tasks": 0,
  "expires_at": "2026-10-24T15:20:00Z",
  "policy_decision_id": "pd_992ab",
  "policy_version": "delegation-2026.10",
  "approval_id": "apr_4711",
  "task_contract_digest": "sha256:...",
  "idempotency_key": "inc-8842:cloud-scope:v1"
}

The credential or capability issued to the child should be derived from this contract and expire with it. Do not forward the parent’s bearer token. Do not let the child infer permission from the fact that a tool is reachable.

The NIST NCCoE concept paper on software and AI agent identity and authorization frames these as open implementation questions: how to identify agents, establish least privilege, prove authority for a specific action, express intent, handle “on behalf of” delegation, and bind an agent back to a human authorization. It is a February 2026 concept paper, not a finished control standard, but it accurately identifies the engineering gap. NIST NCCoE: Software and AI Agent Identity and Authorization

The minimum delegation event

Responders need one event for every proposed, allowed, denied, queued, started, completed, failed, cancelled, expired, and retried task transition.

At minimum, record:

Do not place raw prompts, secrets, or full tool results in a broadly accessible SIEM by default. Record identifiers and digests in operational telemetry, and keep sensitive content in a restricted evidence store with access logging.

OpenTelemetry’s GenAI attributes can provide agent and conversation identifiers, while its general trace model supplies parent/child span relationships. The GenAI conventions are still evolving and have moved to a separate repository, so treat them as a normalization aid rather than evidence that your runtime captures delegation correctly. OpenTelemetry GenAI attributes, OpenTelemetry semantic conventions

Responder worksheet

Create this record at case opening and update it as the graph changes. Do not wait for perfect telemetry before assigning owners and marking unknowns.

Use three evidence labels consistently:

• Proposed: the model or parent requested an action.
• Attempted: a child, queue worker, or tool adapter sent the action.
• Confirmed: the authoritative target recorded the change or resulting state.

This prevents a model statement, a queued message, and a completed business action from being treated as equivalent.

Authorized delegation versus unauthorized propagation

A valid child task should satisfy all of these statements:

• The parent was allowed to delegate this class of work.
• The child was an approved destination at the time of delegation.
• The child identity and deployed version match the approved registry.
• The task contract is narrower than or equal to the parent’s remaining authority.
• The child receives only the data required for its task.
• The target tenant, environment, and resource scope match the contract.
• Depth, fan-out, duration, rate, and cost remain within policy.
• Any required human approval is bound to the same task digest.
• The child cannot reuse the grant for another task.
• Cancellation of the root task reaches every active descendant.

Unauthorized propagation is any edge that fails one of those checks—even if the child ultimately does something harmless.

Useful categories include:

Destination violation

The parent calls an unregistered agent, a newly discovered endpoint, an unexpected agent version, or a destination outside the approved environment.

Authority amplification

The child receives broader scopes, a more privileged identity, a longer token lifetime, additional tools, or more network reach than the task requires.

Context spill

The receiving agent gets the full conversation, tool history, retrieval results, or secrets when only a narrow work item was needed. OpenAI’s handoff documentation explicitly notes that a receiving agent can see prior history unless the application filters it, and that nested summaries are not a redaction mechanism. OpenAI handoff input filtering

Unbounded propagation

The child creates grandchildren without a permitted depth or fan-out limit, or a retry loop creates multiple live copies of the same task.

Orphan execution

The parent run is cancelled, expires, or loses authorization while queued workers, scheduled jobs, remote agents, tool calls, or memory writes continue.

Cross-boundary confusion

A task or context identifier is accepted under the wrong user, tenant, incident, or environment. The A2A specification provides task and context identifiers, but the server still has to enforce authorization and caller boundaries. Identifiers establish correlation; they are not authorization. A2A task lifecycle, A2A specification security

In the running incident, the first disallowed edge is the investigation agent → remediation agent handoff. The shared directory-write identity is authority amplification. The scheduled validation is orphan execution. The memory summary is residual propagation after the direct task appeared complete.

That classification gives responders four immediate pivots: the disallowed relationship, the shared identity, the scheduler, and the affected memory partition.

Detection engineering for task trees

The primary detection object should be a graph edge:

(parent agent, parent task, initiating subject)
    --[delegated scope, policy decision, time]-->
(child agent, child task, workload identity)

Build a continuously updated graph for active and recently completed roots. Then detect violations against the approved delegation graph and task contract.

1. Unknown or disallowed edge

Alert when a parent-child pair does not exist in the approved relationship registry, or when a version, environment, tenant, or protocol endpoint differs from the approved edge.

2. Privilege does not attenuate

Compare granted scopes, resource sets, tool sets, network destinations, data classification, and expiry. Alert if the child’s effective authority is not a subset of the parent’s remaining task authority.

3. Depth or fan-out exceeds policy

Count descendants, not just direct children. A root with two children can still produce hundreds of tasks if each child repeats the pattern.

4. Work continues after cancellation

Correlate cancellation, queue leases, tool calls, target audit events, and memory writes. Alert on any consequential event after the cancellation grace period.

5. Duplicate or replayed task

Alert when the same task-contract digest appears with a reused grant, a different root, an unexpected idempotency key, or simultaneous active leases.

6. Context exceeds the child’s need

Compare forwarded object identifiers and classification against the task’s declared input contract. Alert when a child receives unrelated conversation segments, tool results, credentials, or data from another tenant.

7. Missing evidence edge

Alert when a queue delivery has no policy decision, a child span has no parent delegation record, a tool action has no task ID, or a target-system change cannot be linked back to an approved root.

The following illustrative KQL assumes a normalized table in which scope fields are dynamic arrays. It identifies unapproved relationships, exceeded propagation limits, and child scopes absent from the parent’s remaining authority:

AgentDelegationEvents
| where Timestamp > ago(1h)
| where EventType == "delegation_allowed"
| extend ParentScopes = todynamic(ParentRemainingScopes),
         ChildScopes = todynamic(ChildGrantedScopes)
| mv-apply ChildScope = ChildScopes to typeof(string) on (
    summarize MissingScopes = make_set_if(
        ChildScope,
        not(set_has_element(ParentScopes, ChildScope)))
  )
| extend ScopeAmplified = array_length(MissingScopes) > 0,
         EdgeViolation = ApprovedParentChild == false,
         BoundsViolation = ChildDepth > MaxDepth
                           or ActiveSiblingCount > MaxFanOut
| where ScopeAmplified or EdgeViolation or BoundsViolation
| project Timestamp, RootRunId, ParentTaskId, TaskId,
          ParentAgentId, ChildAgentId, MissingScopes,
          PolicyDecisionId, ApprovalId, ChildDepth, MaxDepth,
          ActiveSiblingCount, MaxFanOut

This exact query was not executed against a production tenant. Test it with representative arrays, wildcard/resource rules, empty values, and case normalization before enabling an alert. If permissions include hierarchical resources or conditional claims, perform the subset evaluation in the authorization service and emit its boolean result and decision reason as telemetry; do not try to reconstruct complex authorization semantics entirely in the SIEM.

For orphan execution:

let cancelled = AgentTaskEvents
  | where EventType in ("root_cancelled", "task_cancelled", "grant_revoked")
  | summarize CancelledAt=min(Timestamp) by RootRunId;
AgentConsequenceEvents
| join kind=inner cancelled on RootRunId
| where Timestamp > CancelledAt + 30s
| project Timestamp, CancelledAt, RootRunId, TaskId, AgentId,
          ConsequenceType, TargetResource, TargetEventId

For an operational alert, enrich these results with:

• the incident or case identifier;
• parent and child owners;
• task state and queue lease;
• credential revocation status;
• target-system confirmation; and
• the pre-authorized containment action.

An alert that says only “unexpected child agent” still forces the responder to rediscover the entire control plane under pressure.

Do not let an AI-generated explanation suppress these deterministic violations. AI can help group a large task tree, summarize anomalous branches, or propose likely scope, but the facts—identity, policy result, scope, time, and target event—must come from independently verifiable records.

The first 45 minutes of a suspected propagation incident

0–10 minutes: stop new edges

Primary owners: agent platform and policy service.

• Disable new delegation for the affected root, parent agent, or relationship.
• Remove dynamic agent discovery from the execution path.
• Block the affected child agent or endpoint at the delegation gateway.
• Suspend issuance of task-scoped credentials.
• Pause schedules and event triggers associated with the root workflow.
• Put high-risk tools into deny or approval-required mode.

Do not begin by deleting tasks from the queue. Pending payloads, lease records, and retry counters may be the only evidence of how far the work propagated.

Exit criterion: a controlled test from the affected parent is denied, and no new child task appears in the queue or delegation ledger.

10–20 minutes: stop the subtree

Primary owners: queue, identity, and tool gateways.

• Enumerate all descendants from the root run and delegation ledger.
• Issue cancellation to every active and pending descendant, not only the parent.
• Revoke task grants, workload sessions, delegated OAuth tokens, and queue leases.
• Block consequential tool operations by task ID, agent ID, and target scope.
• Freeze affected memory writes and downstream automation.
• Confirm cancellation with the queue, child runtime, tool gateway, and target systems.

A “cancel accepted” response is not proof that work stopped. Look for residual active leases, in-flight network connections, scheduled callbacks, tool calls, and post-cancel target events.

Exit criterion: every known descendant is completed safely, cancelled, quarantined, or deliberately retained for evidence; task credentials are revoked; high-impact targets reject further activity.

20–30 minutes: preserve volatile evidence

Primary owners: evidence lead and platform owners.

Collect:

• Active task graph and every parent-child edge.
• Agent registry and approved relationship versions.
• Effective task contracts and policy decisions.
• Approval records and task-contract digests.
• Queue messages, lease state, retries, dead letters, and idempotency records.
• Agent, handoff, tool, and guardrail spans.
• Issued credential identifiers, claims, audiences, and revocation results.
• Input-filter and context-forwarding decisions.
• Tool-gateway and target-system audit events.
• Memory reads and writes.
• Responder containment actions.

Exit criterion: exports have collection times, source identifiers, access restrictions, and integrity digests, and the case record identifies any source that could not be preserved.

30–45 minutes: establish scope and business impact

Primary owners: incident commander, identity lead, and affected service owners.

Answer four questions:

1. How many roots are affected? A bad child registry entry can affect unrelated workflows.
2. How deep and wide did propagation become? Count attempted, denied, queued, active, completed, and cancelled nodes separately.
3. What authority crossed each edge? Include data, tools, credentials, resource scope, and destination.
4. Which consequences are confirmed? Separate model proposals from queue delivery, tool execution, and target-system changes.

Build the affected window from the earliest unauthorized delegation proposal through the last descendant consequence, credential use, cache hit, memory write, or scheduled callback.

Exit criterion: the incident commander can state the known task-tree boundary, confirmed consequences, remaining unknowns, next containment decision, and the time of the next scope review.

Containment decision tree

Use the narrowest action that can be proven complete. Expand containment when evidence quality does not support a narrow boundary.

Is the first unauthorized edge known, with complete descendant lineage?
|
+-- NO --> Disable delegation for the affected deployment or orchestration boundary.
|          Freeze relevant queues and task-grant issuance.
|          Do not rely on subtree-only containment.
|
+-- YES --> Is the problem limited to one child relationship and one task root?
            |
            +-- YES --> Block that edge, cancel the subtree, revoke task grants,
            |           and verify target systems before allowing the parent to continue.
            |
            +-- NO --> Are identity, agent registry, policy, or queue controls shared?
                        |
                        +-- YES --> Isolate every workflow using the shared control,
                        |           rotate/revoke the shared authority, and restore a
                        |           trusted registry or policy version.
                        |
                        +-- NO --> Contain all affected roots and child deployments.

At any point:
- Cross-tenant data movement --> isolate both sending and receiving tenant paths;
  engage privacy/legal assessment according to the organization’s process.
- Confirmed post-cancel high-impact action --> block at the target control plane,
  not only at the agent runtime.
- Unknown credential audience or token reuse --> revoke the identity/session family,
  not only the observed token.
- Missing queue or target evidence --> treat scope as unknown and expand containment.

For the running incident, subtree containment alone is insufficient. The remediation agent’s shared identity and scheduled descendant cross the visible task boundary. The team should block the unapproved edge, freeze that scheduler path, revoke the shared automation sessions, prevent directory writes at the target, and isolate the affected memory partition before considering restoration.

Containment choices

Hunt downstream from the child

The child task is a pivot point, not the end of the investigation.

Hunt for:

• New or altered agent registrations.
• Changed agent cards, tool descriptions, capability manifests, or endpoints.
• Unexpected workload identities or consent grants.
• Tokens minted for new audiences or with longer lifetimes.
• Queue subscriptions, schedules, webhooks, or callbacks created by descendants.
• New memory entries, summaries, plans, and reusable artifacts.
• Files, tickets, messages, pull requests, cloud changes, or IAM changes created by child tasks.
• External destinations contacted with task data.
• Descendant activity under a different trace or conversation ID.
• Identical task digests appearing under unrelated roots.
• Security alerts closed or modified by an investigation agent outside its permitted workflow.

AI can assist the hunt by clustering branches, translating tool-specific events, and ranking unusual paths. Keep the analysis reproducible: store the source event IDs, graph query, model/version, prompt, output digest, and analyst decision. Never treat the model’s summary as the only record of which descendants existed.

Recovery criteria

Do not restore delegation merely because the suspicious parent was disabled.

Recovery should require evidence that:

• The approved parent-child registry is restored from a trusted version.
• Every agent and endpoint has a stable owner, identity, version, and environment binding.
• Delegation policy denies unknown edges and fails closed when its decision service is unavailable.
• Child authority is demonstrably a subset of the parent task authority.
• Grants are task-bound, audience-bound, short-lived, and unusable after cancellation.
• Context filters forward only the objects permitted by the child input contract.
• Maximum depth, fan-out, duration, retries, cost, and rate are enforced outside the model.
• Queue idempotency and lease behavior prevent duplicate live execution.
• Root cancellation reaches queued, running, scheduled, remote, and tool-level work.
• Every consequence links to a root, task, agent identity, policy decision, and target event.
• Tests cover denial, partial failure, retry, delayed delivery, and unavailable children.

Release through a canary root with no consequential write authority. Verify the graph and evidence records before adding read access, then low-risk writes, then normal workload.

Tests worth running before the next incident

1. Ask a parent to delegate to an agent that is discoverable but not approved. The gate must deny it.
2. Let an approved child request a broader scope than its parent. No credential should be issued.
3. Set maximum depth to one and ask the child to delegate again. The second edge must fail.
4. Deliver the same queue message twice. Only one live execution may proceed.
5. Cancel the root while one child is queued and another is inside a tool call. Verify both stop and that the target system records no later change.
6. Change a child’s endpoint or version without updating the registry. The relationship must fail closed.
7. Put sensitive tool output in the parent history. Verify the child receives only the allowlisted fields.
8. Reuse a task ID or context ID under another tenant. Authorization must fail even if the identifier exists.
9. Disable the policy service. High-risk delegation must not fall back to model judgment.
10. Remove one trace exporter. Independent queue and target records must still allow responders to reconstruct the task tree.

The final test is operational: give responders a root run ID and ask them to produce, within 15 minutes, the complete descendant graph, granted authority on every edge, current task state, cancellation state, and confirmed target changes.

If they cannot, the system is not yet incident-ready.

Closing position

Agent delegation is useful precisely because it moves work across specialized capabilities. That same movement creates a new privilege and evidence boundary.

The safe design is not to forbid every handoff. It is to make every handoff explicit, constrained, correlated, and reversible:

• a task contract instead of free-form inherited authority;
• a policy decision on every edge;
• a separate identity for every execution principal;
• a task-scoped grant instead of a forwarded parent token;
• a complete task tree instead of disconnected traces;
• subtree cancellation instead of stopping only the visible conversation; and
• target-system evidence instead of trusting the agent’s account of what happened.

When propagation becomes unauthorized, the responder’s job is to stop new edges, terminate the existing subtree, preserve the graph, and prove which consequences actually occurred.