Can developers use a public agent swarm privately?

Research date: 1 November 2026. Public information only; no accounts created, teams contacted, jobs submitted, services purchased, or private code requested.

Group-chat summary

IMD could offer useful privacy without hiding work from the agents doing it. The smallest worthwhile change is a private project whose brief, files, reviews and results are readable only by its customer and authorized builders, reviewers and operators. Hiding it from Explorer alone would not achieve that: sampled IMD APIs expose the brief, attempts, source bundles, results and project history without login. Payments and receipts can remain public without publishing those contents. Keeping secrets even from workers is a separate, substantially harder feature: confidential-computing systems demonstrate pieces of it, with important trust and tooling limits. Make public showcases a separate, customer-approved release. This is a technical opportunity, not evidence that customers will pay a particular premium.

How to read the evidence

Observed: public response or distributed code inspected here. Documented: provider-described availability, not independently tested enforcement. Roadmap/historical: separate from current features. Inference/proposal: this report's reasoning. Unknown: not established publicly. Availability means public onboarding/tooling exists, not an end-to-end certification.

Three different promises matter:

1. Explorer-hidden: removal from a website; other public surfaces can still reveal the job.
2. Access-restricted: contents/results restricted to the customer and explicitly authorized participants. Workers, reviewers, operators and any receiving AI/tool providers remain trust dependencies.
3. Worker/operator-confidential: sensitive data stays inside an approved protected execution boundary, including its input, storage, inference and output paths. Attestation, encryption and authorization must work together. A private repository or a content hash alone provides no such execution protection.

Comparison: six systems, with different trust models

Details on storage, retention and iterations are in Appendix A. A negative finding means no qualifying feature was established in the sources checked, not that no private deployment could exist.

System and category	What outsiders can use; status	Actual privacy boundary and public residue	Publication, iterations and restrictions
Olas Mech Marketplace — open agent-service network, independently operated Mechs	Paid agent tools, including language-model and prediction services. Current client supports on-chain and direct off-chain requests. Documented available.	Standard flow places prompts and responses on IPFS and publishes references on-chain. Not access-restricted in that flow. Direct HTTP and inline answers offer a different transport, but are not proof of content confidentiality or deletion. Mech operators and selected LLM providers receive content. Standard flow, current client	A caller can orchestrate successive requests; no verified private-project guarantee. Operator-specific handling matters. Off-chain settlement still leaves public payment/activity records. No documented marketplace-wide privacy premium found. Off-chain rollout
Golem Network — open compute marketplace, independent providers; not a ready-made coding swarm	Rent execution environments and distribute tasks through Yagna/SDKs. Available network/software, with current releases.	Runtime images in demands must be publicly downloadable. Data can be transferred separately, but provider-host volumes expose execution files to that host. No blanket Level 2 guarantee; ordinary VM execution is not Level 3. Payment and market metadata persist. Images and state, releases	Requestor can retrieve results without publishing a website and preserve state within an activity; longer continuity is application-managed. Do not bake proprietary files into public images. Provider selection and configurable cleanup exist; no documented privacy surcharge found. Provider FAQ
Devin — centrally operated multi-agent service, not independent worker bidding	Software engineering with coordinator and managed child sessions in separate VMs. Current docs describe this as available in sessions. Documented shipped, with self-serve plans. Orchestration, plans	Level 2 model: account/organization and repository permissions; Cognition infrastructure and receiving subprocessors are trusted. Prompts, code and execution logs are processed centrally. Encryption at rest is not operator-confidentiality. Security/data controls, subprocessors	Work can stay in selected private repositories across sessions. Customers control repository publication, but session sharing/integrations can disclose it. Paid plans can opt out of training and enable provider ZDR; enterprise has separate terms. These are plan restrictions, not evidence of a separately priced privacy premium.
CrewAI OSS — self-hosted multi-agent framework, not a worker marketplace	Installable crews/flows, configurable models, tools and memory. Shipped framework; hosted AMP is a separate product. Repository	Level 2 is achievable by deployment design, not a universal framework guarantee. The deploying organization controls files, access and logs; configured LLM, embedding and tool services receive their inputs. Local models are possible. Telemetry and optional trace export need separate controls. Telemetry, tracing	Persistent private workflows are possible with customer-controlled storage and permissions. No required public payment ledger or showcase. OSS privacy has no feature surcharge, but operating infrastructure/models costs money. It does not isolate data from the administrator running it.
iExec / DataProtector / PoCo — distributed confidential-computing infrastructure	Encrypted datasets, permissioned applications and paid workerpool execution; current guides use Intel TDX. Documented operational tooling, not an IMD-equivalent general-purpose agent labor service. Lifecycle, workerpools	Conditional Level 3 against compute hosts: secrets released to authorized protected workloads; encrypted results require correct configuration. Dataset types, actors, deals and prices remain visible. SMS/key-service operator protection is a separate unresolved boundary; see Appendix A. Protected data, result encryption	Reusable grants and encrypted assets can support multiple computations; private multi-job agent state must be built. Public arguments, callbacks or unsafe apps can disclose secrets. Execution prices depend on resources/offers; no isolated privacy premium established.
Phala Cloud / dstack — confidential-computing infrastructure, with Private AI inference	Public cloud onboarding, confidential VMs, deployment tooling and dedicated GPU TEE guides. Documented available; not an open marketplace of arbitrary coding agents. GPU deployment	Conditional Level 3: attested workloads, protected keys and encrypted secrets can exclude host operators. Cloud KMS retains Phala authorization trust; on-chain KMS changes governance. Model API evidence may cover a router/broker rather than every model worker. KMS choice, inference boundary	Developer-controlled application state can support iterations. Logs/public endpoints can undo confidentiality. Dedicated hardware is billed compute, not a demonstrated swarm-privacy surcharge; the GPU guide warns provisioning can take about a day. Public logs

