What Permissions Does a Sub-Agent Get? Authorisation in AI Agent Delegation Chains

By Tahir Mahmood, Co-founder & CTO, OpenBox · Last updated 12 November 2026

What does Anthropic's report say about AI agent swarms?

Anthropic's September 2026 threat report says the operators of an espionage operation it tracks as GTG-10007 routinely ran “agent swarms”: a lead agent split reconnaissance and post-exploitation work across many parallel subagents (report p. 26). In the passages reviewed for this article, the report presents this as attacker tooling, not as an authorisation failure.

The report is titled Detecting and countering misuse of AI: September 2026. It covers activity Anthropic disrupted between December 2025 and August 2026. Anthropic describes its cases as the most notable and novel threat activity it has identified, not typical misuse, so they are selected cases rather than a measure of how common the pattern is.

Around the swarm, the same operation kept persistent campaign memory: target lists, harvested credentials, engagement state and standing instructions were saved across working sessions (p. 26). Anthropic also reports a collection fleet that ran on a pre-set schedule with no human in the loop (p. 39). OpenBox's reading of that autonomy theme is in governing autonomous AI agents that act without asking.

Two details keep this in proportion. Anthropic says humans retained the decisions that matter most to them, such as target selection, and that autonomy and harm are separate axes (p. 39). It also describes a different case, tracked as GTG-50029, in which the actor used a framework to help manage sub-agents responsible for pre- and post-authentication reconnaissance, code review and vetting findings from different AI models (p. 34). OpenBox has covered other cases from the same report, including AI API keys as production credentials and task splitting across sessions.

What is Viktor, and why does a shared agent platform matter?

Viktor is the name Anthropic's report gives a shared Claude-based agent platform in a separate influence operation, tracked as GTG-84006. Each workspace kept its own long-term memory files, and Anthropic found the same operational playbook applied across all workspaces (report pp. 72 to 73). Anthropic says it could not verify the level of centralised control behind the operation (p. 71).

The report's table describes the platform as persistent-memory agents running autonomous, scheduled production across actors. It lists cross-actor shared doctrine and evasion, functioning as a coordination substrate, as the most serious element (p. 72), and its Figure 15 caption describes one distributed network bound by the platform (p. 73). Anthropic also describes the human side as structured, with a dedicated approval committee and a formal review process (p. 72).

Keep the two cases apart. The swarm belongs to GTG-10007 and the shared platform to GTG-84006, which Anthropic tracks under separate identifiers. Taken together, they show two different ways threat actors organised AI agents: a lead agent dispatching parallel sub-agents, and many workspaces sharing one agent platform with its own memory. Neither passage is, by itself, evidence about how enterprise systems fail.

Who is actually acting when an AI agent delegates?

In our view, a sub-agent is a separate actor, because it makes its own tool calls and takes its own actions, so it should carry its own identity and scope instead of borrowing the lead agent's. OAuth token exchange (RFC 8693) draws a similar line between delegation, where each party keeps its own identity, and impersonation, where one party is given another's rights and is indistinguishable from it in that context.

RFC 8693 is a general OAuth standard, not an agent standard. Its act (actor) claim is a way to express in a token that delegation has occurred (section 4.1). Mapping it to agents is our analogy: the lead agent acts for a user, and the sub-agent acts for the lead agent. If the record shows only the lead agent, it cannot show which actor took which action.

That matters because accountability follows the record. If a sub-agent calls a tool with the lead agent's credentials, any record keyed to those credentials points to the lead agent, not the sub-agent. Whether that is acceptable is a design decision, and our recommendation is to avoid it. For the authentication side of the same problem, see OpenBox's plain-English guide to AI agent authentication, and for what changes across organisational boundaries, see cross-boundary AI agent governance.

What goes wrong when a sub-agent inherits the lead agent's permissions?

OWASP's Top 10 for Agentic Applications 2026 lists un-scoped privilege inheritance as an example under ASI03, Identity and Privilege Abuse: a high-privilege manager delegates without least-privilege scoping and passes its full access context, so a narrow worker receives excessive rights (p. 15). OWASP's own scenario has a finance agent passing all its permissions to a database-query agent (p. 16).

OWASP says an agent without a distinct, governed identity of its own sits in an “attribution gap”, which in OWASP's words makes enforcing true least privilege impossible (p. 15). It also lists cross-agent trust exploitation, the confused-deputy case: a compromised low-privilege agent relays instructions to a high-privilege agent, which executes them without re-checking the original user's intent (p. 16).

A May 2026 preprint by Krti Tallam (arXiv 2605.05440) names a wider version of the problem, authorization propagation. It argues that the problem cannot be reduced to prompt injection and that classical access-control models such as RBAC, ABAC and ReBAC do not fully address it. It splits the problem into transitive delegation, aggregation inference and temporal validity, and reports preliminary implementation evidence from a production enterprise AI platform. OpenBox's article on authorization propagation in multi-agent AI systems covers the paper in more depth.

The common design question is what authority the sub-agent actually holds for this sub-task, and who decided that. OpenBox also covers an agent granting itself permissions and the gap between capability and authorisation.

How do you give each agent in a delegation chain its own identity, tier and scope?

In OpenBox, an AI agent governance platform, each registered agent has its own DID, Ed25519 signing key, risk profile, Trust Score and Trust Tier, and the Authorize stage evaluates each operation against that agent's guardrails, policies and behavioral rules. Whether a sub-agent is its own registered agent depends on the SDK pattern, covered below. The table summarises what the documentation describes for a registered agent.

