As we lean on automation more, I need to be able to show what ran, who did what, and why. What audit and compliance features should security teams be using in 3B? I’m curious what’s captured automatically and what I should set up deliberately. A rundown of what’s available would help me build with accountability in mind.
Great question, and it’s the right lens to build with from the start. Accountability is much easier to design in than to bolt on later.
Here’s how I’d split it: what the platform captures for you automatically, and what you set up deliberately.
What you get automatically. Every run of a workflow is recorded, along with the executions inside it, so there’s a durable trail of what ran and when. Each execution keeps its output and its logs, which is your “what actually happened” record: the data that went in, what came back, and where something errored. So the raw “what ran” history is there without you doing anything, and you can go back and inspect a specific run after the fact. Changes to a workflow are tracked too, since builds are versioned, which gives you a sense of who changed the automation and when.
What to set up deliberately. This is where the “who did what, and why” really gets sharp.
Think about your route auth. Anything with an exposed endpoint should be behind proper authentication (space or tenant scope) rather than open, so you can actually attribute who or what triggered a run. An open public route is the classic accountability gap: things ran, but you can’t say who kicked them off.
Handle credentials through connectors rather than hardcoded keys. Beyond the security win, it means access is granted at the connector level and can be rotated and reasoned about, instead of secrets being scattered through code where no one can audit them.
Log deliberately for the decisions that matter. The automatic logs capture execution mechanics, but the “why” often needs you to write it. When a workflow branches on a decision, especially an automated one like escalate versus suppress, log the reason: what the inputs were, what rule or score drove the choice, and what it did as a result. That turns “the system closed this alert” into “the system closed this alert because all three sources returned benign.” That narrative is what auditors and incident reviewers actually want.
For anything sensitive, add human-in-the-loop checkpoints where a person approves before a consequential action runs. That both creates a clear point of human accountability and gives you a record of who signed off.
Mind what you store. Logs and execution outputs persist, so be intentional about not capturing more sensitive data than you need. Good hygiene now saves a data-handling headache later.
A couple of habits worth adopting. Keep decision logic and its logging in a dedicated step so your “why” lives in one predictable place rather than scattered around. And if you need records to live somewhere central, like a SIEM or a compliance system, treat writing to it as an explicit step in the workflow rather than assuming the platform’s internal history is your system of record.
Short version: the platform gives you the run, execution, log, and version history automatically, so “what ran” is covered. The “who and why” is on you to design in, through authenticated routes, connector-based credentials, deliberate decision logging, human approvals on sensitive actions, and pushing records to your system of record when you need them there.