What these comparisons establish: central services and self-hosted systems show that multi-agent collaboration need not entail public publication. Open networks require separate scrutiny of task transport, downloadable assets and worker trust. Confidential infrastructure supplies useful components, not an automatic confidentiality guarantee for a complete agent workflow. This is an inference from the boundaries above.

IMD: what is exposed today

Observed conclusion: the sampled public IMD path does not provide Level 2 privacy. Unassigned workers and ordinary internet users can read its contents through the same unauthenticated endpoints. This does not prove the existence or absence of an undisclosed private tier. The public worker README explicitly describes current public reads and says the backend is not distributed. Pinned README

Lifecycle stage	Evidence and audience today	Necessary information versus implementation choice
Submission and payment admission	HTTP paid flow exists; the public OpenAPI describes quote/submit/status. Separately, verified Intake code and a decoded transaction show request publishes the complete JSON body in calldata/event data. pay instead accepts a signed quote hash and payment terms. OpenAPI, Intake source, request transaction	Payer, asset, amount and an order commitment can support payment. Publishing the full brief is a property of the request route, not required by the hash-based pay route. HTTP alone does not make the resulting job private.
Assignment	Distributed worker client authenticates signed control-plane frames and handles individual assign/research/fuzz leases. This establishes directed dispatch, not restricted public reads. The sampled job API exposes objective, node status, assigned seats and review data. Pinned client, sample job	Scheduler needs capabilities, availability, task relationships and authorized assignees. Broadcasting the objective to public readers is avoidable. Whether internal server paths additionally broadcast contents is unknown.
Execution	Assigned workers obtain task data and execute through their own Claude Code/Codex accounts; tools can receive data too. The shipped distribution contains ordinary local execution and upload logic. The published isolation language protects the worker's unrelated files; it does not establish protection of customer data from the host administrator. Worker runtime description, CLI implementation	Builders need relevant plaintext under Level 2; infrastructure providers need not be excluded for that promise. Their local copies, model settings and tool calls must be covered by an explicit policy.
Verification and reviews	A sampled submissions endpoint exposes attempt summaries, changed paths, findings, model/usage information, verdicts and bundle references. Its accepted website source is explicitly labeled evaluation: structural, profile: none. Acceptance is not universal semantic verification. Submissions, result	Authorized reviewers/verifiers need the evidence appropriate to their checks. Wider public disclosure is not inherently needed for structural integrity, builds or a restricted review panel.
Receipts, reputation and rewards	WorkRegistry's writer records a document hash, prior hash, job identifier and URI, with optional acceptance feedback. Public event/call data exposes these associations. The inspected work document itself contains an objective and research answers. LaunchFactory funds a Merkle-root distributor. Registry source, sample work document, factory source	Contracts inspected do not evaluate prompt text. Hashes/receipts and reward proofs could coexist with restricted evidence. Changing public evidence affects outside auditability and requires a deliberate policy. A general per-job worker payout or public dispute protocol was not established.
Delivery and continuation	Unauthenticated reads returned a research artifact, downloadable Git bundles, repository delivery references and project-history content. They expose useful intermediate material as well as final work. Research result, project read	Delivery and repeat work need persistent artifacts and authorized access. Public GitHub, IPFS sites, source URLs and history are current delivery choices, not prerequisites for iterative agent work.

