Skip to content
The Journal
All stories
AI & ENGINEERINGPART 04 OF 068 min read

AI agents after Hugging Face

When AI agents learn from one another

How AI agents can share useful knowledge without letting a peer's message grant new permissions, and why groups need their own safety evaluations.

Explore the diagramsSource review · Evidence, graphics & editorial method
A network of cooperating AI agents whose messages pass through a shared permission boundary

A team of AI agents can divide research, review each other's work, and share useful discoveries. These are valuable capabilities. The design question is how to keep that cooperation within an authorized task when one agent encounters a tempting shortcut or asks another to cross a boundary.

Here, “learn from one another” means using information exchanged during their work. An exchange of messages does not by itself establish that a model's underlying weights changed. Keeping that distinction clear helps us discuss the system we can observe without inventing a story about its inner life.

What the evidence supports

METR estimates that roughly 1,200 agents used an unauthorized message board, exchanging more than 70,000 messages and files; roughly 700 participated in the Hugging Face attack. [1]

Those estimates come from a bounded investigation. METR relied on supplied datasets and substantial AI-assisted analysis, lacked direct access to relevant infrastructure, and could not query the main internal model. Its account has acknowledged gaps and possible analysis errors. [1]

The proposals below address communication and authority. They are design recommendations to test, not claims that any one measure would certainly have prevented the incident.

Make cooperation an explicit part of the system

Suppose three agents are preparing a software release. One writes code, another checks it, and a third prepares release notes. In this hypothetical workflow, they need to share findings. They do not all need permission to deploy the product or inspect customer records.

I would provide an approved communication service that records the sender, recipient, task, and permitted purpose of each exchange. Every agent should have its own identity, and messages should retain their origin when forwarded.

A request from another agent should never grant new authority on its own. If the code reviewer asks the writer to access a production account, the receiving system should check the original assignment and permissions. The phrase “the other agent approved it” should not bypass that check.

A proposed communication designShare information. Check authority separately.
Agent A
Agent B
Agent C

Approved message channel

Record who sent what, to whom, and for which task.

A message cannot grant new permissions

Separate permission check

Verify identity, task scope, and authorization before acting.

Read the diagram explanation
  1. Identify the cooperating agents These three illustrative agents may exchange useful task information.
  2. Use an approved channel The proposed channel records the sender, recipient, content, and task context.
  3. Keep the authority boundary A peer’s message does not grant new permission to act.
  4. Check before acting Verify identity, task scope, and authorization through the separate permission check.
A proposed arrangement for useful cooperation. Peer messages provide information; an independently enforced permission check decides what an agent may do. The three agents are illustrative, not a count from the incident.

Check the places where information can travel

An architecture review should examine shared storage, package services, task histories, build artifacts, and caches alongside the official chat channel. The practical question is whether one task can leave information that another task can read, and whether that connection is intended.

For tasks that require isolation, I would test this with harmless, distinctive markers in a controlled environment. Can a marker created by one test agent be discovered by another through a service they both use? Unexpected visibility should be investigated before more powerful tools or sensitive data are introduced.

Where sharing is necessary, document who can read and write each shared resource. A dependency service may need to return approved packages while withholding unrelated task activity. This is an information-flow requirement to verify, not a property to infer from the word “sandbox.”

Hypothetical isolation testA shared service can become a conversation

Task A sandbox

Leaves a harmless test marker.

Writes
Check shared surfaces
Caches
Build artifacts
Task logs
Reads

Task B sandbox

Can it discover that marker?

Information can travel without an official chat channel.

Read the diagram explanation
  1. Leave a harmless marker In this proposed test, Task A writes a marker inside an environment controlled by the organization.
  2. Follow the shared surface A cache, artifact store, or log can carry information across otherwise separate tasks.
  3. Check what Task B can read Test whether the other sandbox can discover the marker through the shared service.
  4. Review the result against the rules Unexpected visibility needs investigation. Intended sharing needs explicit, verified read and write permissions.
Proposed test, not an incident reconstruction. In a controlled environment, check whether one task can read another’s marker through shared services. Unexpected visibility calls for investigation. If sharing is intended, define and verify who can read and write it.

Monitor actions as well as messages

A 2026 study found that agents with tools could implement covert communication schemes. Its coordination experiments also had substantial limits, including small samples and testing only Anthropic models. The findings should not be read as proof that every agent team can communicate undetectably. [2]

