Platform
Security and permissions
Roles, separation of duties, secret handling and what the interpretation layer can and cannot reach.
Operations automation holds credentials to the systems that matter most. The permission model is built around separating the ability to run an action from possession of the credential behind it.
Roles
- Author — can write and edit workflow definitions, but not publish them.
- Publisher — can publish a workflow version, making it runnable.
- Operator — can trigger published workflows within permitted environments and tenants.
- Approver — can approve held steps. Scoped by action, environment or tenant.
- Administrator — manages the action catalogue, connectors, credentials and role assignments.
Separation matters most between Author and Publisher, and between Operator and Approver. A single person holding both halves of either pair removes the control.
Secret handling
- Credentials are stored encrypted and referenced by name.
- They are resolved by the execution runner at the moment of use.
- They are never written to workflow definitions or run history.
- They are never included in any context passed to the interpretation layer.
What the interpretation layer can reach
It receives the request text and the outputs of read actions that the workflow already ran. It can propose an intent, a matched runbook and a draft response. It cannot select an action outside the catalogue, cannot alter policy evaluation, cannot resolve a credential, and cannot change the tenant or asset scope a run is bound to.
On untrusted input
Model training
Customer data is not used to train models shared across StackHeal customers. Model hosting and residency options are available on enterprise deployments.
Scope of this documentation