Existing controls are narrower than privacy. Documentation offers GitHub/IPFS publication switches, accepted files as subsequent-job inputs, and owner-checked continuations. It also describes Venice-backed jobs as keeping work private. These do not establish restricted job reads or confidential worker execution. IMD documentation

Provider exposure is separate. Venice offers several privacy modes. IMD's inspected gateway sends ordinary chat requests; its documented E2EE flow was not identified there. Protected inference alone would still leave worker files and IMD delivery paths exposed. Venice modes, E2EE protocol, pinned IMD gateway code

Explorer hiding: reduces casual discovery and indexing. It does not retract already published data, block direct API/bundle/artifact reads, hide source repositories/IPFS copies, erase chain input, or constrain workers and model providers. A nonlisted URL is not authorization. Private work across iterations needs project-wide access rules covering every parent, dependency, retry, review and export.

Prioritized recommendation

Start with Level 2 private projects for pre-launch work. This is an engineering proposal, not a claim that IMD already supports it. It addresses individual developers' immediate concern—public exposure of unfinished mechanics and research—while stating clearly that authorized workers, operators and approved inference/tool providers can read the work.

Option	User benefit and remaining trust	Changes and verification consequences	Burden and limits
1. Explorer hiding	Less browsing/search exposure; everybody with another public route may still read.	Filter listings, detail previews, search, feeds and caches consistently. Does not change execution/verification. Label it unlisted, not private.	Low relative effort; old caches, APIs, repositories and chain records remain. Useful presentation control only.
2. Public-access restrictions — first priority	Prevents internet users and unassigned workers from retrieving contents. Trust assigned builders/reviewers, platform operators and declared providers.	Project ACLs, lease-scoped fetches, private artifact storage/source delivery, redacted receipts/logs, explicit retention, publication gating. Re-run checks and restricted panels can continue; public readers lose independent access to full evidence.	Moderate, cross-cutting backend/worker/product work. Copies already read cannot be recalled; operator compliance and provider terms matter.
3. Worker/operator-confidential execution — later pilot	Reduces trust in compute hosts for selected workloads; still trusts measured software, hardware, key governance and authorized output recipients.	Attested worker and verifier, protected inference, key release bound to approved measurements, encrypted state/results, controlled egress/logging and upgrades. Attestation proves a boundary/configuration, not that the research conclusion or generated code is correct.	High integration and operations burden; narrower hardware/models/tools, side channels, software exploits, outages and metadata leakage remain. Not a drop-in property of the present worker.

Proposed private-job lifecycle

1. Create a private project. Authenticate the customer; select authorized roles and allowed model/tool providers. Store brief, source and attachments in encrypted off-chain storage with a project ACL. Use opaque identifiers and nonsensitive public labels. Enforce privacy on the server.
2. Pay against a commitment. Keep the brief out of chain calldata/events. Adapt the existing quoted-payment pattern, admission and delivery paths. Commit to a randomized private manifest; salt low-entropy content hashes to resist guessing and linkability.
3. Assign before disclosing. Advertise capabilities and coarse workload only. Give selected builders/reviewers/verifiers short-lived, identity-bound fetch grants for required inputs. Reauthorize replacements. Disclose that authorized independent workers can copy plaintext; record access.
4. Execute and check privately. Restrict workspaces, logs, summaries, screenshots and previews. Enforce approved inference/tool policies instead of assuming every personal subscription has suitable settings. Preserve the actual verification level in receipts.
5. Deliver without publishing. Return a versioned manifest and authenticated downloads or a private repository. Publish minimal receipts/commitments; keep detailed evidence restricted. Never place a bearer download credential in an on-chain URI.
6. Continue privately. Inherit ACLs, provider rules and artifact permissions across jobs. Block private-to-public attachments by default. Approve new participants, expire fetch grants, clean worker copies and document backup/provider retention exceptions.
7. Publish a separate release on request. Preview selected files/text, scan for private history and secrets, obtain customer consent, then export the showcase/repository/site. Earlier briefs, attempts and versions stay private unless approved separately. Published copies cannot reliably be recalled.

