Recurring work is where security tooling earns its keep, and where vague promises cause the most trouble. Safeguard has more than one way to run something on a timer, and they behave differently. This post separates them, using only the docs.
Desktop tasks: simple intervals
The desktop app is in early access. Its Tasks tab is described as where the agentic layer lives. A task matches a built-in workflow such as a local repo scan, an MCP configuration audit, a dependency watch, a container scan or an IDE extension check. Otherwise it is split into a generic series of steps.
Recurring tasks use an interval made of a number and a unit: 30s, 5m, 1h or 24h. Cron expressions are not accepted. Each scheduled task can be enabled, disabled or deleted. When a step is about to do something destructive, the task pauses and raises an approval request, and you approve or deny before it continues.
Workflows: a cron trigger in UTC
The workflows docs list on.schedule as a trigger, defined as a cron expression in UTC. The docs example for a weekly audit is 0 9 * * 1, annotated as Mondays at 09:00 UTC. A workflow can declare several triggers, so the same workflow can run on a schedule and when a vulnerability is published.
Workflows are written in YAML and use versioned steps such as scan-repository, griffin-remediate, evaluate-policy and jira-create. Run logs are kept for 90 days by default.
What does not run on a timer
- The autonomous agent. Inside a Griffin search conversation it acts only after you give consent with a typed goal each time, and a session ends after 30 actions or 60 seconds. The docs describe no scheduled or recurring runs.
- Cowork. The product page describes no scheduling. Sessions pause and resume on your next approval.
- The CLI.
safeguard execruns one turn with no prompts, and you can call it from your own scheduler or CI. The CLI page recommends registering a runner for scans the platform schedules.
How to choose
Use a desktop task for something personal on one machine, such as watching a project on this computer. Use a workflow for something the team owns, because it lives in Git and can be pinned per environment. Use a runner when the scan must read code that stays on your machine.
A scheduled run that nobody reads is only a log. Decide where its output goes, and who looks at it, before you turn it on.
Quick check
Can a desktop task use a cron expression?
No. The docs say only a number plus a unit such as 30s, 5m, 1h or 24h is accepted.
In what time zone is a workflow cron trigger?
UTC.
