Public preview · Private device infrastructure for AI agents

Agent Device Cloud

Give any AI agent controlled access to the files, tools and environments already on your devices.

Agents keep using MCP, CLI or SDK. ADC authorizes and routes each call; the selected Mac, Linux or Windows device runs the tool.

Create an account View on GitHub Read the architecture

Live control planeinv_01 · mcp.github.search

Agent interface

Call a local MCP tool

MCPCLISkillSDK

actor_coding · grant_dev

Authorized tool call

Control planePolicy and placement

01Identity verified

02Agent grant matched

03Device policy allowed

04Approval satisfied

Audit ledgerdecision_allow · job_01

Signed lease

Connected

Selected deviceBuilt-in tools + MCP Providers

Provider credentials stay local

mcp.github.search · file.patch

Authorized

Queued

Claimed

Running

Succeeded

Completed on deviceReceipt recordedrcpt_01 · 1.8s

Runs on your deviceOnly requested results travel back.

Outbound connectionNo inbound port on the device.

Explicit accessEach Agent gets its own grant.

Auditable effectsEvery side effect gets a receipt.

Why Agent Device Cloud

The context agents need is not in the cloud.

Your code, tools, credentials and private services already live on machines you control.

Cloud agents are useful, but copying an entire working environment into every agent is slow, fragile and difficult to govern.

Agent Device Cloud connects the two without turning your device into an unaudited remote shell.

Built first for developers and self-hosters

Real work, on the machine that is ready for it.

Continue local development

Let an agent inspect a repository, apply focused edits and run existing tests without rebuilding the environment elsewhere.

file.read · file.patch · test.run

Developer Mac

Connect existing MCP tools

GitHub MCP · database MCP

Mac, Linux or NAS

Move work across interfaces

Start from an MCP client, terminal, Skill or SDK and route the same governed work to the intended device.

MCP · CLI · Skill · SDK

Selected device

Automate with boundaries

Use explicit templates, writable folders and approval rules for repeatable work instead of sharing unrestricted access.

grant · approval · receipt

Approved device

Architecture

One control plane. Execution remains local.

Use familiar Agent interfaces. ADC applies authorization and routing centrally; the selected device validates and executes each tool locally.

Agent interface

Use MCP, CLI, Skill or SDK to call authorized tools on the selected device.

MCP clientCLIOfficial SkillSDK

Authorized request

Control plane

Authenticates, authorizes, routes and records. It does not execute your tools.

IdentityAuthorizationPlacementAudit ledger

Outbound dispatch

Device connector

Maintains an outbound wake connection, advertises built-in and local MCP tools, and renews active leases.

WebSocket wakeBuilt-in toolsLocal MCP ProvidersLease and ACK

Local execution

Local runtime

Revalidates local policy, runs built-in tools or calls the selected MCP Provider, and persists a receipt.

Path validationLocal executionReceipt ledger

Dispatch stateat-least-once · durable receipt

AuthorizedQueuedClaimedRunningSucceeded

Cancellation is checked during lease renewal. An unprovable side effect becomes unknown_outcome, never a silent retry.

Control plane records

Accounts, disclosed path metadata, grants, invocation state, requested results, artifacts and receipts.

Device retains

The private device key, unrequested files and the local environment. Only an authorized operation can return content.

Explore the system design

Trust model

Permission is the smallest shared intersection.

Account boundarySame account owner

Agent grantDevice and tool selected

Device policyWrites and execution enabled

Exposed folder/Users/me/work

Live capabilityfile.patch advertised

Effective permissionfile.patch/Users/me/work/src/**

Allowed only when every layer agrees.

Separate identities

User sessions manage the account, Agent credentials use one grant, and every device owns a separate key.

Intersect permissions

Account, Agent, device, folder and capability rules must all allow the same operation.

Keep local authority

The device validates paths and permissions again. Cloud policy can narrow local access, never expand it.

Record side effects

Idempotency, leases and durable receipts make retries and uncertain outcomes explicit.

Security boundary, stated plainly

Restricted process mode reduces common mistakes; it is not an OS sandbox. Full device trust uses the connector user's actual permissions.

Read the security model

Familiar interfaces, one policy

Bring your own Agent.

Use MCP, CLI, Skill or SDK. ADC applies the same authorization, device selection and audit trail behind each interface.

Integration guides

Add this URL to an MCP client with OAuth support. Sign in and choose an authorization, or connect with an Agent token.

https://adc.zioon.tech/mcp

Latest

Product progress and engineering notes.

View all updates

Product updateOct 11, 2026Connector 0.1.1: faster mobile control and visible updatesADC 0.1.1 tightens Android UI execution, refreshes long-running MCP sessions and makes outdated desktop Connectors visible without blocking CLI work.Product updateSep 29, 2026A public knowledge base for an open-source device cloudADC now publishes indexable documentation, release notes and explicit privacy boundaries from the same versioned source.GuideSep 29, 2026From the first device to the first verified tool callPair a Connector, create a narrow Agent authorization and verify the complete execution path.

Roadmap

A clear boundary between available and planned.

Available now

A complete personal device loop

Accounts, macOS/Linux/Windows connectors, local MCP Providers, scoped grants, approvals, audit, MCP OAuth, CLI, Skill and self-hosting.

Production hardening

Signed releases, automatic updates, keychain storage, quotas, retention and external artifact storage.

Later

Teams and broader capabilities

Container isolation, team roles, SSO, SIEM export, Windows and additional local executors.

See the roadmap

Hosted or self-hosted

One product, the same trust model.

Use the hosted preview now, or deploy the same application on your own infrastructure. Both use the same accounts, authorization, approvals, audit and device software.

Create an account Self-hosting guide

FAQ

Questions that should have clear answers.

Does the control plane copy my device?

No. It does not crawl or mirror your filesystem. Authorized requests and their returned results pass through the control plane and are recorded for audit.

Is full device trust sandboxed?

No. It deliberately uses the connector user's OS permissions. Use selected folders and narrow tool grants when that level of trust is unnecessary.

What happens when my device sleeps?

New calls report the device as offline. The connector reconnects automatically after the device wakes.

Do I need to reinstall after changing folders?

No. Local folder and access changes reload automatically and immediately narrow affected running work.

Do MCP Provider credentials leave my device?

No. Provider environment variables and HTTP headers stay in the local Connector configuration. The control plane receives tool descriptions and requested results, not Provider credentials.

Connect the tools and environment you already trust.

Start with one device, one folder and one Agent authorization.

Connect a device Read the docs