Building CanopyRig, questioning the filesystem, and exploring how humans and agents share a world.
An agent I was working with needed to modify a protected system configuration file. It couldn’t simply use sudo. But it had access to Docker, and by launching a container with a writable bind mount of the host filesystem, it found another route to the file.
It had found a way to accomplish the task. It had also exposed a gap in the boundary I thought existed. Restricting one command had left another route to the same authority available.
I’ve spent much of this year building CanopyRig, a platform for building and running platforms. DCC Platform, the creative-production suite growing out of my pipeline work, is its first client. Working on identity, deployment, execution and storage together has increasingly become an investigation into who is actually using the computer.
An agent can interpret an objective, choose tools, inspect results, change its approach and continue while I’m elsewhere. It can delegate work. It can encounter hostile instructions. And it can make a locally plausible change in entirely the wrong part of an architecture.
At Microsoft’s October Windows event, Satya Nadella described agents becoming the filesystem’s largest users. That caught my attention because I keep encountering the consequences in systems I’m building now.
Files are an extraordinarily successful interface. The harder question is how many independent actors can use that interface without inheriting one another’s authority or making every intermediate change everyone else’s problem.
Working for someone is a relationship the system needs to understand.
The familiar desktop experience is built around a person signing in and operating tools. Applications receive access through the user, the application or the process. The human directs the work; the operating system manages the resources.
Computing has always had multiple users, service accounts, background processes and isolated environments. Delegated authority has a long history too. Agents bring these questions into ordinary work, with software choosing its own next action and continuing through time.
An agent may share my objective without sharing my judgment. It may need some of my resources without needing all my authority. If it makes a mistake, I want to restrict that agent’s access while continuing my own work.
That requires the system to keep two identities distinct: the actor carrying out the action, and the person or organisation whose authority it exercises. A shared login or a valid process credential doesn’t fully describe that relationship.
The Docker incident made this concrete. A boundary around one tool only tells me about that tool. The effective authority comes from every reachable route: subprocesses, mounted resources, service credentials, remote APIs and whatever those capabilities can invoke in turn.
An instruction to avoid a directory can communicate intent. Enforcement has to happen where access is granted. And the record of an action needs to say who acted, for whom, with which grant.
In The Agentic Web, I wrote about services becoming directly addressable by agents. The question here follows from that: once an agent can reach a capability, whose authority makes the call legitimate?
Independent work needs a stable view of what it is working on.
Imagine three agents working on a Rust workspace. One implements a feature, another refactors a dependency, and a third runs tests and investigates failures.
If they share a writable directory, the test runner can encounter a mixture of unfinished changes. One agent can overwrite work it didn’t know was in progress. A build can begin against one state and finish against another.
I’ve also seen an agent make a change at the wrong architectural layer. The code works locally, but the responsibilities have moved somewhere they don’t belong. Tests may catch the resulting behaviour; they won’t necessarily catch the architectural decision.
Worktrees, snapshots, version control and orchestration already help with these problems. The possibility I’m pursuing is to make the relationship between an actor and its view of shared state explicit throughout the platform.
The implementation agent needs enough context to understand the whole workspace, permission to change its assigned crate, and a stable base to change it against. The reviewer needs to compare the proposal with accepted state. The deployment service needs the approved artifact and the evidence that it passed its checks.
Those are different views and different operations over related information. They needn’t require complete copies of everything, and they shouldn’t depend on an agent remembering which files it was told to leave alone.
This began for me with creative work. In The Application That Builds Itself Forever, the test case was several agents working on one 3D scene without ruining each other’s work. A tool could move an object or read a material. What was missing was an account of the world being changed: what depended on the object, who else was working on it, and which changes had become accepted.
Source code has Git. A scene has objects, materials, references and assets whose relationships matter to a merge. Giving each actor a branch is only the beginning; the system still has to understand what it means to combine their changes.
This is why the storage question matters to DCC Platform. The format work exposes content inside creative files. The platform needs to preserve its identities, relationships and history as people and agents work on it.
For any accepted change, I want to know which actor made it, what it was trying to accomplish, the authority it used, and the state it started from. I want to distinguish a discarded experiment from an accepted edit and an intermediate output from a deployed artifact.
A timestamp or an owner field answers part of that. The rest lives in the relationships between resources, proposals, decisions, builds and releases. That is the point at which the current contents of a directory stop being enough to describe the work.
Each part owns a different piece of the answer.
CanopyRig is distributed infrastructure: it builds, places and runs the platforms hosted on it. Its components have distinct responsibilities, connected through a shared SDK and typed operations that people, services and agents can use.
The separation is consequential. Writing code doesn’t confer deployment authority. A deployment receipt doesn’t make Rig the owner of another service’s state. A declared goal doesn’t mean Canopy should hold every runtime fact or sit in every request’s path.
The SDK is how these capabilities reach the pieces built on the platform. The same records and operations should remain useful in a desktop app, on one host or across several nodes. A change of execution location should preserve the actor’s identity and the limits of its delegation.
The core identity and entitlement machinery, Rig’s build and deployment work, Spindle’s gear hosting, and the record and content machinery in DnB are implemented, with migrations and integration still underway. Humans use passkeys; agents and services use cryptographic identities and explicit bindings to the authority they exercise.
The independently governed views described in this article are a design direction. A filesystem projection spanning the suite, complete scene-merge semantics, and seamless movement of every workload with its state remain work to prove. The existence of the components doesn’t establish all the properties of their composition.
DnB gives me a starting point richer than a tree of files: resources with stable identities, committed changes, current state and history, with content retrieved and checked by hash. Events support reaction to change; they aren’t the only representation the system holds.
The filesystem can then become a projection of those records, preserving an interface existing tools understand while allowing the underlying model to carry more of what the work means.
A familiar interface over a richer account of the world.
A path is a useful way to reach a resource. The resource can also have an identity that survives a rename, a history of committed versions, and relationships that aren’t fully expressed by its place in a directory.
That makes several views possible over common underlying data:
A tool could still open a path, read bytes and write a result. The projection would decide which version the actor sees, where its writes land, and which operations its delegation permits. Promotion into accepted state would be a separate, attributable act.
These are familiar ideas from databases and version control, applied to the shared world the platform holds. The opportunity is to make them available consistently across formats and tools, with authority carried through the operations.
A virtual filesystem governs only the access that passes through it. If an actor can reach the backing store directly or obtain a broader service credential, that route must be constrained too. Otherwise the Docker problem has simply moved downstairs.
Revocation needs equally careful semantics. Closing future access cannot make an actor forget bytes it has already read. An open handle, a cached copy and a new request are different cases. The system needs to say which operations a revoked grant stops, and enforce that answer.
Content addressing establishes the identity of bytes. Transaction isolation, safe merging and trustworthy provenance need their own mechanisms. Recording a claimed purpose doesn’t prove that purpose was followed. A policy system also has to stay fast enough to use and clear enough for a person to understand.
Those are the engineering problems this direction exposes. They are also useful tests of whether the model is doing more than adding vocabulary.
Different systems are encountering parts of the same problem.
The industry developments that interest me are the ones that make these boundaries concrete. They address different environments, but each helps clarify a part of the problem.
Microsoft’s October 7 announcement describes containment, identity and manageability as distinct requirements. Microsoft Execution Containers are generally available, enforcing declared file and network access at runtime. Broader Entra and Agent 365 attribution is described as coming soon: it should allow restrictions on an agent without blocking the employee’s access.
That distinction between available containment and forthcoming governance matters. It also illustrates why identity and enforcement have to meet: knowing which agent acted is useful only if the system can apply the relevant consequences to that actor.
The hybrid-intelligence announcement also names Meta’s forthcoming Muse for Windows with MXC integration. It is another example of an agent depending on a boundary enforced by the environment it runs in.
Worker Previews give Git branches production-like environments with their own code, configuration, URL and observability, and isolate Durable Objects and Containers per branch.
The connection to my work is independent state. An experiment needs somewhere to run, fail and be revised before its changes become production’s changes. A preview environment and an authorized filesystem projection operate at different layers, but both give work a boundary before promotion.
OpenAPPA tracks information flow across an agent’s trajectory. Reading a confidential source constrains the audience to which subsequent information may flow; reading an untrusted source affects its trust label.
That adds a question beyond whether an actor may read a document or send a message. Permission to do both separately doesn’t establish permission to send the document’s contents in the message.
An authorized view controls access to resources. Information-flow policy concerns what happens after information has been read. A shared working environment may need both, with explicit conditions for releasing information to a wider audience.
Useful autonomy includes knowing where human authority is required.
Recently, an agent I was working with needed to authenticate to Steam. It presented a QR code; I scanned it in Steam on my phone and completed authentication through a device I controlled. The workflow continued.
The agent reached a boundary, and the person with the relevant authority performed the action required to cross it.
That was a discrete authentication event. In Authenticated Presence Sessions, I explored a further possibility: authenticated human presence as a live, revocable condition of access.
An agent might inspect a project and prepare a deployment while I’m away. Publication could require a specific human authorization. Certain protected resources might remain available only while an authenticated presence condition holds. These are different policies; a sign-in event alone doesn’t establish continued presence or consent to every later action.
The aim is to put intervention where the consequence warrants it. A model’s promise to ask is insufficient; the infrastructure granting access has to require the condition. That leaves useful work free to continue within the scope already delegated.
A workflow can use a cloud model to plan, a local model to inspect data, a desktop tool to make an artifact and a remote service to publish it. To the person, it may feel like one activity. To the architecture, it crosses several trust domains.
Hopper connects nodes by identity. The harder promise is that the operation arriving at the next node retains its attributable actor and bounded authority. Sending a file to a cloud model also changes who can receive its information; locality and access have to be considered together.
This is the distributed-infrastructure side of the same problem Windows encounters on the desktop. Each environment needs enforcement of its own, and the delegation between them needs to remain legible.
The next proof is a shared workload: actors working against stable views, changes promoted deliberately, and a record connecting the result to its source, validation and authority. Revoking a grant should stop the operations it governs. Moving work to another node should preserve those limits. The human should be able to understand and intervene in the process.
I want to prove that on creative data as well as code. Several actors changing a scene will test much more than whether a mount can present files. It will test whether the system understands enough of the relationships to preserve the work.
The operating system is learning who is acting. The resource layer needs to understand what each actor may see and change. The infrastructure connecting them needs to preserve those relationships as the work moves.
That’s the direction I’m building toward with CanopyRig.