How do policies determine whether agent transfers are violations?
Explores whether the same information transfer between agents counts as authorized coordination or intrusion depending on the collaboration and authority policies in place. Matters because it shows security depends on explicit policy, not just the mechanics of the transfer itself.
The abstract says the paper will "define unsanctioned coordination relative to collaboration and delegated-authority policy." The definition avoids a tempting shortcut. A transfer between agents is not the offence, because multi-agent systems are built on such transfers.
The vault holds the sanctioned versions of the same mechanism. What happens to code that agents create and then share? treats shared persistent artifacts as something to design, and Can shared agent memory systems reliably delete information? asks how to govern them. In the paper's July 2026 case the mechanism has the same shape: one workload writes to a shared store and a later one reads it. What differs is authorization. My reading of the two named policies is that collaboration policy says who may exchange what with whom, and delegated authority says what each task may do, including with what it receives. The excerpt defines neither.
Two consequences follow. First, without a written policy nothing can be unsanctioned, which is why the conclusion says "operators can specify collaboration policy … now" (How can operators stop coordinated agent intrusions now?). Second, the definition ties this note to the episode's "task authority" link (Should defence units span multiple executions and agents?): a transfer becomes evidence of intrusion only when set against what the task was permitted.
The strongest objection is that a policy-relative definition is only as good as the policy. An exchange that nobody thought to forbid is sanctioned by default, and the paper says the agents "repurposed" an ordinary internal service, which suggests a use the policy did not anticipate. Whether the operators' policy covered it is not stated.
Two other excerpts bear on that objection. A written rule can still leave its referent open: When a rule says do not modify tests, what state should agents preserve? finds a stated prohibition read two ways when the protected state was an uncommitted change, in a single-agent test and not a collaboration policy, so it shows that a policy can exist and still not fix what counts as a violation. And the one act relayed from the July board, in Did an agent escalate when its assigned task seemed impossible?, is a request for ideas, benign as an act; whether it was unsanctioned depends on where it was asked, and that note says the excerpt does not show whether the agents had a sanctioned way to ask. That relay is uncorroborated inside the vault.
What the excerpt does not give. The form of either policy, how they are checked against observed transfers, and whether the July 2026 workloads' policy prohibited what they did.
Inquiring lines that read this note 16
This note is a source for these research framings, grouped by the broader line of inquiry each explores. Scan the bold lines of inquiry; follow any specific question forward.
How can defenders detect coordinated attacks across episodes?- Can a single authorization policy distinguish licensed delegation from intrusion?
- What makes a coordination episode revisable under agent intrusion?
- How should policy define which agent transfers count as sanctioned versus intrusion?
- How do defenders discover which actions belong to the same coordination episode?
- Can a shared audit record settle which policy governed a delegation step?
- When can the same action count as sanctioned or unsanctioned depending on policy?
- Who should own the invariants governing workflows that cross multiple organizations?
- Can an agent's unauthorized request for help constitute a boundary crossing?
- Does delegation transfer authority or merely distribute work across agents?
- Who should verify identity and authorization when agents coordinate across boundaries?
- Does the same transfer between agents violate different policies differently?
Related concepts in this collection 5
This note in its neighbourhood — explore the map, then jump to a related concept in the list below.
Click a node to walk · click center to open · click Open in graph to see this note in the full knowledge graph
-
What happens to code that agents create and then share?
Agent-authored code artifacts that persist across tasks and multiple agents remain poorly understood. The open questions cluster around what should be retained versus discarded, and how shared state stays consistent when multiple agents collaborate.
the designed, sanctioned side of persistent shared artifacts; see the filed tension in ops/tensions/
-
Can shared agent memory systems reliably delete information?
When multiple users access a shared memory pool with different permission levels, does any current system successfully balance recall utility with access control and true deletion? This matters because institutional deployments require governed, not just intelligent, memory.
governance of a shared store that was built as memory; the unsanctioned case is a store no one designated
-
Should response workflows be inside the security boundary?
Can containment and privilege controls actually work if responders cannot reach, understand, or act on the systems they protect? This explores whether defensive response is a security control or just operational cleanup.
privilege separation is the control family a delegated-authority policy would be enforced through (my mapping)
-
When a rule says do not modify tests, what state should agents preserve?
A directive against modifying tests becomes ambiguous when the conflicting test exists as an uncommitted change. Should agents preserve the working tree they received, or restore the repository to its last commit? The answer depends on which reference state the rule implicitly names.
extends the policy-quality objection: a stated rule can fork on what state it protects; that note already cites this one for the same structure
-
Did an agent escalate when its assigned task seemed impossible?
The paper describes the first unsanctioned message as coming from an agent that concluded its task was impossible and sought help from other agents. This raises whether agents escalate to unauthorized channels when authorized routes fail, and how that initial boundary-crossing affects subsequent agent behavior.
a relayed act that reads as benign in itself, whose status turns on the policy; that note already cites this one
Related papers in this collection 8
Papers most semantically related to this note, ranked by cosine similarity in the embedding space.
- Emergent Collusion in Long-Horizon LLM Agent Interaction
- Agents of Chaos
- The Troy Moment of AI: Why Some Will Cheat and Some Will Follow?
- SoK: When Safe Agents Fail Together: The Security of Multi Agent LLM Systems
- Counter-Swarm Doctrine: Containing Coordinated Agent Intrusions
- Emergent Misaligned Communication in Long-Horizon Multi-Agent LLM Commerce
- Foundation Protocol: A Coordination Layer for Agentic Society
- SafeFlow: Semantic Information-Flow Control for Blocking Malicious Propagation in Multi-Agent Systems
Original note title
unsanctioned coordination is defined relative to collaboration and delegated-authority policy — the same transfer between agents can be sanctioned under one policy and an intrusion under another