The article argues that AI subagents should not automatically inherit their parent agent's full permissions, advocating instead for attenuated delegation with explicit scope, tool limits, and audit trails to improve security in multi-agent systems.
Subagents are usually described as a decomposition pattern. Break a task into smaller parts. Give each subagent a role. Let the parent coordinate. That framing is useful, but it misses the security problem. A subagent is not just a smaller prompt. It is a new actor. If the parent agent has access to Slack, GitHub, Jira, customer records, internal docs, and a browser, should every subagent it spawns inherit all of that? Probably not. That turns delegation into authority copying. Worse, it can become authority amplification. For Example: A parent agent is asked to investigate a customer issue. It spawns: * one subagent to search logs * one to inspect recent code changes * one to summarize support tickets * one to draft a customer response * one to check whether similar issues happened before Those are different jobs. They should not all receive the same tools, data, identity, memory, and write permissions. The ticket-summary subagent probably does not need repo write access. The code-inspection subagent probably does not need customer communication tools. The customer-response subagent probably should not query raw production logs. The “similar issues” subagent may only need read-only access to sanitized incident history. If all of them inherit the parent’s full authority, the system has not decomposed risk. It has multiplied it. The pattern I think makes more sense is attenuated delegation: parent agent authority: tools: github, jira, slack, logs, docs actions: read, write, comment, create\_ticket scope: customer\_issue\_123 duration: 60 minutes subagent authority: tools: jira actions: read scope: customer\_issue\_123 only duration: 15 minutes The parent can delegate a task, but only with a narrower capability set than it has itself. No automatic inheritance. No ambient credentials. No “same user, same session, same everything.” Each subagent should have: * its own identity * explicit tool scope * parameter constraints * data access limits * expiry * audit trail * parent/child relationship * revocation behavior * memory boundaries This also makes incident review less useless. Instead of seeing: > You can see: > That is much closer to something a security team can reason about. The obvious downside is complexity. You probably do not want to build a full IAM system for every tiny helper prompt. But for subagents that can touch high-consequence tools, code, production data, customer messages, payments, tickets, credentials, deployment systems, full inheritance seems like the wrong default. A few questions I’m trying to reason through: * Are people building multi-agent systems already scoping subagent authority separately, or do most frameworks just pass down the parent context/tools? * Do current agent frameworks make this easy, or does it require custom orchestration? * Should subagents have separate identities, or is parent identity + delegated scope enough? * What is the minimum practical control here: tool allowlists, parameter constraints, time-bound scopes, or separate credentials? * Where should revocation happen if a parent agent is stopped: should all child agents and queued child tasks die automatically? * Has anyone seen this become a real issue in production, or is it still mostly a design concern? My current bias: subagents should receive less authority than the parent by default. Delegation should attenuate authority. It should not clone it.
The article argues that the key issue with AI agents is not their capability but their scope of action, suggesting a graduated permission system based on risk rather than full autonomy from the start.
The article argues that granting broad tool permissions to AI agents is an inadequate abstraction for production environments, suggesting more granular control is needed.
The article argues that AI agents should have different permission levels based on risk, with more autonomy for low-risk tasks and approval required for actions involving money, customers, or reputation. It questions whether users would trust agents more with risk-based autonomy.
The article argues that as AI agents autonomously perform actions in shared workspaces, clear attribution of each action to both the agent and the accountable human is necessary for oversight and trust. Without proper identity and audit trails, teams cannot safely delegate more complex tasks to agents.
The author argues that successful AI agent products require a robust permission system with read-only, draft, approval, limited execution, and audit layers, prioritizing safety over apparent magic.