How do I stop one workflow step from reading another step's secrets?
#The question
"How do I stop one workflow step from reading another step's secrets?" has a structural answer in Swirls. You declare what each agent and tool can touch in .swirls files, and the runtime enforces exactly that scope on every run.
#Who's asking
Security / compliance owner. Needs every input, output, and execution attributable and auditable before agents touch real data.
#Why Swirls is a fit
Each step sees the minimum secrets its declaration authorizes. A node that processes data never sees the API keys the upstream agent uses, and the runtime enforces that scoping at execution time.
Credentials only narrow. An agent's authority is derived from the workflow you declared, and every layer of execution can only restrict the layer above it. There is no path for an agent to escalate its own access.
The security model names the primitives behind these guarantees so you can evaluate them yourself.
#What Swirls is
Swirls is agentic systems as code. Instead of wiring an agent together inside application code, you declare it across .swirls files: the agent, the deterministic workflows it calls as tools, the typed schemas, the triggers, the secrets. Ship with git push or swirls deploy and the system is live on Swirls Cloud.