When Untrusted Content Tries to Become Authority
The coding-assistant scenario makes the identity-and-authorization model concrete. It asks whether a planner can coordinate a document reader and a coding agent without giving either one more authority than the task requires, especially when a document contains hostile instructions. The useful judgment is narrow but important: untrusted content may influence an agent’s reasoning, but it must not create a new identity, delegation, scope, or permission at the tool boundary.
Separate the work before the content arrives
The research paper describes an enterprise coding assistant that works across shared documents and source repositories. A developer may have permission to view a project’s design material and the rights needed to commit changes. A planner agent coordinates the task. It can ask a document-reading agent to retrieve and analyze requirements, then ask a coding agent to prepare or submit a change. These agents collaborate, but collaboration does not mean they should share one broad authority.
The first design decision is to separate the delegations by purpose. The developer can delegate document-view authority to the reader agent, with conditions that identify the relevant project or organizational context. The planner can receive enough authority to coordinate the task and can create a narrower relationship for the reader. A repository-writing delegation can be issued separately to the coding agent. The document reader does not receive repository access merely because it can communicate with the planner, and the planner does not automatically inherit every permission that the developer has.
This division gives each agent a different envelope. The reader’s envelope covers the documents needed for analysis. The coding agent’s envelope covers the repository operation that the developer has authorized. The planner’s envelope covers whatever coordination actions are explicitly permitted. If one agent is compromised or misled, the effect is bounded by the relations attached to that agent rather than by the full set of the developer’s credentials.
The sequence also preserves attribution. When the reader opens a design document, the record can identify the reader agent and the delegation path that permitted the view. When the coding agent attempts a repository write, the record can identify that agent and the distinct path that permits the write. The human remains the source of the underlying authority where the model requires it, but the human is not substituted for the actor that performed each operation.
A purpose-bound delegation is more than a comment in a prompt. It has to become a relation that the authorization system can inspect. The policy needs to know which agent received it, which human permission is its root, which resources and actions it covers, and whether the agent may delegate onward. If those terms exist only in the planner’s reasoning, the system cannot use them to stop an action that the planner should not have requested.
The boundaries should be decided before the agents consume the content that will shape their plans. The human or organization owns the underlying resource permission. A trusted authorization component records the delegation facts. The planner owns coordination, not an automatic copy of the human’s access. The specialized agents own their own requests and sessions. The resource service owns the final side effect. This allocation prevents a message such as “the planner asked me to do it” from becoming a substitute for a valid delegation path.