Security and controls
Automation You Can Describe to an Auditor.
Operations automation holds credentials to the systems that matter most. The controls below are enforced by the platform's architecture rather than requested in a prompt — because the difference matters the first time something unexpected arrives in a ticket.
- Interpretation proposes, policy permits, verification confirms
- No general-purpose shell — registered actions only
- Credentials resolved server-side, never in a model context
The central idea
Interpretation and authority are different jobs.
Language models are genuinely good at interpretation: reading prose, recognising a pattern, summarising a situation, matching a description to a known case. They are the wrong mechanism for deciding what is permitted to happen to a production system.
Most of what goes wrong in AI operations comes from collapsing those two roles. So we separated them structurally. The interpretation layer produces a structured proposal with a confidence score. A deterministic policy layer decides whether anything may act on it.
That boundary is why we can tell you the blast radius of a workflow in a sentence, and why widening its scope is a decision you make rather than something that drifts.
What the interpretation layer cannot do
- Select an action that is not in the registered catalogue
- Alter or bypass policy evaluation
- Resolve or read a credential
- Change the tenant, environment or asset scope a run is bound to
- Mark an outcome verified without the assertion passing
Controls
Eight controls, all enforced by the platform.
Each one exists because of a specific failure mode we are not willing to leave open.
Registered actions only
A workflow composes from an action catalogue you control. Each action declares a typed input schema, the credential it resolves, whether it reads or writes, whether it is retry-safe, and how many assets one invocation may affect. There is no general-purpose shell action.
Policy evaluated in code
Whether an action may run on an asset, for a requester, in an environment, right now is a deterministic evaluation. It is not model output, not a prompt instruction, and not inferable from the content of a ticket.
Separation of duties
Author, publish, run and approve are distinct roles. The pairs that matter most to keep apart are author/publish and run/approve — one person holding both halves removes the control, and the model makes that visible.
Server-side secrets
Credentials are stored encrypted, referenced by name, and resolved by the execution runner at the moment of use. They never appear in a workflow definition, in run history, or in any context passed to the AI layer.
Blast-radius limits
Cap how many assets a single remediation may touch and how often it may run. A repeat-run detector escalates rather than re-applying a fix that is not holding.
Approvals with fail-safe timeouts
Any action can require a named approver, who sees the resolved asset set and the exact parameters. Every approval declares a timeout action — and “continue anyway” is deliberately not the default.
Verification as a separate assertion
Outcomes are asserted against measured state rather than inferred from exit codes. “Unverified” is a distinct result from both failed and successful, and it escalates.
Immutable run history
Trigger, payload, identity, workflow version, resolved scope, every step's inputs and outputs, branch decisions, approvals and verification results — recorded append-only and exportable for audit.
Identity
Roles that make delegation safe.
The point of the role model is that you can give someone the ability to run an operation without giving them the credential behind it.
- Author
- Writes and edits workflow definitions. Cannot publish them.
- Publisher
- Publishes a workflow version, making it runnable.
- Operator
- Triggers published workflows within permitted environments and tenants.
- Approver
- Approves held steps. Scoped by action, environment or tenant.
- Administrator
- Manages the action catalogue, connectors, credentials and role assignments.
Deployment
Keep execution where your constraints require.
The control plane and the execution runners are placed independently, so credentials and command execution can stay entirely inside your network.
StackHeal cloud
Control plane and runners hosted by StackHeal. Your systems are reached over authenticated outbound connections.
Private execution runners
Runners inside your network. Credentials and command execution never leave your environment; no inbound firewall rules required.
Self-hosted
Control plane and runners both in your environment, for residency, air-gapping or compliance requirements.
Compliance
What we will not put on this page.
You will not find a row of certification badges here. Publishing a compliance logo you have not earned is the kind of thing that ends an evaluation badly, and a badge grid tells you nothing about whether a specific control applies to your deployment.
Ask our team where our compliance programme stands and we will tell you specifically: what is complete, what is in progress, what is scoped and what is not started. If you need something we do not have yet, you should know that before you start an evaluation, not after.
About this website
This site is the StackHeal marketing and documentation front end. It stores no credentials, holds no customer data, and connects to none of the systems described here. The only server behaviour is contact-form validation and an optional webhook forward — see the security documentation and the repository README.
Security questions
Something not covered here? Ask our team.
Bring us your hardest control requirement.
If there is a constraint that usually rules automation out — change control, residency, separation of duties, air-gapped execution — tell us early. We would rather tell you no than discover it in month three.