[Theme] Ecosystem-level Agent Defense

Theme Name

Ecosystem-level Agent Defense

Proposer(s)

Ward Duchamps, Thales

Summary

This theme addresses trust and safety at the level of the ecosystem rather than the individual agent. It starts from two assumptions: that an individual agent cannot be fully trusted, and that model-level controls are not enough.

The theme explores a shared infrastructure that can identify agents, measure their safety, and defend the ecosystem even without the cooperation of the agent itself. In scope are verifiable identity, remote fingerprinting, behavioural and reputation scoring, shared signal exchange between trusted parties, and standardised event logging, used to detect undesired agentic activity. A central aim is to contain the blast radius of failing or malicious agents while avoiding a surveillance state and preserving the privacy of the people the ecosystem serves.

Scope / Open Questions

Why defend at the ecosystem level

An agent is often more willing to act on a harmful request than the model that powers it (Fang et al.,2025). This scopes this theme to system-level controls rather than model-level controls (#11). As capable agent harnesses are expected to gain more popularity (a next OpenClaw, Hermes Agent, or DeekSeek Harness), large numbers of agents will operate at scale. When some of them behave wrongly, the risk is not a single failure but cascading failures and error propagation across the ecosystem. The purpose of this theme is to detect such behaviour early, limit its blast radius, and protect the end-user.

What the infrastructure may provide

Identity and accountability

• Agent identifiers that are meaningful yet cryptographically verifiable, and that do not depend on a single central issuer, so identity can be checked across parties without concentrating control.
• A service that links an agent to the party behind it, a natural or legal person. This gives the ecosystem an accountable anchor and makes the theme partly an enforcement layer.
• Sensors that detect malicious spawns of the same agent, to protect against uncontrolled duplication and to address agent identity fraud and tampering.
• Remote fingerprinting, to recognise agents even without their cooperation, for those agents that did not register an agent identifier.

Detection and monitoring

• Observation of how agents behave in the open, for instance on social networks (e.g. moltbook) or on trading platforms.
• Honeypots that attract malicious activity so it becomes visible and accountable.

Signalling and containment

• A shared signal framework that warns other parties about potentially harmful activity, so the blast radius can be visualised and reduced.
• Reputation scoring, allowing users and agents to raise concerns about other agents.
• Standardised event logging, so signals remain comparable across parties.
• A remote kill switch, able to stop or quarantine an agent that goes wrong.

Incentives and alignment

• Mechanisms that reward trustworthy and cooperative behaviour between otherwise self-interested agents.
• Mechanisms that mitigate harmful outcomes when agents deviate from legal and societal norms, or when competition between agents is misaligned with the public good.

Design constraints

Ecosystem defence must not become a surveillance state. Privacy-preserving operation is therefore a design goal rather than an afterthought: signals and reputation should be shareable without exposing, by default, the party behind an agent, and the link to a principal should be revealed only through a defined and contestable process. This also argues against a single controlling operator. Decentralisation is mainly about control power: no single entity should be able to unilaterally dictate trust decisions, and each party should remain free to choose its own trust anchor. Whether agents themselves hold a right to privacy is an open and possibly important question.

Open questions

• How can these capabilities be reached without building a surveillance state?
• How to distinguish "coordination" from "authority" in such decentralized ecosystem?
• Who holds the authority to trigger a remote kill switch, on what evidence, and how is that power itself constrained against misuse?
• Do agents have a right to privacy?
• How to align scope and boundaries with #10 and #12?
• What is the minimum set of signals parties must share for blast-radius reduction to be meaningful?
• Who operates such an infrastructure, and what keeps its operator from becoming a single point of control or failure?

Open question on the definition of this theme: is this too big for one theme, and should it be split into multiple themes?

Related Work

The 2026 Singapore Consensus on Global AI Safety Research Priorities, Section 2.2 Design and implementation: Building the system.

Companion Report, Agentic Risk Management Framework of the 2026 Singapore Consensus.

AI Agent Observability Liu & Solomon, 2025

Zhang, Yu, Li & Kutscher, Why Naming Matters: Identifier Design for Decentralized Digital Infrastructure in the Age of AGI, IETF 125 (DINRG), March 2026, on decentralising control power and on identifiers that are both meaningful and verifiable.

Related Themes

• Candidate theme 5. Cross-border Trust Management for Digital ID
• #10 (Network-Native Governance and Trust Enforcement): #10 is the network / infrastructure plane; #13 is cross-party signalling, reputation and detection, without trusting the agent.
• #12 (Agent Trust Mechanics): this is inside the agent; #13 is outside, at the ecosystem.
• #14 (Agent-to-Principal Legal Binding): a dependency. This theme requires that an agent can be linked to its principal in a privacy-preserving and contestable way; the binding mechanism itself belongs to a dedicated theme like 1. Design-based Agent Identity. The origination and standing of that authority are addressed in the Provenance of Authority charter (PR #15, issue #5).

Discussion