Data protection in processes

The three classes

Classification belongs to the data itself, not to the node manipulating it. The same node can therefore receive a field normal and a field secret simultaneously without its entire context becoming uniformly secret.

Where classification comes from

A classification may be carried directly by a field contract or inherited from the data from which that field derives.

• Explicit declaration. An input, output, or Form field may declare a protection class.

• Semantic type. Some types carry native protection. For example, common.password is always treated as secret.

• Inheritance. Derived data without an explicit classification keeps the class of the source from which it comes.

Absence of a declaration on derived data therefore does not automatically mean normal. It means “keep the source data's protection”.

For a custom Form field, classification is part of the field definition. For example:

{
"key": "temporary_password",
"label": "Mot de passe temporaire",
"value_type": { "type": "string", "subtype": "common.password" },
"control": "password",
"security": { "class": "secret" }
}

How it propagates

The bindings and expressions pass values between steps. The protection class travels with the value.

Binding direct

input.password [secret]
      ↓ binding
param.password [secret]

The parameter receives the same class as the source path. This also applies to a node output or process variable.

Template or expression

A composed value inherits the most protective class among the protected data it actually depends on.

"Continue: {{ nodes.link.url }}"
                   ↑ secret

template result → secret

Field-level granularity

Protection may apply to one precise field without making the entire object equivalent. For example:

company.legal_name          → normal
company.bank_account.iban   → sensitive

This granularity is also preserved in collections when the contract can identify the relevant fields.

Output without an explicit class

When a node produces an output without explicitly assigning it a more precise class, the output inherits the protection of protected data on which it depends. This prevents a generic transformation from silently removing source sensitivity.

Reduce a classification

Some nodes guarantee that a transformation produces data less sensitive than its input. For example, a node may turn a full bank identifier into its last four characters:

iban [sensitive]
    ↓ transformation
iban_last4 [declared normal]

Ormuz calls this change a classification downgrade. When a process configures such a path, the editor requests explicit consent before saving. Consent is tied to the node, the mapping concerned, and the output contract; a significant wiring change requires new consent.

Consent does not attempt to prove that the business transformation is correct: the designer remains responsible for choosing the transformation and wiring. It does prevent a reduction in protection from being introduced silently.

A write to durable storage declared normal follows the same rule. For example, Set metadata treats every key as a declassification boundary: writing an IBAN sensitive, or a value whose subtype imposes more restrictive Agent access, triggers consent tied to that key and mapping. Changing the source or mapping invalidates that consent. After the consented write, the stored value is normal metadata; it does not automatically re-propagate its source classification.

Inputs and Forms

Protection begins as soon as data enters the process. The main boundaries are:

• inputs supplied when launching a process;
• typed data received from an event;
• values entered in a Form or user action.

When a Form field is classified secret, the submitted value keeps this class when it becomes a node output and when used in subsequent steps. A sensitive field follows the same classification-continuity rule.

Secret constants cannot be saved directly in the process definition. A secret must come from a protected source intended for that use — for example a protected input, integration configuration, or data produced during execution.

Agents and disclosure

An Agent receives protected data through the explicit contract of the invoked activity. For each relevant input, disclosure policy determines whether the Agent receives a controlled projection or the raw value in raw mode when that exposure is authorized.

The same logic applies to tool results. An activity may receive a safe projection by default and access a raw representation only when the tool contract and applicable consents allow it.

For the authority boundary, see Activities, tools, and authority. For process wiring, see Use an Agent in a process.

History and visibility

Generic observability surfaces do not directly display values classified as sensitive or secret. They indicate that protected data is present and its class without making the raw value visible by default.

This protection notably applies to:

• instance inputs;
• inputs and outputs visible in the execution chronology;
• process variables;
• user-action responses;
• process outputs.

The same rule applies to the corresponding generic APIs. A masked value in history is not functionally unavailable: a node explicitly receiving it can use it for the intended operation.

See Observability for instance and chronology monitoring.

Controlled reveal

When a persisted protected value must be inspected for diagnosis, Ormuz provides targeted reveal from observability surfaces. The user selects one precise masked value, provides the requested reason, then views it in a temporary dedicated window. There is never a global “show all sensitive data” mode.

A reveal is:

• limited to the requested value;
• subject to the specific required right;
• audited with its author, context, and reason;
• shown temporarily without turning masked history into a permanent unmasked view.

Some highly ephemeral values are never retained once their use is complete. This is notably expected for one-time codes when no retention is required. In that case, later reveal is impossible: history retains only information useful to understand that the operation occurred.

Retry, fork, and subworkflows

Classification is part of the data context and does not disappear when a process crosses an execution boundary.

• Subworkflow. An input passed to a subprocess keeps its class even when the subprocess schema does not explicitly redeclare it. An explicit declaration in the subprocess nevertheless remains its own contract.

• Retry. A retry preserves protections associated with input data carried over from the original instance.

• Fork. Data carried over at a fork point keeps its protection classes; a fork does not turn protected data into normal data simply because a new instance is created.

Designer responsibility

The protection model limits accidental exposure and makes explicit classification changes visible. It does not replace functional process design.

It is perfectly legitimate to pass secret data to a node that must use it: a token may be required for an external call, a temporary password for a precise action, or a protected identifier for a provider. Ormuz does not block this intentional egress merely because data is secret.

The designer therefore remains responsible for recipients and business uses. The platform guarantees that classification follows the data, generic surfaces respect that protection, and an explicit reduction in classification is not silent.