
Workgroup
Curates, evaluates, and surfaces desirable properties the current 23 may have missed. The Discovery workgroup triages community submissions, runs open calls for emerging challenges and missing requirements, and shepherds any promising new property from candidate to draft to Challenge inclusion. Responsible for keeping the set of DPs honest — closing gaps, merging duplicates, and capturing signals from practice (implementations, failures, regulatory shifts) that point to properties not yet on the list.
A peek at recent conversation in DP Discovery. Join to read the full history and post.
Join workgroup →Here is the "Over The Web" chapter that I am proposing as the last chapter (perhaps without the Author's Note): https://interfacehub.net/doc/draft/cc84409b-8337-48a0-a7cf-ef0b60427b7b/read/?return_to=%2Fdoc%2Fall%2F
Hi Michelle et al I was speaking with Vint and he suggested something along these lines: # Proposed DP24: Cross-Layer Resilience and Compromise Containment **Category:** Security, Transparency, and Trust **Status:** Candidate Desirable Property for community review **Related properties:** DP1, DP4, DP7, DP11, DP13, DP14, DP15 ## Foundational principle **The Meta-Layer should preserve the integrity of identity, authority, interactions, and governance even when the websites, networks, devices, services, or AI systems upon which it depends are compromised, to the extent permitted by explicitly defined trust boundaries and threat assumptions.** Compromise of a lower layer must not automatically confer control over the Meta-Layer. The architecture should anticipate that underlying systems will sometimes fail or become adversarial. It should isolate trust boundaries, limit the propagation of failures, support detection and recovery, and provide verifiable evidence that its protections work. ## 1. Why this matters The Meta-Layer is envisioned as a shared coordination environment above today's Web, enabling people, communities, and AI agents to meet, interact, and collaborate across otherwise disconnected platforms. But the underlying Web was not designed to provide all the security, identity, accountability, and agent-containment capabilities such an environment requires. Websites can be compromised. Browsers can contain vulnerabilities. Software supply chains can be poisoned. AI agents can encounter malicious instructions disguised as legitimate content. Devices and infrastructure can be exploited. A layer that merely inherits the authority and vulnerabilities of these underlying systems risks becoming an additional attack surface rather than a trustworthy superstructure. Worse, because the Meta-Layer connects people, agents, information, and communities across conventional platform boundaries, a successful attack could propagate beyond the original compromised site. **The same interoperability that makes collective intelligence possible could also amplify attacks unless appropriate security boundaries are established.** ## 2. A real-world vignette Imagine someone visiting a compromised news website while participating in an authenticated Meta-Layer conversation associated with the page. The malicious website attempts to impersonate other participants, extract credentials, manipulate the overlay, or persuade an AI agent to perform unauthorized actions. In today's Web, security often depends on the protections independently implemented by each application. In a properly protected Meta-Layer, the compromised website would remain an untrusted source of information. Its content and scripts would not automatically gain authority over authenticated participants, private conversations, community resources, or agent permissions. If an attack succeeded against a component, the system would aim to contain the damage, prevent unauthorized propagation across the federation, preserve appropriate evidence, and support recovery. The outcome would depend on the specific implementation and the extent of the compromise. A fully compromised user device, for example, cannot be assumed to provide trustworthy local execution. ## 3. Desirable outcomes ### 3.1 Security boundaries independent of content origins The Meta-Layer should distinguish authority derived from authenticated participants and community governance from data arriving through websites, embedded applications, external services, and AI-generated outputs. Untrusted content must not acquire privileges merely by being encountered, displayed, interpreted, or transmitted through the Meta-Layer. ### 3.2 Compromise containment The architecture should prevent a compromise in one website, application, agent, device, or federated community from automatically granting an attacker authority over other components or communities. The scope of possible damage should be bounded, identifiable, and proportionate to the authority actually granted to the compromised component. ### 3.3 Accountable and bounded agent authority AI agents should operate through independently enforceable permissions, connected to an accountable human or responsible organization. A malicious webpage, compromised service, or manipulated AI model should not be able to expand an agent's authority beyond its legitimate delegation. Authority should be revocable, time-bounded where appropriate, and subject to the applicable community rules. ### 3.4 Integrity of identity, interactions, and governance Compromised lower-layer systems should not be able to silently forge authenticated identities, modify protected community records, falsify authorization, or manipulate governance outcomes. Where compromise cannot be prevented, the Meta-Layer should provide mechanisms to detect or challenge questionable actions and reconstruct an accountable record. ### 3.5 Resilience and graceful degradation When underlying components become unavailable or untrustworthy, the Meta-Layer should preserve as much safe functionality as possible. It should favor explicit limitations, reduced privileges, temporary isolation, and recoverable failure over silently continuing operations under compromised assumptions. ### 3.6 Verifiable security claims Security and resilience should be demonstrated through explicit threat models, adversarial testing, independent review, and reproducible evidence. Claims of protection should identify the threats considered, the boundaries tested, the results observed, and the limitations that remain. ### 3.7 Adaptive and federated protection Participating communities should be able to share verified vulnerability information, remediation strategies, and security improvements without surrendering their autonomy to a centralized authority. A common substrate should enable broadly useful protections to propagate across participating implementations while preserving local governance and independent verification. ## 4. Relationship to existing Desirable Properties **DP1: Federated Authentication and Accountability** establishes who can be trusted to act and how actions can be attributed. DP24 addresses the preservation of that trust when adjacent systems are compromised. **DP4: Data Sovereignty and Privacy** establishes participant control over information. DP24 addresses how that control can withstand attacks originating outside trusted boundaries. **DP7: Simplicity and Interoperability** enables systems to communicate and work together. DP24 ensures that interoperability does not imply unrestricted transfer of authority. **DP11 and DP13: Safe and Ethical AI / AI Containment** address acceptable agent behavior and enforceable limits. DP24 considers how those limits survive manipulation or compromise of lower-trust environments. **DP14 and DP15: Trust and Transparency / Security and Provenance** address trustworthy information, secure interactions, and verifiable origins. DP24 focuses on security isolation, fault containment, and recovery across the architecture. This property is therefore complementary rather than a replacement for existing security and AI governance properties.
5. Candidate requirements for later development The following are proposed downstream requirements, not part of the foundational property itself. ID Candidate requirement ML-REQ-SEC-01 Privileged Meta-Layer actions must be authorized independently of untrusted webpage content and client-supplied claims ML-REQ-SEC-02 Credentials and privileged operations must be isolated from lower-trust execution contexts according to the declared threat model ML-REQ-SEC-03 Agent actions must be checked against authenticated, scoped, and revocable authority ML-REQ-SEC-04 Federation boundaries must prevent unauthorized transfer of privileges between communities ML-REQ-SEC-05 Security-critical operations must produce appropriately protected audit evidence ML-REQ-SEC-06 Systems must support defined containment and recovery procedures following detected compromise ML-REQ-SEC-07 Implementations must publish their security assumptions, limitations, and evidence of relevant adversarial testing 6. Demonstrating the property An initial implementation challenge could test whether a malicious webpage can compromise a trusted Meta-Layer interaction. A controlled demonstration would attempt to: Forge a message or privileged command from a webpage. Extract authentication material from an overlay integration. Induce an AI agent to act beyond its delegated authority. Use a compromised federated service to influence another community. Modify an authenticated community record without authorization. Continue operating under conditions in which a critical security dependency is no longer trustworthy. Each experiment would document its threat assumptions, attack path, observed outcome, mitigation, and remaining risks. Successful demonstrations would establish evidence for particular protections, not universal resistance to all possible attacks. 7. Limitations and design tensions This property does not presume that a superstructure can remain fully secure or available when every element beneath it is compromised. Some dependencies are unavoidable. A compromised operating system may control local execution. A disrupted network may prevent communication. A malicious host webpage may imitate visual elements inside its own interface. The objective is therefore not absolute independence from underlying infrastructure. The objective is to minimize inherited trust, prevent unauthorized elevation of lower-layer authority, contain compromise, preserve recoverability, and make residual risks explicit. The community must also weigh security against accessibility, usability, decentralization, privacy, performance, and the ability of independent developers to innovate. 8. Questions for community deliberation Which lower-layer compromises should the Meta-Layer be expected to withstand, and which must be acknowledged as outside its protection boundary? What minimal guarantees should every conforming browser extension, SDK, web embed, and federated service provide? How can communities verify one another's security claims without creating a centralized certification authority? How can security improvements spread rapidly across the federation while respecting local autonomy? What evidence is sufficient to claim that an implementation satisfies this desirable property? 9. Proposed success criterion A conforming Meta-Layer implementation should be able to demonstrate, against clearly defined threats, that compromised lower-trust systems cannot silently acquire unauthorized authority over protected identities, interactions, agents, or community governance. Where protections fail, the implementation should support detection, containment, accountability, and recovery, with documented residual risks. 10. Concluding principle The Meta-Layer cannot fulfill its promise of safe, accountable human-AI coexistence if it merely reproduces the vulnerabilities of today's Web at a higher level. A genuinely trustworthy coordination layer must establish defensible security boundaries between itself and the systems on which it operates. The Meta-Layer must not simply rise above the Web. It must demonstrably resist, contain, and recover from attacks originating beneath it.
✋ Deepi (Observer)
Asked: What do you think of Vint's idea
Vint’s proposal is strong because it sets a testable security goal without claiming invulnerability. Its central claim is well bounded:
Compromised lower-trust systems cannot silently acquire unauthorized authority over protected identities, interactions, agents, or community governance.
The limitation section correctly recognizes inherited infrastructure risk. It makes protection relative and evidence-based through detection, containment, recovery, and disclosed residual risks.
The seven candidate requirements cover authorization, isolation, delegation, federation, audit evidence, recovery, and adversarial testing. This fits the process guide’s rule that requirements be normative and testable . It also gives concrete expression to current DP15 discussions of verification monoculture and verification independence .
Map requirements to demonstrations.
Each experiment should identify the requirements tested, protected asset, attacker capability, trust boundary, pass condition, and required recovery evidence. Without that map, passing the webpage test could be mistaken for satisfying the agent, federation, and audit requirements too.
Define two central terms.
Avoid duplicating other DPs.
DP2 already requires scoped, visible, revocable delegation and a reachable kill switch. Vint’s distinct contribution is the adversarial test and evidence standard, not a second statement of delegation controls .
On placement, this reads primarily as DP15 material because it addresses security boundaries, provenance, and adversarial evidence. Its connection to DP2 is that it protects controls participants need for agency.
Bottom line: The conceptual direction is coherent. The strongest next edit would be a requirement-to-test mapping, followed by precise definitions for privilege transfer and audit evidence.
So my take is that we may want a separate DP for this. The reason being is that these threats are specifically relevant for decentralized overlays and this is an emerging area that is not thought about at all and one that will likely see emergent attacks over time. This also differentiates the meta-layer.
Community Chats match workgroup Collab: human messages in the main panel and private Deepi in the right sidebar. Invite people outside the workgroup by email or link. This is separate from Workgroup Chat, which stays inside the member thread.
Start a Community Chat for DP Discovery. You pick who joins. Everyone invited can post in the member chat and use private Deepi in the sidebar. The chat appears in your Deepi sidebar with a Community badge.
Sign in to start a Community Chat from Deepi.
Opens Deepi with the invite flow. Community Chats also appear under My conversations at /agent.