Skip to content

Security

How Clone is designed to protect company data: enforcement outside the model, secret references, approvals, audit and isolated networking.

Clone is in development. Nothing customer-facing is generally available yet.

This page describes a security design that is still to be proven. The design is not evidence of production readiness.

Enforcement sits outside the model

Security must be enforced outside model prompts. The design checks identity, action, destination, current policy and inherited information restrictions at execution time.

Browser, network and shell access must not bypass that boundary.

The system must enforce security even when the model produces an unsafe action.

Source: web/src/content/docs/administration-and-security.ts, docs/security.md

One company boundary, two kinds of permission

A Clone uses its own accounts. The company determines what it may access and do, and its person can configure behavior within that boundary.

Action permissions decide whether a Clone may read, write, communicate, execute, delegate, create accounts or spend.

Information restrictions are separate. They decide how information already observed limits later destinations and actions.

Being permitted to read a document does not imply being permitted to share it or act on it without limits.

Source: docs/security.md

Information restrictions follow the data

The intended behavior is similar to classified information handling: an agent may read sensitive material, but doing so can remove capabilities for that session.

The organization defines what context is sensitive. Agents handling that context must have outbound internet disabled before receiving it, and internet-enabled work runs in a separate environment without access to it.

Derived outputs and handoffs keep those restrictions unless the organization authorizes release.

Restrictions are not removed merely because a conversation was reset or summarized.

This enforcement is proposed. It is not implemented capability.

Source: docs/security.md

Secrets are references, never context

This is the current credentials design. No live vault adapter has been validated.

The agent should use references such as {{email}}. The application holds the actual values in secret storage and resolves them only during authorized execution.

Each use is to be bound to an approved service, destination and operation, so a password reference must not resolve into an arbitrary message, URL, command or attacker-controlled login page.

The model sees a reference and a label. A trusted broker resolves the value at action time and fills it straight into a surface or outbound request. Nothing downstream of the broker (events, logs, transcripts, frames, errors, approvals) carries the value.

Remaining exposure is documented, not hidden: the target site itself receives the secret, the browser process holds it in memory, and screenshots from a compromised driver are out of this design’s control.

Source: docs/credentials.md, docs/security.md

The vault, and human reveal

The credentials design has Clone host its own vault by default. Each person and their Clone are to get a shared vault they can see on a Vault page in the apps. No live vault adapter has been validated.

In the design, a person viewing a credential is a different flow, with separate authority, MFA and audit. It is never routed through the agent.

In the accounts library, a reveal is permitted only for the assigned person, or an Owner or Admin who gives a reason. Its ticket expires after 60 seconds, and redeeming it consumes it.

Every reveal request and redemption, including denials, is recorded. The event schema contains no credential value field.

Source: docs/credentials.md, crates/accounts/README.md

An approval binds one exact action

Company prohibitions override user preferences. An approval can authorize only what company policy allows that person to approve.

Proposed approval records identify the requester, action, target, relevant content or transaction details, expiry and decision.

An approval for one action must not silently authorize a modified action or a repeated execution.

In the policy library, authorization re-evaluates immediately before execution. A decision requires the exact digest shown to the person and rejects requester self-approval. Changed actions and expired, denied or replayed approvals are rejected.

Source: docs/security.md, crates/policy/README.md

The shared computer is not a security boundary

Human takeover does not stop the Clone or its other workers. Each worker’s ability to observe a screen, send input, read shared files or use an account must still be permissioned.

Seeing sensitive content on a human-controlled screen counts as receiving that information and must carry its restrictions forward.

Separate displays are not, by themselves, a security boundary. Shared files, processes, clipboard contents, browser profiles and network access each need defined isolation and policy enforcement.

Source: docs/security.md

Default-deny networking

This section describes a proposed implementation plan, not deployed capability.

The plan gives each VM its own isolated network namespace and a mandatory outbound web gateway, with no unrestricted guest NAT, no bridge to the GCP VPC and no public guest ports.

New or unclassified environments default to offline, with no outbound internet and no external DNS, until policy admits a profile.

Approved destinations are exact hostname and port rules. General browsing needs an explicit company-authorized public web profile, suitable only for data permitted to leave to arbitrary public sites.

Source: docs/engineering/vm-networking-plan.md

What is recorded

The credentials design keeps an append-only record of every resolve and denial: company, Clone, task, worker, reference, origin, mode, decision, approval ID and result. It holds no values.

Creating and revoking a credential grant both leave audit rows.

Network decisions are to record allow or deny, bounded destination metadata, reason, revision, connection timing and byte totals. Default logs hold no request bodies, cookies, authorization headers, URL query strings or full DNS payloads.

The networking plan targets GCP in Sydney for enforcement, policy state and audit storage.

Placeholder, not page copy

[PLACEHOLDER for Justus: confirm the data-residency sentence and list the approved external-provider exceptions]

Source: docs/credentials.md, crates/credentials/README.md, docs/engineering/vm-networking-plan.md

What is not proven yet

There is no generally available provisioning or administration service. The initial prototype’s policy work does not establish production account lifecycle support.

The policy library has no persistence or core/runtime integration yet, no production secret storage and no enforcement of OS or network isolation.

Separate screens are not sufficient isolation for sensitive data. Handling real sensitive workloads requires boundary tests.

Placeholder, not page copy

[PLACEHOLDER for Justus: certifications or independent audits to cite, if any]

Placeholder, not page copy

[PLACEHOLDER for Justus: whether to publish an uptime or SLA commitment]

Source: web/src/content/docs/administration-and-security.ts, crates/policy/README.md

Contact

Placeholder, not page copy

[PLACEHOLDER for Justus: security contact or vulnerability-disclosure address and policy]

Placeholder, not page copy

[PLACEHOLDER for Justus: legal entity name and registered address for the “who we are” line]