Verification/disputes: minimal on-chain commitments are technically plausible because the inspected contracts accept hashes/URIs rather than interpreting the evidence. This does not establish compatibility with every IMD server schema or reward policy. Keep a restricted evidence bundle for a defined dispute window and give explicitly authorized adjudicators access. If IMD intends permissionless public challenges, hiding evidence changes that assurance; do not quietly replace it with an operator's assertion. For deployed public contracts and public oracle answers, the deployed bytecode/transactions or answer itself remains visible even when preparatory work is private.

Today: use the sampled IMD path for deliberately public or sufficiently redacted work; keep sensitive core work in a controlled workflow until a restricted mode is shipped and tested.

Demand/pricing: the compared products demonstrate privacy supply, not quantified IMD demand. This brief and public research jobs establish use cases, not willingness to pay. Pilot private projects and measure adoption/costs; no evidence here supports a revenue uplift or specific surcharge.

Five questions for IMD maintainers

1. Does any supported private-project mode already exist, and exactly which read APIs, artifact stores, history routes, receipts and Explorer caches enforce its ACL?
2. Who can receive full task/dependency contents internally—assigned workers only, standby/replacement workers, planners, reviewers, verifiers, operators—and can customers approve or constrain that set?
3. What are actual retention, deletion, backup, logging and model-provider/training policies across these actors, including Venice model selection and any provider fallbacks?
4. Which current acceptance, reward, reputation or dispute rules require public evidence, and could private jobs retain the same rewards with restricted adjudication and accurately labeled verification?
5. Can private source/artifact delivery, inherited project permissions and an explicit later publication step be supported without automatic GitHub/IPFS/receipt-content publication, and what migration is needed for existing clients/contracts?

---

Appendix A — Platform evidence and important limitations

A1. Olas: off-chain is not automatically private

Documented standard implementation: request JSON includes prompt, tool and a nonce; the requester uploads it to IPFS. Mech watches request references, reads the payload, calls its tools, and uploads a response to IPFS. Referenced readable content is exposed to anyone obtaining it; hashing does not encrypt it. This is stronger evidence than assuming a decentralized marketplace must either be private or public. Mech tool-development documentation

Current transport update: September's rollout describes direct HTTP requests with asynchronous on-chain settlement. The current client allows inline off-chain answers as well as IPFS delivery. Thus it would be wrong to claim every current off-chain prompt/result must be published to IPFS. Neither source establishes a marketplace-wide ACL, confidential execution, deletion schedule, private iteration store or customer-controlled publication contract. Operator terms and actual tool behavior must be checked. Rollout, client return semantics and operator disclosures

Exposure/retention: an executing Mech sees inputs and intermediate work; its upstream model/tool services see what it sends. Published references, payment histories and third-party IPFS copies cannot be treated as privately revocable storage. Private chained work is therefore not established, although a custom operator could implement it. No verified global retention or privacy-price schedule was found.

A2. Golem: useful separation of compute and delivery, with public-image hazards

Documented: the requestor sends code/data to a selected provider and downloads results. This does not require publishing a finished product. However, the VM-image guide requires images named in demands to be public and describes provider-host-backed volumes. It also documents filesystem continuity across tasks within an activity. Inference: a generic public runtime plus separately transferred inputs avoids publishing secrets in the image, but does not protect them from its host administrator. Transfer examples, image requirements and filesystem behavior

Access/storage qualification: the published GFTP implementation binds download handlers to a file-content identifier; no per-assigned-worker ACL check was identified in those handlers. This is static inspection, not a live network authorization test, and is another reason not to label the whole network Level 2. Transfer URLs should be treated as sensitive. GFTP implementation

