Add explicit cross-owner artifact handoff without weakening owner isolation

[yyjeqhc]

Problem

Current owner isolation correctly prevents one owner's files/artifacts from being sent directly into another owner's Runner/project context. That fail-closed default is the right security boundary, but future collaboration needs a narrow way to intentionally transfer selected outputs across owners without turning collaboration into ambient cross-owner access.

The first cross-owner capability should be explicit, bounded, auditable Artifact handoff rather than generic shared filesystem/project authority.

Core invariant

Cross-owner access remains denied by default. Collaboration is an explicit capability transfer, not ambient authority expansion.

Possessing a project id, Session id, Artifact path, or guessed object id is never sufficient authority.

Direction

Add a narrow handoff/grant object that lets an authorized source owner delegate one exact frozen Artifact snapshot to one exact destination owner/project.

Today the V1 data plane can identify a source Artifact by an authorized project-relative path plus a Runner-validated snapshot such as byte count, SHA-256, MIME type, and safe name. It should not be assumed that a separate durable artifact_id + version object already exists. If this feature introduces such a durable Artifact record, that record may become the immutable source identity; otherwise the grant itself must freeze the exact validated source snapshot.

Conceptually:

source owner
  -> selects exact source Artifact/path
  -> Server/Runner validates and freezes exact source snapshot
       source owner/project/path
       sha256 / bytes / MIME
  -> creates bounded handoff grant
       target owner/project
       expiry / single-use policy
       allowed operation = import/read
  -> Server records grant + provenance

destination owner
  -> presents/accepts exact grant
  -> Server revalidates target identity and grant state
  -> imports/references only the exact frozen source snapshot

Do not use a mutable source Runner filesystem path by itself as the delegation primitive. The grant must bind to immutable source evidence: either a durable Artifact record introduced for this purpose or the exact frozen source snapshot (source owner/project/path + sha256 + bytes + MIME). If the source path later resolves to different bytes, acceptance/transfer must fail stale rather than silently transferring the replacement content, unless the original bytes were already captured into a Server-controlled immutable data-plane object.

Grant semantics

The MVP should define:

• stable grant/handoff id;
• exact source owner/project and immutable Artifact snapshot identity (or durable Artifact record/version if introduced);
• source SHA-256, byte count and validated MIME/provenance needed to fence replacement content;
• exact destination owner and, preferably, destination Project when known;
• allowed operation(s), initially read/import only;
• created/accepted/consumed/revoked/expired state;
• expiry and optional one-shot consumption;
• bounded provenance/audit metadata;
• idempotent accept/import behavior.

A stale source snapshot, revoked, expired, already-consumed one-shot, wrong-owner, or wrong-project grant must fail closed.

Data-plane behavior

Prefer Server-controlled Artifact transfer/reference semantics rather than routing raw bytes through model output.

The destination should receive a new destination-owned imported Artifact/file result with provenance pointing back to the source grant and frozen source snapshot. The source owner should not thereby gain access to the destination project, and the destination owner should not gain access to unrelated source files/artifacts.

Large payloads must reuse existing streaming/chunked/resource mechanisms and their bounds.

Security and privacy

• Never transfer source credentials, environment variables, private auth material, or filesystem authority with the Artifact.
• Existing sensitive-path/content policy still applies before a handoff can be created.
• Audit should identify source owner, destination owner/project, exact frozen Artifact snapshot/grant state transition and result without logging raw Artifact bytes.
• Revocation must prevent unused grants from being accepted later.
• A failed/indeterminate transfer must have explicit state; do not silently create multiple destination copies on retry.

Collaboration integration

Later Workflow Session/message collaboration may reference a handoff grant or destination Artifact id/path, but a session message itself must not confer cross-owner authority.

This capability can later be generalized to other explicitly delegable objects if real dogfood justifies it; do not start with a generic ACL/delegation framework.

Acceptance criteria

• Source owner cannot directly import/send an Artifact into another owner's project without an explicit grant.
• Source owner can create a grant for one exact validated and frozen source Artifact snapshot to one exact destination owner/project.
• Replacing the source path with different bytes after grant creation cannot silently change what the grant transfers; the operation either uses the frozen immutable data-plane object or fails stale on snapshot mismatch.
• Destination owner can accept/import only that exact snapshot and receives source provenance/hash metadata.
• Destination cannot use the grant to enumerate/read other source Artifacts or Projects.
• Source cannot use the grant to access the destination Project.
• Wrong owner/project, expired, revoked and stale grants fail closed.
• One-shot grant replay is idempotent and does not create duplicate imports.
• Transfer failure/unknown outcome has a recoverable explicit state.
• Audit records the handoff lifecycle without raw bytes or credentials.
• Large Artifacts retain existing bounded/streaming semantics.

Non-goals

• shared cross-owner filesystem mounts;
• granting one owner ambient access to another owner's Runner or Project;
• generic organization/team RBAC redesign;
• automatic collaboration trust based on being in the same Session;
• transferring secrets or credentials;
• arbitrary object delegation beyond Artifact handoff in the MVP.