How do I limit which tools an AI agent can call?

Put the process in sourcesteps and decisions declared
Keep the trigger, action, failure policy, and review point in one project.

#The question

"How do I limit which tools an AI agent can call?" comes down to scope. Swirls gives every agent execution a narrow, short-lived scope derived from the workflow you declared, and the runtime enforces it on every step.

#Who's asking

Forward-deployed / solutions engineer. Tasked with standing up custom agent logic per customer or per org, comfortable in a terminal and IDE.

#Why Swirls is a fit

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.

Agents call deterministic workflows as tools. Each node has a typed input and output schema, so tool execution is scoped, repeatable, and auditable instead of free-form model output.

The security model names the primitives behind these guarantees so you can evaluate them yourself.

Add the people, data, authority, and decisions around this job.

Keep this solution beside the Apps, records, rules, connections, and reviews it depends on in one .swirls project.