The provider FAQ documents configurable task cleanup, defaulting to 30 days; that is not cryptographic erasure or a guarantee against copies. Providers have local logs, while pricing/node/payment information is available publicly. An application calling an external LLM adds that provider; Golem itself is compute infrastructure, not a compulsory model broker. No universal retention contract or managed private-project/publication feature was established. Provider FAQ, debug logging

A3. Devin: account privacy still includes operator and provider trust

Documented: repository access is selected through the GitHub integration; resulting PR visibility follows the repository. Central managed sessions coordinate multiple VMs, rather than independent third-party seat holders. Session tools expose commands, edits and browser activity to the customer. Continued work can use the same private repository and organization context. GitHub permissions, managed Devins, session tools

Security docs describe encrypted transmission/storage and limited production access by role. They also say training may occur by default; paid customers may opt out, enabling ZDR with model providers, while enterprise training requires express consent. Retention of service data and some feedback/interaction data differs. Do not interpret ZDR at model providers as deletion of the hosted project or session history. Security and data controls

The DPA lists infrastructure/logging and model subprocessors, including OpenAI and Anthropic, and provides a termination-related deletion period with exceptions. The general privacy notice warns about shared conversation links. Repository choice does not control all integrations, central logs or legal retention. Self-serve access is documented; stronger enterprise deployment terms are not a universal free-tier entitlement. No separately itemized privacy-only premium was established. DPA, privacy notice, plan structure

A4. CrewAI: keeping work private is the deployer's responsibility

Documented implementation surface: the OSS framework supports agent orchestration and local models. Storage, authentication, file permissions and tool access depend on the deployment; installing a framework does not supply an independent-worker labor pool or a privacy contract. Framework README

Telemetry collects technical attributes including tool names and agent roles; those names can themselves disclose a project. share_crew enables richer data sharing. Current docs distinguish CREWAI_DISABLE_TELEMETRY from tracing controls: OTEL_SDK_DISABLED does not disable AMP tracing, which needs its own setting. Telemetry controls

Trace docs describe upload consent/authenticated exports and warn that traces can contain prompts, inputs and outputs. Hosted tracing is another recipient when enabled. Private iterations can use local or customer-controlled memory/state; persistence and embeddings may add further service dependencies. Inference: customers can avoid public disclosure with local models, controlled tools, disabled exports and secured storage, but remain responsible for backups/deletion and administrator access. No universal retention duration applies to every self-hosted configuration. Trace export behavior, memory configuration

A5. iExec: protected data and execution do not make every layer secret

Documented current workflow: DataProtector authorization selects permitted apps/users; the SMS checks the protected workload's eligibility before releasing secrets. Trusted application code sees decrypted inputs and intermediates inside its execution boundary. External AI services still receive any plaintext that application sends them. A malicious authorized app can intentionally disclose data: permission must be to reviewed behavior, not merely an app address. Access control, confidential assets/SMS

Critical qualification from implementation: the public SMS README describes AES-encrypted disk storage, TLS provisioning, a local encryption-key path and separate TEE provisioner/session-storage services. That does not establish that every production SMS operator is excluded from secret access. Current high-level docs mention TEE-backed secret storage; the deployed configuration was not verified. Therefore this report credits a conditional protected-worker path, not proven confidentiality from all infrastructure operators. SMS source and configuration

Results/public residue: SDK instructions explicitly request --encrypt-result and use a beneficiary encryption key; do not assume all task outputs are secret by default. The input guide distinguishes public inputFiles URLs and on-chain arguments from protected data/secrets. Asset schemas, identities, orders and prices also reveal metadata. Confidentiality of application source/container distribution was not established; protected input data alone does not establish private application code. The Explorer includes result-download and encryption-status views. Encryption tutorial, arguments warning, Explorer

Reusable authorizations and protected datasets support repeat computations. Re-protecting derived state and controlling who can run which application would be needed for a private iterative swarm; this was not verified as a packaged feature. No firm general dataset/result deletion schedule was established; revoking future use cannot retract previously delivered plaintext. Workerpool onboarding currently points prospective operators to assistance, so do not equate the public requester toolkit with frictionless permissionless joining of its current TDX fleet. Workerpool documentation

A6. Phala/dstack: inspect the whole chain of trust

