Security Considerations

A Workfile composes operations that can read or change external systems. Static validation limits what a document can express and discovers declared requirements before execution, but it does not authorize a workflow, establish the trustworthiness of a catalog artifact, or replace deployment access control.

Hosting Responsibilities

These responsibilities belong to implementations hosting workflows or retaining run data. They are operational responsibilities outside the portable suite’s observations; the observable security requirements in the following subsections remain part of implementation conformance.

An implementation hosting workflow activation or execution is responsible for authenticating authors and operators, authorizing workflow activation and invocation, protecting stored and in-transit data, and limiting access to definitions, connections, event payloads, run state, and history.

An implementation retaining run data is responsible for access control, encryption, and deletion of that data.

Credentials and Sensitive Values

Credentials and connection fields are deployment configuration. They MUST NOT enter workflow scope, be exposed to expressions, templates, agents, connector arguments, diagnostics, or ordinary run history, or be included in a catalog artifact.

An executor MUST pass credential material only to the resolved connector implementation for the selected connection. Implementations MUST prevent one workflow, connector, connection, or tenant from obtaining credentials assigned to another unless deployment policy expressly authorizes that use.

Before trigger activation or action dispatch, a deployment that can determine granted scopes MUST enforce the manifest’s required scopes as specified by Connector Manifests. Scope declarations are a requested-privilege contract, not proof that the connector uses credentials safely.

Implementations managing connections SHOULD grant each connection only the scopes needed by the workflows bound to it and SHOULD require renewed authorization when a resolved definition adds a scope or write effect. A field declared sensitive remains an ordinary readable value during execution.

The sensitive designation controls display, export, and retention as specified under Field Declarations; it does not encrypt the value, prevent an action or explicitly projected agent context from receiving it, or taint values derived from it. An implementation MUST apply withholding to every retained representation it controls, including diagnostics and profile history, and MUST NOT substitute the withheld marker for the live value before an operation that is entitled to read it.

Note. Authors can copy sensitive values into nonsensitive fields; sensitivity does not propagate to those copies.

Untrusted Inputs and Payloads

Implementations MUST treat workflow inputs, trigger payloads, action results, connector error details, catalog documents, templates, filter packages, agent text, and replay history as potentially untrusted. Implementations MUST validate each at the boundary and against the exact resolved declaration before using it.

A value’s successful type validation does not make its text trusted instructions, markup, a path, a host, code, or a connector reference. Interpolation and expression evaluation MUST treat data as values and MUST NOT parse generated text as an expression, operation key, template directive, capability declaration, or document fragment.

Structural positions that select actions, triggers, callees, templates, or agents are literal where their defining sections require them to be literal. Implementations MUST NOT add an evaluation mechanism that lets runtime data alter those selections while claiming base behavior.

Template escaping protects only the context declared by wf.render. The text context performs no escaping, and an escaped result is not necessarily safe in a different or nested language context.

An implementation MUST apply the specified escaping exactly and MUST NOT offer an unregistered bypass. HTML context emits safe_html unchanged only because its producing operation’s resolved contract establishes that designation. An implementation MUST NOT accept an ordinary string, including an untrusted string, as asserting that designation.

Authors remain responsible for selecting a context appropriate to the eventual sink; connector implementations remain responsible for parameterization and validation at that sink. Manifest operational declarations and filter-package purity promises are trusted contracts after format validation and cannot in general be verified from the manifest alone.

An implementation selecting or executing artifacts SHOULD resolve artifacts only from sources it trusts, verify their identity and signatures when available, isolate executable connector and filter implementations according to their authority, and treat a change of pinned content as a new security-review surface.

Network and File Access

A Workfile MUST NOT directly select a connector destination. Connector addresses and credentials come from deployment connections, and a connection field used in a host MUST satisfy its manifest pattern.

For self_hosted connectors and every other deployment-selectable destination, the implementation connecting to the destination MUST apply a documented host-access policy. That policy SHOULD deny loopback, link-local, multicast, unspecified, and private-use addresses unless expressly allowed for that connection, and SHOULD restrict schemes, ports, redirects, proxies, and name resolution to those required by the connector.

Schema evaluation and expressions remain subject to their defining purity rules; templates during evaluation and filter packages MUST NOT perform network or filesystem access.

Project content used as part of a workflow definition is read only during resolution under Catalog and Packaging. An implementation MUST validate and execute the pinned bytes rather than reread content from a path or storage location that might have changed.

A file value is an opaque content reference, not a filesystem path or authority token. Merely possessing it grants only the operations defined by Workfile evaluation; a connector or profile operation that dereferences it MUST be separately authorized and MUST enforce deployment policy.

Implementations MUST NOT interpret $file, file metadata, workflow strings, or action results as host paths unless a standard or claimed profile expressly defines that operation.

Agents

Agents are optional, nondeterministic trust boundaries and MUST NOT be treated as base expressions. An executor MUST NOT execute an agent unless wf.agent-execution is supported and authorized.

Validation of goals, schemas, allowlists, and budgets does not establish that model output is benign.

An agent receives only its evaluated goal and with projection and can act only through its declared tools. Instructions contained in those values or in tool results are untrusted and MUST NOT expand readable context, tools, credentials, budgets, or network and filesystem access.

The executor MUST mediate and validate every tool call rather than relying on the agent to honor its allowlist. A sensitive value included deliberately in with is disclosed to the resolved agent runtime; executors SHOULD require policy authorization for that disclosure and for every effectful tool.

Implementations SHOULD isolate agent sessions from one another and from connector implementations, destroy transient context after its required lifetime, and prevent provider or runtime defaults from adding logging, training use, tools, environment access, or retention contrary to deployment policy. These controls are responsibilities of the implementation hosting the agent unless a claimed capability or profile states a stricter normative requirement.

Resource Limits

An implementation MAY impose finite limits on document bytes, nesting, collection lengths, expressions, templates, concurrent work, bound values, run steps, retention, action duration, and other exhaustible resources. A documented call-depth limit MAY be stricter than, but MUST NOT exceed, the maximum defined under wf.call.

An implementation MUST document every limit that can cause a conforming workflow to be unsupported or to fail, including its unit, scope, and consequence. An implementation determining deployment support MUST make any stricter deployment policy limits available with that determination.

A limit exceeded entirely by the source or resolved definition MUST be reported before execution as an unsupported target or validation error according to the provision defining that limit. A limit that depends on runtime input or consumption MUST produce the registered stable outcome or fault at the operation that exceeds it.

Implementations MUST NOT truncate a value, collection, iteration, output, history record, or event silently; convert exhaustion into success; or discard accepted durable state while claiming it remains resumable. Limits MUST be enforced across retries, recovery, child runs, agents, concurrent branches, trigger queues, batches, and other nested work so that composition cannot bypass them.

Cancellation or exhaustion SHOULD release implementation resources promptly, but release MUST preserve any outcome, idempotency, accepted-event, ambiguity, or durable-history information required by an applicable document format, capability, or profile. Implementations SHOULD bound parsing and validation work for hostile inputs and use algorithms with the complexity guarantees required by this specification, including linear-time regular-expression matching.