The first is secrets + credentials. You can use our hosted vault or bring your own vault so that your credentials are encrypted and can only be accessed directly by your user code.

The next ACL - we set up teams so that you can control which Slack channels (private or public) they can run in, to deeply control who has access to the workflow. Even if someone has access to the workflow, they can't see the secret as if it's printed, we remove it from the output. Additionally, we push your user outside of Slack (browser or CLI) to manage secrets.

Next, is the actual PaaS itself. Slack doesn't know what's being run, they just send us a webhook and we deal with executing the workload, completely outside Slack. Slack is just a client, it doesn't really know anything about your systems or workflows.

Next is the shared workflow environment, which has multiple layers of virtual sandboxing to ensure, what runs inside your container, only runs inside your container. You can make requests to external wide area network io or inside your container to disk. All of this goes through a sidecar type analysis that we use to ensure security at a very granular level for anything that runs inside these systems.

Lastly, Slack never has access to your code. They are simply the client which tells our platform to run it and in a secure enterprise case, our PaaS can run inside your VPC, which gives you full control end to end as long as you are willing to let Slack send you HTTP request - but this is a standard expectation for any Slack app, we just dramatically simplify it.

I've been thinking about doing a detailed blog post about this in the near future, so i really appreciate these questions!