Security model

OWG treats security as a property of the node, not a system wrapped around the graph. The three classic zero-trust principles map onto the workflow layer directly.

Verify explicitly

Every action attributes to a verified participant. Because agents are participants too — each with an operated_by chain to the human on whose authority it acts — the question "who did this, and on whose say-so" is a query rather than an investigation.

{
  "participants": [
    { "id": "s.okafor", "kind": "human", "role": "vfx-supervisor",
      "organization_id": "org_studio" },
    { "id": "agent_denoise", "kind": "agent",
      "operated_by": "s.okafor",
      "organization_id": "org_studio",
      "identity": {
        "scheme": "did",
        "id": "did:web:example.com:agents:denoise",
        "credential_scope": ["read:assets", "write:outputs"]
      } }
  ]
}

An agent's authority is never ambient. It is a declared edge to a responsible principal, and its credential_scope bounds what it may do. An asset produced by that agent traces to the supervisor and the organization without additional record-keeping.

The generative-AI profile makes operated_by required for agent executors, which is the one place the profile system currently expresses a real constraint.

Least privilege

Permissions attach per object, and the enforcement pattern is the turnover: a vendor receives the subgraph they need and nothing else. Access follows the graph, not the org chart.

Two schema features do the work:

• subgraph on a task scopes what crosses the wall. A vendor gets plates, an EDL, a LUT, and notes — not the show.
• A task's validity window bounds when. Access expires with the task rather than lingering until someone remembers to revoke it.

Together these make access bounded in both scope and time by construction rather than by policy. Nothing is reachable by default, every grant is itself a structural edge in the same graph that records who touched what, and there is no separate access-control system to keep in sync.

This is what makes cross-company work tractable. The vendor's own pipeline stays their business; when the comp returns it does not land in an inbox, it reconnects to the show's graph with lineage attached — which participant, what plate, how many rounds.

Assume breach

The specification's contribution here is narrow: because an asset is addressed by a storage locator rather than by being held in the graph, an implementation is free to place high-consequence content behind a hardened storage tier without the workflow document changing at all.

A locator names a provider and an address. What that provider does behind the address — ordinary object storage, an encrypted store, or a specialised protective tier — is outside this specification. The same document runs against any of them, which is the point: protection is a deployment decision, not a schema decision.

What OWG does require is that the governance record stays with the asset node regardless of where the bytes sit. See Assets and versioning.

The audit trail is the system of record

Approvals, rights, and clearances are graph events with participants and timestamps, not fields overwritten in place. Combined with typed version relations (see Assets and versioning), this means:

• Nothing is overwritten, so nothing needs reconstructing.
• An approval names who approved what, when, and on which version.
• A rejected asset stays in the graph in a rejected state, not as an absence.

Version chains preserve everything. The audit trail is not assembled after an incident; it is the ordinary operating record.

Credentials

A task's executor.credentials_key names a secret held by the orchestrator. Secrets are referenced by key, never inlined, so the workflow document itself stays safe to share, commit, and hand to a vendor.

{
  "id": "dub_es_419",
  "executor": {
    "type": "saas_api",
    "credentials_key": "tts_provider_api_key",
    "permissions": ["read:assets", "write:outputs"]
  }
}

The saas_api profile entry marks credentials_key as required for exactly this reason.

What this specification does and does not do

Worth being precise, because a security model is only useful if its boundaries are clear.

The specification defines what must be expressible:

• Every action attributes to an identified participant.
• An agent's authority is a declared edge to an accountable principal, with a bounded scope.
• Access scope is expressible as a subgraph, and access lifetime as a task's validity window.
• Approvals, rights, and clearances are recorded as events with actors and timestamps.
• Nothing is overwritten; superseded and rejected states are retained.

The specification does not define how any of it is enforced. Authentication, authorization mechanism, policy storage, key management, tenancy isolation, and audit retention are all implementation concerns. Two conformant implementations may enforce the same document very differently, and the specification takes no position on which is adequate for your content.

The practical consequence: a document that expresses a scoped turnover is not the same as a system that enforces one. When evaluating any implementation — including your own — verify enforcement independently of the document format. Expressiveness is a precondition for enforcement, not evidence of it.

If you take one rule from this page: a permission is an edge, and an edge is only as good as the writer that created it and the assurance level it carries.