Actual implementation surface: deployment and attestation guides, client-side encrypted secrets, GPU verification commands and open-source dstack provide more than a marketing claim. The secret guide specifies client-side encryption to values decryptable in the CVM and warns that logs or Terraform state can expose them. Encrypted secrets, attestation, dstack implementation

Boundary: customer-approved code inside the CVM can read inputs, source and outputs. Excluding a host does not exclude a developer/operator with authorized SSH, logging access or power to approve malicious code. Cloud KMS policy remains controlled by Phala; on-chain KMS can make update authorization externally visible and configurable. It does not automatically remove every governance/key compromise risk. KMS governance

The Private AI API documents gateway plaintext processing, varying upstream evidence coverage and explicit client verification. It warns that local agent tools and telemetry are outside its inference boundary. Thus attesting a gateway is insufficient evidence of an entire confidential swarm. Dedicated GPU TEE deployments provide more control over serving code but require actual workload/CPU/GPU/channel verification. Inference trust boundary, GPU guide

Storage/retention/publication: protected application storage and keys can preserve private state across runs; application authentication and encrypted result delivery still have to be implemented. Public Logs explicitly allows unauthenticated access to a copied URL when enabled; disable it for sensitive workloads. There is no single retention promise established here for every customer-built application's files, backups and logs. Hardware allocation, billing/traffic metadata and public attestations or governance transactions can remain visible without revealing content. Log controls, dstack storage/key design

A7. Documented limited attempts, and what was not found

• Golem SGX/Graphene, historical prototype: a 2019 first-party account reported working Blender integration but said both integration and LibOS needed more development before mainnet. The SGX runtime repository contains voting-demo work and unresolved release/driver issues. This documents attempts and incomplete integration, not a verified abandonment decision. No reliable first-party explanation that privacy failed commercially was found. 2019 engineering Q&A, runtime repository, release issue, driver issue
• iExec SGX compatibility limits: its account of moving toward TDX says SGX applications could require substantial rewriting. The current TDX guides show a successor approach; this is a documented technical limitation and evolution, not evidence the overall privacy effort was abandoned. The 2026 roadmap alone is not proof every planned capability shipped. Compatibility discussion, roadmap
• Phala, explicitly residual work: the dstack-cloud threat model lists side channels, governance collusion, service denial and a KMS root-key trust concentration; distributed MPC root-key generation is described as future work for that architecture. Do not apply a design document's stronger future trust model to every current deployment. Threat model

No substantiated abandoned IMD private-work product was identified in the public material reviewed. That finding does not mean nobody tried, or that one is impossible.

Appendix B — IMD evidence ledger and limits

B1. Direct public-read checks

Read-only GETs on 1 November 2026 used no Authorization header, session cookie or worker identity. A descriptive User-Agent was supplied; initial requests through some clients were blocked, but subsequent ordinary HTTP GETs returned the responses below. Rate limits, CORS and bot filtering are not customer-specific authorization. The response sizes and SHA-256 fingerprints of the initial samples are recorded in the observation ledger; bodies are not republished here.

Public resource checked	Observation	What it establishes / does not establish
Job 44188dd1…	HTTP 200; objective, project versions, nodes/seats and delivery metadata	Public brief and coordination/history exposure for this job; not proof every internal log is public.
Its submissions	HTTP 200; four attempts with summaries, paths, findings and usage	Public intermediate/review exposure, including unsuccessful work; does not reveal a complete raw model transcript.
Its result manifest	HTTP 200; source bundle URL and repository delivery	Public delivery references. The referenced bundle also returned 200 with Git-bundle bytes.
Research result 304834c0…	HTTP 200; named Markdown output URL, hash and source bundle	Its artifact and bundle URLs both returned bytes without authentication. An opaque digest URL is not a read ACL.
Project read	HTTP 200; history file with earlier request excerpt, source reference and site CID	Continuation context is another disclosure path, separate from Explorer.
Swarm, jobs	HTTP 200; public coordination/health/job data	Listing/feed redaction also belongs in a privacy design. No exhaustive endpoint audit performed.
Current version, worker build record	API commit and worker source build both identify a6eb446119eb3b800ad72ba242263311f176c046; distributed worker 0.1.9	Useful snapshot alignment; not verification of the private backend implementation.

Publication flags are not ACLs. Choosing not to export a repository or website is insufficient when the same brief and accepted bytes remain publicly retrievable. The public-read observations above establish this distinction directly; they do not establish a private delivery mode.

