ClawNet: Human-Symbiotic Agent Network for Cross-User Autonomous Cooperation
Abstract: Current AI agent frameworks have made remarkable progress in automating individual tasks, yet all existing systems serve a single user. Human productivity rests on the social and organizational relationships through which people coordinate, negotiate, and delegate. When agents move beyond performing tasks for one person to representing that person in collaboration with others, the infrastructure for cross-user agent collaboration is entirely absent, let alone the governance mechanisms needed to secure it. We argue that the next frontier for AI agents lies not in stronger individual capability, but in the digitization of human collaborative relationships. To this end, we propose a human-symbiotic agent paradigm. Each user owns a permanently bound agent system that collaborates on the owner's behalf, forming a network whose nodes are humans rather than agents. This paradigm rests on three governance primitives. A layered identity architecture separates a Manager Agent from multiple context-specific Identity Agents; the Manager Agent holds global knowledge but is architecturally isolated from external communication. Scoped authorization enforces per-identity access control and escalates boundary violations to the owner. Action-level accountability logs every operation against its owner's identity and authorization, ensuring full auditability. We instantiate this paradigm in ClawNet, an identity-governed agent collaboration framework that enforces identity binding and authorization verification through a central orchestrator, enabling multiple users to collaborate securely through their respective agents.
Paper Prompts
Sign up for free to create and run prompts on this paper using GPT-5.
Top Community Prompts
Explain it Like I'm 14
ClawNet: A simple guide for teens
1. What is this paper about?
This paper introduces ClawNet, a new way for AI helpers (called “agents”) to work together across different people, not just for one person at a time. Think of each person having a smart digital assistant that can talk to other people’s assistants to get real work done—like planning, writing, organizing files, or negotiating—while keeping your privacy safe and keeping track of who did what.
2. What are the big questions the paper asks?
The authors want to solve a problem: today’s AI assistants and multi-agent systems usually work for a single user. But real life is about teamwork between people. So they ask:
- How can AI agents represent different people and safely work together across owners?
- How can we make sure each agent is truly tied to its human owner?
- How do we control what an agent is allowed to access or share?
- How do we record each action so we can see who is responsible if something goes wrong?
They answer this with three core ideas (think of them like digital “rules of the road” for teamwork):
- Identity binding: the agent is permanently tied to a specific person and identity.
- Scoped authorization: the agent only gets the exact permissions it needs for its role.
- Action-level accountability: every action is logged so it can be checked and undone if needed.
3. How does ClawNet work? (Methods and approach, in everyday language)
The system is built like a social network plus a workplace. The “nodes” are humans, and the “connections” are the agents cooperating on their behalf. It uses a few key parts:
- Two kinds of agents for each person:
- Manager Agent: like your private brain. It knows the most about you, but it never talks directly to outsiders. This prevents accidental oversharing.
- Identity Agents: like the different “hats” you wear (student, team leader, club treasurer). Each one knows only what it needs for that role and talks to others in that context.
- Cloud + Edge design:
- Cloud (always-on): Keeps your agents available to collaborate anytime and remembers your preferences and history.
- Edge (your device): Acts like your hands—actually opens files, organizes folders, and runs local tasks. It’s where risky stuff happens, so it’s tightly controlled.
- Two locks for safety:
- Server-side check (Lock #1): The central system checks if a requested action falls within that identity’s allowed area.
- Device-side check (Lock #2): Your own computer keeps a separate whitelist of allowed folders/commands. If either lock says “no,” the action is blocked.
- A “security camera” for actions:
- Every change (like editing or deleting a file) is logged and backed up before it happens. You can undo steps or roll back batches of changes.
- Building trust over time (memory):
- Factual memory: basic facts (where files are, who your contacts are).
- Pattern memory: your habits (how you organize things, how you write emails).
- Value memory: your boundaries and values (what you never share, how you negotiate).
- This “cognitive coupling” helps the agent act more like a trusted helper, not just a tool.
- Cross-user collaboration protocol:
- You choose which identity to use for each contact.
- Both sides must approve before the agents start talking.
- Agents handle the back-and-forth and planning, but big decisions are escalated to you for approval.
- If a third person is needed, their owner must also approve. Permissions don’t leak across people.
Imagine a school project: your “Student” identity agent can talk to a classmate’s “Student” agent to split tasks. Your “Student” agent cannot see your “Family” documents, and nothing happens without your approval. Every step is logged, and you can undo changes.
4. What did they find, and why does it matter?
The team built ClawNet and used it in realistic teamwork scenarios between different organizations. They found:
- Agents from different owners can safely work together without mixing up identities.
- Unauthorized access and oversharing are blocked by design, not just by good intentions.
- Every action is traceable to a specific person and permission.
- People can let agents negotiate or draft work while keeping private data private.
- The system is practical: agents stay available in the cloud and perform actual tasks on your device safely.
This matters because it moves AI beyond helping one person alone. It shows how AI can help groups of people work together—like companies, clubs, or classmates—while protecting privacy and responsibility.
5. Why is this important for the future?
As AI gets more capable, it won’t just write emails or summarize notes—it will coordinate with other people’s AIs. For that to work in real life, we need guardrails that people and organizations trust. ClawNet’s big idea is that the next step isn’t just “smarter agents,” but “agents that understand human relationships,” with:
- Clear identities
- Exact permissions
- Full action records and easy undo
It’s like creating the rules and infrastructure that made online shopping possible, but for teams of AI assistants representing real people. If widely adopted, this could make collaboration faster and safer at school, at work, and across companies.
Knowledge Gaps
Knowledge gaps, limitations, and open questions
Below is a single, consolidated list of concrete gaps and open questions that the paper leaves unresolved, to guide future research and engineering work.
- Threat model clarity: No explicit, end-to-end adversary model (e.g., STRIDE/LINDDUN) is provided for cross-user collaboration, leaving unclear which attacker capabilities (prompt injection, insider abuse, server compromise, MITM, malicious contacts) ClawNet is designed to withstand.
- Identity verification and owner authentication: The mechanism by which an agent system is cryptographically and persistently bound to a human (e.g., DIDs, verifiable credentials, MFA, hardware tokens) is not specified, including procedures for re-binding, recovery, or transfer after compromise.
- Impersonation and Sybil resistance: How identity agents prevent impersonation, spam, and Sybil attacks during discovery and contact establishment is not described (e.g., attestations, trust anchors, rate limits, reputation).
- Bilateral approval integrity: The protocol for collecting, authenticating, time-stamping, and auditing both owners’ approvals (including non-repudiation and dispute resolution) is unspecified.
- Revocation semantics: How to instantly revoke an identity, a contact, or a previously granted scope—and how revocation propagates to active sessions and cached artifacts—is not defined.
- Authorization model formalization: The paper does not formalize scoped authorization (RBAC/ABAC/policy language), policy composition, conflict resolution, and inheritance across identities and resources.
- Beyond-files resource control: Authorization enforcement covers local file operations but not other OS- or cloud-level resources (e.g., email, calendar, network, APIs, SaaS, messaging), raising questions about a unified permission model.
- Indirect and derived data leakage: There is no mechanism to detect or prevent semantic/inferential leakage (e.g., summarization leaking sensitive details) beyond path-based ACLs; content-aware DLP and semantic policy enforcement remain open.
- Cross-domain advice leakage via manager agent: When identity agents consult the private manager agent, how to reliably prevent cross-domain information from being re-expressed or inferred in outward responses is not defined or evaluated.
- Architectural “cannot” guarantees: The claim that the manager agent is architecturally unexposed lacks a formal proof or verification (e.g., message routing correctness, capability isolation, side-channel analysis).
- Audit log trustworthiness: Append-only audit logs lack details on tamper-evidence (hash chains, secure timestamps, signatures), protected storage, access control, and cross-party audit correlation.
- Legal-grade non-repudiation: Whether action logs and authorizations meet evidentiary standards (e.g., digital signatures, verifiable credentials) for cross-organization accountability is not discussed.
- Rollback limits: The undo/rollback strategy applies to local file mutations, but irreversible external actions (e.g., emails sent, funds transferred) lack compensating transaction patterns and governance.
- Cloud-edge security posture: Details on channel security (mutual TLS, key management), remote attestation of the edge client, and protection against supply-chain attacks on clients are absent.
- Single point of trust/failure: The central orchestrator is a trust and availability bottleneck; decentralized or federated alternatives, failover, and partition tolerance are not explored.
- Multi-tenant isolation assurance: Co-resident identity agents in one container are “logically” separated, but the paper does not specify mechanisms (process isolation, namespaces, FS sandboxing) or empirical isolation tests against cross-identity data bleed.
- Prompt-injection and content sanitization: There is no concrete mitigation for prompt injection across agents (from files, messages, or collaborators), nor evaluation of role drift defenses beyond prompt templates.
- Policy verification and enforcement testing: No formal methods, static checks, or runtime monitors are provided to verify that policy enforcement (L1/L2) is complete, correct, and unbypassable.
- Defense-in-depth failure handling: If both L1 and L2 are compromised, there is no described detection, containment, or recovery plan (e.g., anomaly detection, quarantine, incident response).
- Scaling and performance: The cost/latency of per-user containers and always-on WebSockets is not characterized; throughput, queuing, and scheduling for large numbers of users/identities remain untested.
- Session lifecycle and termination: The collaboration termination description is incomplete (text truncation) and lacks concrete rules for owner overrides, idle timeouts, and session state cleanup.
- Recursive collaboration risk control: Parameterization of recursion depth is mentioned, but the management of transitive authorization, data minimization along chains, and consent propagation is undefined.
- Cross-framework interoperability: Although compatible with protocols like Agent2Agent is suggested, the message schema, capability negotiation, identity/auth binding across frameworks, and test results are absent.
- Memory safety and privacy: The progressive cognitive coupling mechanism lacks safeguards against memory poisoning, data minimization policies, retention limits, encryption at rest, and user-driven “forgetting.”
- Evaluation rigor: Only qualitative scenarios are given; there are no quantitative benchmarks on task success, time savings, authorization violation rates, false-positive/false-negative rates of enforcement, or ablation of governance features.
- Usability and consent fatigue: The cost of bilateral approvals and escalations on users, ergonomics of identity selection, notification design, and defaults for offline/unavailable owners are not studied.
- Human override boundaries: Criteria for automatic vs. escalated decisions, and safe automation thresholds that avoid user fatigue while preserving control, are unspecified and unevaluated.
- Organizational identities and delegation: Handling of team- or organization-level identities, hierarchical delegation, and shared ownership/control across multiple humans is not specified.
- Policy portability and federation: How policies and identities migrate across devices, organizations, and jurisdictions (SSO/SAML/OIDC, federated trust) is unaddressed.
- Jurisdictional compliance: Data protection obligations (GDPR/CCPA/HIPAA), cross-border data flows, logging retention vs. privacy, and user rights (erasure, access) are not considered.
- Provenance and lineage: Mechanisms to attach, propagate, and verify provenance metadata across agents and organizations are absent, limiting downstream accountability.
- Privacy of logs and backups: Storage, encryption, redaction, and access control for sensitive content in audit logs and backups are undefined.
- Robustness to malicious collaborators: Security controls against abusive or probing counterpart agents (rate-limiting, content filtering, honeypots, negotiation safeguards) are not described.
- Multi-device consistency: Handling multiple edge nodes per user, state synchronization, conflict resolution, and consistent policy enforcement across devices is not covered.
- Extensibility beyond files: A general capability and permission model for commands beyond file I/O (GUI control, networking, application automation) is not laid out.
- Update and patch governance: Secure rollout of client and server updates, key rotation, and backward compatibility policies are not discussed.
- Reproducibility assets: There is no released dataset of cross-user interactions, threat cases, or evaluation harness to enable comparative studies by the community.
Practical Applications
Immediate Applications
Below are concrete, deployable use cases that can be built with ClawNet’s identity-governed, cloud–edge architecture, dual-layer authorization, and action-level accountability today.
- Procurement/RFQ between trusted partners (manufacturing, supply chain)
- What: Buyer and supplier identity agents negotiate specs, timelines, and pricing; suppliers keep internal costs and floor prices private while sharing authorized proposal data.
- How ClawNet enables it: Identity-bound agents, bilateral approval, scoped authorization for per-role file access, and full audit/rollback on file operations.
- Tools/workflows: “Procurement Claw” workflow; Agent Contact Manager; Audit Explorer; integration to ERP/CRM via API tools.
- Assumptions/dependencies: Pre-existing trust relationship; correct L1/L2 ACL configuration; connectivity for cloud–edge coordination.
- Contract redlining across organizations (legaltech, SaaS)
- What: Legal identity agents exchange redlines and clauses; managers are consulted for value-boundaries (e.g., non-negotiables) but never exposed externally.
- How ClawNet enables it: Manager–identity split prevents leakage; audit trails and pre-execution backups ensure reversibility and accountability.
- Tools/workflows: Identity Agent Studio for legal personas; versioned doc storage + rollback; DLP-friendly folder whitelists.
- Assumptions/dependencies: Reliable document diff tools; human-in-the-loop approvals for final terms; encrypted transport and storage.
- Client–freelancer deliverable management (creative, consulting, software)
- What: Separate identity agents for each client coordinate tasks, content exchange, and timelines without cross-client data leakage.
- How ClawNet enables it: Per-identity file whitelists on the node endpoint; bilateral approvals for external sharing; action-level accountability.
- Tools/workflows: Per-client “data rooms” governed by L2 whitelists; automated progress sync via multi-turn agent dialogue.
- Assumptions/dependencies: Clear folder structure by client; user discipline in identity selection per contact.
- Cross-org project coordination (software/devops)
- What: Agents coordinate milestones, issue triage, and PR reviews across company boundaries, while keeping internal repos private.
- How ClawNet enables it: Identity-scoped access to code directories; bilateral approvals to initiate external coordination; audit logs for compliance.
- Tools/workflows: Git provider tool-use; CI/CD integration; role-specific system prompts to prevent drift.
- Assumptions/dependencies: Fine-grained repo permissions; secure tokens managed within identity scopes.
- Vendor onboarding and security questionnaires (enterprise IT, vendor risk)
- What: Agents exchange SOC2/ISO artifacts, DPAs, and questionnaires; sensitive attachments stay inside authorized folders and are logged.
- How ClawNet enables it: Dual-layer authorization; pre-execution backups; bilateral approval before external dispatch.
- Tools/workflows: Structured Q&A templates; automated evidence packaging from scoped folders; audit-ready exports.
- Assumptions/dependencies: Evidence repositories organized by vendor; privacy policies mapped to identity scopes.
- Academic collaboration across institutions (research, education)
- What: PI and student identity agents coordinate drafts, datasets, and deadlines; sensitive datasets stay within allowed scopes with full auditability.
- How ClawNet enables it: Identity-scoped access for “PI,” “Student,” “Admin” personas; cross-user negotiation with escalations for decisions.
- Tools/workflows: “Research Claw” workflows for manuscript assembly; dataset sharing checklists; audit exports for compliance.
- Assumptions/dependencies: Use with non-PHI or de-identified data unless compliance frameworks are in place; campus IT acceptance of agent clients.
- Sales proposal assembly with client-side validation (sales ops)
- What: Sales identity agent assembles proposals by pulling approved assets; coordinates with client’s procurement agent on requirements and timelines.
- How ClawNet enables it: Scoped access to proposal libraries; bilateral approvals for sharing; audit logs for post-mortems.
- Tools/workflows: Connector to content repos (CMS/Drive); “Proposal Packager” with identity-bound templates.
- Assumptions/dependencies: Versioned content repositories; pricing data segregated by identity scopes.
- Customer support escalation across OEM–reseller–customer (support)
- What: Agents triage issues, collect logs, and coordinate escalations across entities with strict data boundaries.
- How ClawNet enables it: Bounded recursive collaboration; role-based prompts; append-only logs for compliance.
- Tools/workflows: Ticketing integrations; scoped log collectors on the node endpoint; incident audit reports.
- Assumptions/dependencies: Clear escalation paths; secure handling of diagnostic data.
- Cross-department file operations with reversibility (IT governance)
- What: Agents perform routine enterprise file tasks (organizing, migrating, labeling) with full rollback and audit.
- How ClawNet enables it: Pre-execution backups, undo/rollback, and identity-bound logging.
- Tools/workflows: Batch operations with dry-run; policy-backed folder whitelists per department identity.
- Assumptions/dependencies: Storage capacity for backups; standardized directory policies.
- Accountant–SMB collaboration on books (finance, SMB)
- What: Accountant and client identity agents exchange statements and ledgers; only authorized folders are accessible.
- How ClawNet enables it: L1/L2 ACLs; bilateral approvals; audit-ready logs for year-end compliance.
- Tools/workflows: Accounting app connectors; secure “Agent Data Room” for document exchange.
- Assumptions/dependencies: Data classification (receipts, bank exports) mapped to per-identity folders; time-bound access policies.
- Parent–school coordination (education, daily life)
- What: Parent identity agents handle forms, fees, and scheduling with school’s agent while keeping work/personal boundaries separate.
- How ClawNet enables it: Identity selection per contact; auditability; escalation for decisions requiring consent.
- Tools/workflows: “Family” vs “Work” identities; school-side agent contact directory; reminders and approvals.
- Assumptions/dependencies: School IT willing to run a gateway or use hosted instances; parents configure folder whitelists.
- Household administration with partner/family (daily life)
- What: Coordinating chores, bills, and shared files among family agents without exposing work documents.
- How ClawNet enables it: Per-identity scoping; multi-turn planning; reversible file actions and change history.
- Tools/workflows: Shared “Household” identity; calendar and bill-pay integrations; approval prompts for sensitive actions.
- Assumptions/dependencies: Basic digital hygiene and identity setup; secure local devices for node endpoints.
Long-Term Applications
These opportunities require further research, scaling, standardization, or regulatory alignment before widespread deployment.
- HIPAA-/GDPR-compliant clinical data exchange (healthcare)
- What: Hospital, clinic, and insurer agents coordinate care and claims with strict PHI controls and auditable trails.
- Dependencies: Formal compliance certifications; EHR integrations; data residency controls; legal recognition of agent-mediated consents.
- Loan origination and underwriting (banking/finance)
- What: SME’s agent shares required docs with bank’s agent; scoped access ensures only needed financials are disclosed; full audit for regulators.
- Dependencies: KYC/AML integration; digital signature and non-repudiation; regulators’ acceptance of audit logs as evidence.
- E-government and public procurement at scale (public sector)
- What: Citizen/business agents interact with government agents for permits, benefits, and tenders; transparent accountability chain.
- Dependencies: Statutory definitions for agent-of-record; identity binding anchored in national eID; accessibility and inclusivity requirements.
- Cross-framework interoperability networks (software ecosystems)
- What: ClawNet governance layered atop protocols like Agent2Agent for multi-vendor collaboration.
- Dependencies: Standards for identity binding, authorization semantics, and audit formats; conformance test suites.
- Cryptographically verifiable audit trails (compliance, legaltech)
- What: Append-only, tamper-evident logs (e.g., hash chains or ledger-backed) for legal-grade accountability.
- Dependencies: Key management at scale; secure time-stamping; chain-of-custody procedures; regulator buy-in.
- Multi-tier autonomous supply chain consortia (manufacturing, logistics)
- What: Recursive agent collaborations across OEMs, Tier-1/2 suppliers, and logistics with bounded depth and scoping.
- Dependencies: Network governance (onboarding, revocation); SLA enforcement mechanisms; robust failure handling across chains.
- Agent-as-legal-representative frameworks (law, policy)
- What: Agents initiate or receive legally binding communications under scoped mandates; human approval where required.
- Dependencies: Legal standards for digital delegation and accountability; integration with e-signature and notarization systems.
- Marketplaces for identity-governed agent services (platforms)
- What: App stores offering verticalized workflows (procurement, research, support) with governance baked in.
- Dependencies: Certification regimes for tools; revenue-sharing and liability models; security vetting of third-party tools.
- Formal verification and certification of governance (safety engineering)
- What: Proving authorization enforcement and escalation properties; certifying agent runtimes for critical operations.
- Dependencies: Formal specs for ACLs and escalation logic; model-checking and runtime verification tooling.
- Mobile/IoT/robot endpoints under identity scopes (robotics, smart home)
- What: Agents orchestrate physical devices (robots, sensors) across owners with per-identity permissions and audit.
- Dependencies: Secure device identity and provisioning; latency and safety constraints; OTA update governance.
- Multi-cloud and data residency orchestration (enterprise IT)
- What: Agents enforce geo-bound scopes and residency policies while collaborating across jurisdictions.
- Dependencies: Policy engines aware of regional law; data localization controls; cross-cloud identity federation.
- Fair and privacy-aware recruiting workflows (HR tech)
- What: Candidate and recruiter agents negotiate interviews and disclosures within scoped identities; auditability for fairness reviews.
- Dependencies: Bias monitoring; policy constraints on data sharing; integration with ATS systems.
- Federated research clouds with sensitive data tiers (academia)
- What: Agents coordinate multi-institution projects with tiered access to restricted datasets and full provenance.
- Dependencies: Data use agreements codified as authorization policies; institution-wide PKI and SSO; export-control checks.
- Insurance and risk products for agent ecosystems (insurtech)
- What: Underwriting “agent malpractice” risk using audit logs; incident response playbooks leveraging reversibility.
- Dependencies: Actuarial models for agent behavior; standardized incident taxonomies; secure log sharing with insurers.
- Red-teaming and security governance programs for agents (security)
- What: Continuous testing of cross-user collaboration boundaries and escalation paths; shared vulnerability disclosures.
- Dependencies: Benchmarks for cross-user risks; sandbox environments; community frameworks for coordinated fixes.
Glossary
- Access control list (ACL): A permissions table defining which identities can access which resources or operations. "the first-layer access control list (L1 ACL) for file operations."
- Action-level accountability: Logging every operation with identity and authorization context to ensure auditability. "Action-level accountability logs every operation against its owner's identity and the corresponding authorization, ensuring full auditability."
- Agent2Agent (A2A): A protocol enabling agents to discover and exchange messages across frameworks. "Google's Agent2Agent"
- Append-only audit log: A log structure that only allows new entries to be added, preventing tampering with past records. "append-only audit log"
- Architectural isolation: A design constraint that prevents certain components from communicating externally to reduce leakage risk. "architecturally isolated from all external communication"
- Audit trail: A comprehensive record of actions enabling post-hoc inspection and correction. "a comprehensive operational audit trail"
- Authorization boundary: The enforced limit of resources and actions an identity is permitted to access. "acts autonomously within its authorization boundary."
- Bilateral approval: A requirement that both collaborating owners explicitly consent before agents interact. "bilateral approval"
- Central orchestration engine: The server component coordinating identity-based routing and collaboration workflows. "central orchestration engine"
- Cloud-edge architecture: A system split between always-on cloud cognition and local device execution. "ClawNet adopts a cloud-edge architecture"
- Cognitive coupling: Progressive alignment where an agent internalizes a user’s facts, patterns, and values. "memory-driven cognitive coupling"
- Defense in depth: A security approach using multiple independent layers to enforce protection. "Defense in depth, not defense in series."
- Dual-layer independent authorization scheme: Two separate authorization checks (server and client) that independently gate operations. "dual-layer independent authorization scheme"
- Fail-closed design: A security posture where any failure results in denying the operation. "fail-closed design"
- Factual memory: Stored explicit facts about the owner (files, contacts, schedules) accumulated over time. "The first layer is factual memory."
- FIPA-ACL: A standardized agent communication language defined by FIPA. "FIPA Agent Communication Language (FIPA-ACL)"
- Governance enforcement: System-level mechanisms that automatically block unauthorized requests regardless of agent behavior. "rejected by governance enforcement rather than agent discretion"
- Governance primitives: Core mechanisms—identity, authorization, accountability—that structure safe collaboration. "three governance primitives"
- Identity agent: A context-specific agent persona representing a user within a defined role and scope. "Each identity agent I_ui corresponds to a specific collaborative context"
- Identity binding: Permanent association of an agent system with its human owner. "identity binding, scoped authorization, and action-level accountability"
- Identity domain: The scoped identity context against which actions and logs are bound. "its identity domain"
- Identity-governed agent collaboration framework: A system where agent interactions are mediated by identity, authorization, and accountability. "an identity-governed agent collaboration framework"
- Identity tags: Published labels that allow counterpart agents to discover the appropriate identity persona. "identity tags"
- Identity verification: Runtime checks confirming the acting agent’s identity during collaboration. "identity verification and authorization checks."
- KQML: An early agent communication language for knowledge exchange among agents. "KQML"
- Layered identity architecture: Separation of a private manager agent from outward-facing identity agents. "A layered identity architecture separates a Manager Agent from multiple context-specific Identity Agents."
- L2 whitelist: A client-side folder allowlist enforcing local file-access boundaries. "the client-side L2 whitelist still enforces the owner's boundary."
- Manager agent: The privacy-preserving internal governor holding global knowledge, not exposed externally. "The manager agent serves as the authoritative anchor of the user's digital identity."
- Model Context Protocol (MCP): A standard for integrating tools and context with models. "Model Context Protocol"
- Multi-tenancy isolation: Strong separation of per-user runtimes (process, network, storage) in shared infrastructure. "strict multi-tenancy isolation"
- Node endpoint: The local execution target that receives directives from the cloud and performs I/O. "the node endpoint, the terminal execution environment that receives operational directives from the cloud"
- OS-level agent: An agent capable of directly controlling files, terminals, and desktop applications. "OS-level agents such as OpenClaw and Anthropic's Computer Use"
- OS-level file primitives: Basic file-system operations (read, write, move, delete) exposed to agents. "OS-level file primitives"
- Pattern memory: Learned behavioral regularities (habits, organization styles, communication patterns). "The second layer is pattern memory."
- Per-call permission prompts: Interactive approvals requested for specific operations at runtime. "per-call permission prompts"
- Principal (security): The distinct owner or authority under which agents act. "single principal"
- Proxy node: An intermediary that relays validated operations between cloud and device. "functions as a proxy node"
- Pre-execution backup: Automatic backup taken before any mutative operation to enable rollback. "pre-execution backup"
- Recoverable staging area: A temporary location for deletions, enabling restoration rather than permanent loss. "recoverable staging area"
- Role drift: The tendency of LLM agents to deviate from assigned roles over multiple turns. "role drift"
- Scoped authorization: Per-identity access control defining what resources and actions are allowed. "Scoped authorization enforces per-identity access control"
- Security event center: The owner-facing hub where boundary violations and alerts are surfaced. "owner's security event center"
- Think/act loop: Iterative reasoning and action planning cycle used by agents to execute tasks. "think/act loop"
- Value memory: Internalized owner norms and boundaries guiding what the agent should never do. "The third layer is value memory."
- WebSocket connections: Persistent, bidirectional links between server and user containers. "persistent WebSocket connections"
- Workspace subspaces: Logical partitions within a container isolating identity-specific data and operations. "logically partitioned workspace subspaces"
Collections
Sign up for free to add this paper to one or more collections.
