StackStorm automates actions across infrastructure and SaaS tools. An API key or authentication token can trigger those actions, and RBAC evaluates the effective user. The key itself is only one part of the path. The user, assigned roles, action permissions, and execution context determine what the automation engine can change.
Authentication selects the principal
StackStorm documentation says the API accepts either an authentication token or an API key in request headers, but not both. The authenticated principal becomes the effective user for normal API-triggered executions. RBAC then evaluates role assignments and permissions.
API keys are convenient for webhooks and service integrations, but they should not be treated as anonymous triggers. Create a dedicated user for each integration, assign only the required roles, and record the key's owner.
Review the action path
An allowed action execution can reach a remote system with credentials stored in a key-value store, pack configuration, or external secret manager. Review both the StackStorm permission and the target credential. A user who cannot read a secret directly may still be able to execute an action that uses it.
Limit who can create or modify actions, rules, workflows, and packs. A contributor who can change an action definition may alter what a privileged workflow executes. Code review and pack signing or repository trust are part of the control plane.
What the ZoomEye observation shows
The count-only queries used sub_type=all, page 1, and page size 1. app="StackStorm" returned 0, title="StackStorm" returned 1,191, and http.body="StackStorm" returned 1,486.
The title and body values are close, which suggests a more distinctive product phrase than a short acronym, but the result still does not prove an exposed or operational service. The zero application fingerprint is a valid query result and not a failure.
Use the values to compare public references with owned domains, cloud inventory, and certificate records. Do not probe unknown API endpoints.
Test RBAC boundaries
Create a test key for a limited user and attempt an allowed execution followed by a denied one. Verify that the API returns an authorization failure and that the audit record names the effective user. Repeat the test through webhooks and any automation that triggers executions indirectly.
Check whether a role assignment change affects existing keys. Revoke a key and confirm that a new request fails. Review the audit trail for action registration, pack deployment, rule changes, and credential updates.
Respond to key exposure
Delete the compromised key, disable the associated user if necessary, and review executions attributed to that principal. Compare the action history with expected schedules. Rotate any downstream credential the action could use if the investigation suggests execution or data access.
StackStorm concentrates operational authority. API-key management is therefore part of change control, not just secrets hygiene. The team needs to know which key can execute which action and which stored credential the action will use.