When an AI agent delegates a task, does it also delegate its permissions?
You ask an AI agent to research a competitor. You permit it to:
Read public websites.
Analyse information.
Prepare a report.
It cannot contact anyone, send emails, or make external commitments. It delegates part of the research to another agent, which delegates again to a third agent. The third agent has access to email.
It finds a relevant person and decides that contacting them would help complete the task.
Where exactly did that permission come from?
The original user never granted it.
The first agent didn't have it.
But the task travelled through a chain of agents, each with its own capabilities.
We need to distinguish between two things that are often treated as the same:
Permission to perform a task.
Permission to delegate that task, including its possible side effects.
And this creates some interesting design questions:
Should permissions be inherited, restricted, or explicitly re-authorized at every delegation?
If an agent delegates work to an untrusted agent, should the original user's identity and restrictions follow the entire execution chain?
Who is accountable when an agent acts several delegation steps away from the original instruction?
Can we design delegation systems where capabilities are composable without letting authority expand silently?
We want agents to delegate freely because that's what makes multi-agent systems useful. But how do we prevent delegation from becoming an unintended way of escalating privileges?
Replies
I hit a small version of this. There is an account on my machine that no agent may ever use for my project, and the rule is written about the account, not about any agent or tool: no signing in as it in a browser, a command line tool, a mail connector or a generated sign in link, and if a tool turns out to be signed in as it already, the session stops and tells me. Writing it per account rather than per tool is what lets it survive delegation, whichever agent ends up holding the tool, the account is still off limits. Your chain is exactly the case a per tool rule misses: each link looks allowed on its own.
@gbasovv That's a really interesting distinction. You're essentially making the restriction invariant across the entire execution chain, rather than relying on every agent or tool to independently remember it.
I particularly like the point about an already-authenticated session. Preventing an agent from signing in is one thing. Detecting that a tool is already operating under a restricted identity is a different problem.
It makes me wonder about one more layer: how do you handle derived credentials or indirect access?
For ex., if an agent cannot use Account A, but another agent can access a resource that was obtained through Account A, should that restriction propagate to the derived resource as well?
At some point, this starts looking less like a permission system and more like tracking the provenance and authority of every action.