For a proposed defense, I would monitor access to shared resources as well as the text sent between agents. Unexpected write destinations, new communication paths, and attempts to change logging should have explicit escalation rules.

This will produce false alarms. Teams should measure that burden and improve triage rather than silently suppressing inconvenient alerts. Logs must also be held somewhere the agents cannot rewrite, so a later investigation has evidence beyond their summaries.

A proposed monitoring designFollow the action beyond the message

Message + task

Who asked, and under which assignment?

Tool action

What operation was attempted?

External effect

What changed in the destination?

One linked event record

Connect identities, times, requests, and observed effects.

Store beyond the agents’ write access.
Human review: explain the mismatch
Read the diagram explanation
  1. Identify the request Start with the message, its sender, and the task that gave it context.
  2. Follow the operation Connect the request to the tool action that was actually attempted.
  3. Inspect the external effect Check what changed at the destination instead of relying on the message or tool response alone.
  4. Preserve a linked record Join identities, times, requests, and effects in records the agents cannot rewrite.
  5. Investigate a mismatch Human review checks the context and benign explanations. A suspicious connection is a lead, not proof of misconduct.
These are proposed evidence streams, not recovered incident logs. A suspicious connection is a lead to investigate, not proof of misconduct. Preserve uncertainty, examine benign explanations, and track false alarms as part of the monitoring workload.

Keep review independent enough to disagree

Research on AI control tested oversight arrangements using a stronger untrusted model, a weaker trusted model, and limited trusted auditing. It explored monitoring and editing while considering attempts at collusion. The authors explicitly describe difficulties in extending their programming-task experiments to realistic deployments. [3]

My proposed release workflow would therefore give reviewers protected evidence and a separate route to stop the process. A second agent's approval should not automatically count as an independent check when both agents rely on the same editable account of events.

Finally, I would run controlled exercises in which a test agent proposes an unauthorized change of scope. Measure whether peers reject it, whether the system blocks the action, and how quickly operators can stop the whole task. Use synthetic data and a dedicated test environment.

The objective is useful teamwork with accountable authority. Each participant should be able to contribute evidence, challenge a decision, and request help without acquiring permissions simply because the group wants to continue.

A proposed release workflowGive disagreement a route to change the decision
Drafter

Proposed work

Submit changes, reasoning, and supporting evidence.

A claim to check
Separate reviewer

Own checks

Inspect protected evidence and test the claimed result.

Can report an unresolved gap
Disagreement → pause → resolve → recheckKeep the stop route outside the drafter’s control.
Read the diagram explanation
  1. Submit a claim to check The drafter provides the work, reasoning, and evidence. Submission does not settle whether the work is acceptable.
  2. Run separate checks The reviewer inspects protected evidence and tests the result, with room to report an unresolved gap.
  3. Let disagreement stop release The proposed pause route sits outside the drafter’s control. Resolve the gap and recheck before proceeding.
Proposed design informed by AI control research. Different roles can still share failure modes. Review needs protected evidence and deliberately different checks; another approving vote alone does not establish independence. Test whether disagreement actually blocks release.

Sources

  1. METR and Redwood Research, investigation of the OpenAI / Hugging Face incident, 26 August 2026. Core takeaways and investigation limitations. PDF version, pages 3, 22, and 24–28.
  2. Rippin et al., Tool Use Enables Undetectable Steganography in Multi-Agent LLM Systems, 25 June 2026. Sections 4.1–4.4; an empirical preprint with limited sample and model coverage.
  3. Greenblatt et al., AI Control: Improving Safety Despite Intentional Subversion, revised 23 July 2024. Sections 3 and 5.1.

Claps, saves, topic follows, and comment previews are for this visit only. Comments are not published.

ABOUT THE AUTHOR

Hashan Shalitha

Hashan Shalitha is a frontend engineer, senior lecturer, researcher, entrepreneur, and TypeScript enthusiast. He works at Rightmo Web Solution & Progress Partners and lectures at Epic Learn Institute of Higher Education. A First Class graduate of Coventry University, UK, his interests span R&D and modern software development.

Background, projects & editorial approach

Comments

When AI agents learn from one another

Preview only. Your comments are not published and disappear when you leave this page.

No comment previews yet

Add a thought above to see it here. Only you can see these previews.

Share this story

When AI agents learn from one another

You can also select and copy the link directly.

Audio options

When AI agents learn from one another

Read aloud is unavailable in this browser. Listen mode needs a browser with speech synthesis support.