B2. Contract behavior versus documentation claims

Sources at Ethereum Intake 0xa43e6f75ee006411f79ac1c84120606c2330de82 and WorkRegistry 0xb6d0a187b050fa5bb0b87033a203f37becf4a775 were obtained from Blockscout's verified-source APIs. Sourcify v2 independently returned matching metadata for Intake, WorkRegistry and LaunchFactory; their relevant source contents matched the Blockscout copies. Later link checks encountered transient Blockscout API 500 responses; the original successful observations remain recorded. This is source attribution; bytecode was not independently recompiled/audited in this job. IMD's docs still said explorer sources were unverified, so that blanket statement is stale relative to these observations. Intake verified source, Sourcify, WorkRegistry verified source

Intake observation: _request collects funds and emits Requested with body. The sampled request transaction decodes to a JSON brief. pay checks signed quote terms and emits Paid without the brief. complete accepts a result hash, URI and callback arguments; sensitive callback payloads would also be public transaction data. Existing pay is a concrete reason not to assume all briefs must be on-chain. Decoded request, decoded quote payment

WorkRegistry observation: recordWork validates the writer, hash chain and feedback fields, then emits a URI; it does not fetch/interpret the referenced content or require a public storage scheme. A sampled on-chain WorkRecorded event references receipt.json on IPFS. The corresponding public API document contained the objective, research answers and provenance. IPFS gateway retrieval failed with 403 during this research, so no claim is made that those gateway bytes were independently matched to the on-chain digest. Event transaction, event API, work document

Rewards qualification: LaunchFactory funds a contributor distributor and passes a Merkle root; this does not itself require public prompt text. Documentation describes launch-token shares for accepted contributors and connected seats. Those launch rewards must not be confused with a proven universal direct payout for every research/code job. No public dispute procedure requiring global content disclosure was established. Public evidence availability may nevertheless be important to community trust or allocation audits. Factory implementation, launch policy documentation

B3. Additional leakage and uncertainty checklist

• Unassigned workers: public reads make non-assignment irrelevant for sampled contents. The lease-based submission channel does not remedy public downloads. Internal dispatch/planner visibility beyond the distributed client remains unknown.
• URLs/repositories: source/import URLs, presigned URLs, Git commit history, issue/PR bodies, repository names and README files can reveal the project. Private repositories only protect repository readers; workers and model services still see content they process.
• Logs/previews: summaries, error reports, screenshots, browser previews, tracing, content checks, search queries and external tools can export sensitive details. IMD-wide logging/access/backup retention and preview authentication were not established; these are risks to review, not claims that every listed surface currently leaks.
• Model-provider policy: workers' own Claude/Codex accounts are material. Ordinary hosted routes add Anthropic/OpenAI as model-context recipients; configured gateways such as Venice can change that chain (inference from the runtime paths, not a per-job routing audit). Anthropic's consumer policy explicitly covers Claude Code, allows extended retention for opted-in training, and includes safety/legal exceptions. Exact settings on IMD workers are unknown. Do not apply API enterprise terms to every personal worker plan. Worker account model, Anthropic consumer retention
• Venice: available inference privacy modes do not remove customer content from IMD APIs or worker disks. An anonymized provider route still exposes prompt content to that provider; documented E2EE requires a different client flow. The inspected worker gateway does not establish that flow. Modes, gateway code
• Verification scope: research/website skill metadata currently advertises a structural path without substantive checks, consistent with the sampled result manifests. Other profiles have different checks; neither acceptance nor an attestation is a blanket assurance of research truth or code safety. Live skill catalog
• Irreversibility: removing an API route or changing permissions later cannot erase chain events, public repository history or downloaded/IPFS-replicated copies. Private mode must apply before first submission and throughout the project.

B4. Research limits

The six comparisons intentionally cover different categories rather than treating their security claims as interchangeable. Documentation was checked against distributed code/public responses where feasible. No private account security test, paid execution, hardware attestation experiment, penetration test, backend audit or cryptographic proof of provider compliance was performed. Negative search findings about abandoned products and retention are limited to the linked public materials; they are not claims of impossibility. The accompanying checks establish file/link structure and observation consistency, not independent factual certification.