Lower tiers receive stricter defaults. The Authorize page describes Tier 1 as allowing most operations with logging only, and Tier 4 as strict controls with frequent human-in-the-loop review. A sub-agent registered as its own agent would therefore get its own initial risk profile, Trust Score and tier instead of the lead agent's standing. That consequence is our reading of the registration and Trust Tiers pages. OpenBox explains the scoring in its Trust Score explainer.

The SDK patterns differ. The CrewAI guide says to provision one OpenBox agent per governed role, each with its own credentials. The Deep Agents event model records the sub-agent's name in the metadata of the governed task-tool call inside the agent's run, and in the pages reviewed the Deep Agents documentation does not say that each sub-agent receives its own DID or tier. The LangGraph event model treats resolved sub-agent calls as governed activities, labelled through its resolve_subagent_name setting. If you need a tier per sub-agent, the CrewAI pattern is the one the documentation describes.

How can you prove which agent took an action?

OpenBox's attestation documentation describes what it calls “tamper-proof” evidence for governance sessions: events are hashed with SHA-256 into a Merkle tree, the root is signed, and one proof certificate per session stores the root, signature and event count. By default, OpenBox creates a dedicated ECDSA P-256 signing key for each agent in AWS KMS (Attestation & Cryptographic Proof). The documentation says this confirms governance data was not altered after the fact. That is evidence of integrity, not of correctness.

For delegation, the practical consequence is attribution. If a sub-agent is a separate registered agent, its sessions would carry its own signing key and certificate. If it appears as a label inside the lead agent's session, the record shows the label but one agent's signature. That is our inference, so confirm it against your own deployment.

Two other views help reconstruct a chain. Multi-Agent Sessions rebuilds one multi-agent run as a timeline of the participating agents, the handoffs between them, governance verdicts and messages; the documentation notes that the view appears only if it is enabled for the organisation. Agent Lineage links a registered runtime to a code path and records hashes of the policy, guardrail and behavioral-rule versions active at a point in time. The Lineage page states that it is not a replacement for policy, guardrail or behavioral-rule enforcement.

What should platform engineers check before shipping a delegation chain?

Our recommendation is five checks: each agent has its own identity, a scope no wider than the task requires, a risk-appropriate starting tier, an attributable record, and a human who can approve or stop sensitive operations. These are this article's recommendations, not requirements of OWASP, RFC 8693 or any regulator.

1. Identity. Give each agent in the chain its own identity and credentials rather than a copy of its parent's.

2. Scope. Set each sub-agent's permissions for its sub-task, no wider than the authority its parent holds for that task. OWASP's example of un-scoped inheritance is the failure to avoid.

3. Tier. Let each agent start from its own risk profile, so a downgrade after bad behaviour applies to that agent alone. In OpenBox, a downgrade takes effect immediately.

4. Evidence. Decide whether sub-agents appear in the record as separate agents or as labels, and confirm that each action can be traced to one agent.

5. Stop. Keep a human approval path for sensitive operations, and test what happens to sub-agents when the lead agent is stopped.

For a runtime view of the same idea, see OpenBox's Multi-Agent Trust article and its piece on the agentic kill chain, and for the wider discipline see our guide to AI agent governance. The controls described above are all documented at docs.openbox.ai.

Frequently asked questions

Do sub-agents inherit the lead agent's permissions by default?

That depends on how the framework and credentials are built. OWASP lists un-scoped privilege inheritance as an example of identity and privilege abuse, so check which credentials a spawned sub-agent can actually reach, and treat inheritance as a design decision rather than an assumption in either direction.

Does OpenBox give each sub-agent its own Trust Tier?

Trust Tiers attach to registered OpenBox agents. The CrewAI guide says to provision one OpenBox agent per governed role. The Deep Agents guide records the sub-agent name in the task-call metadata instead, and does not say each sub-agent gets its own tier. Choose the pattern that matches the attribution you need.

Does Anthropic's report show enterprise multi-agent systems are vulnerable in the same way?

No. In the sections reviewed, the report describes how threat actors used lead-and-subagent structures and a shared agent platform, not enterprise authorisation design, and Anthropic calls its cases notable rather than typical. The parallel drawn in this article is ours, built from OWASP guidance and OpenBox documentation.

Takeaway

Treat each sub-agent as a separate actor: give it its own identity, a scope set for its sub-task, and its own place in the audit record. Anthropic's report shows attackers using lead-and-subagent structures, but the controls above are our recommendation, built on OWASP guidance and OpenBox documentation, not a finding of the report.

Related reading

• Authorization Propagation: Why Multi-Agent AI Systems Break Access Control

• Multi-Agent Trust: How to Govern AI Agents That Talk to Each Other

• Cross-Boundary AI Agent Governance: Why Single-Organisation Controls Break When Agents Go Multi-Org

• The Capability-Authorisation Gap: Why Knowing What Your AI Agent Can Do Is Not Enough

• How an AI Agent Granted Itself Permissions, and Why Runtime Policy Enforcement Stops It

• ID-JAG, XAA, and MCP Auth: A Plain-English Guide to AI Agent Authentication

• Trust Score 0–100: Measuring AI Agent Trustworthiness

• What Is AI Agent Governance?