mobius

Get started free
Get started free

Guides

Daily security check

This is the scheduled check pattern: every morning, an agent goes and looks at something, writes up what it found, and puts that in front of a person. Nobody has to remember, and the record of what was checked builds up on its own.

The example here checks a client's code repository for risky changes, because that's an example we can make concrete end to end. The shape is the same whichever thing you check: backups, patch compliance, unusual sign-ins, certificates about to expire. See pointing it at your own systems at the bottom.

One piece of advice before you build it. Run it manually for a week first. A daily check that produces noise gets ignored inside a fortnight, and once your team has learned to ignore it, the day it finds something real you won't notice either. Get the signal right, then put it on a schedule.

What you'll build

  • A weekday schedule at 08:30.
  • An agent step where Scout inspects and writes up what it found.
  • A review step, so the service desk lead sees the finding and can leave notes.

Before you start

  • GitHub connected, with access to acme/api.
  • An agent named Scout (agt_scout) whose toolkit grants github.code.search and read-only repository actions, and nothing else.
  • A Mobius user to receive the reviews.

Build it

  1. In the app, open Build > Loops.
  2. Create a loop named Daily security check.
  3. Add a Schedule trigger for weekdays at 08:30.
  4. Add an agent step named Inspect repository.
  5. Give Scout instructions to search for risky patterns and return a short risk note.
  6. Add an interaction step named Review finding.
  7. Use request_review, any_of, and an input mode so the reviewer can leave notes.
  8. Create the loop as active.

Your loop now produces one daily run and pauses when a human review is needed.

Finished spec

schema_version: "1"
name: daily-security-check
description: Search for risky code patterns and request review.
concurrency: skip
triggers:
  - key: weekday-security-check
    name: Weekday security check
    kind: schedule
    enabled: true
    config:
      cron: "30 8 * * MON-FRI"
      timezone: "America/New_York"
steps:
  - id: inspect
    name: Inspect repository
    kind: agent
    config:
      agent_id: agt_scout
      tool_names:
        - github.code.search
        - github.file.get
      instructions: |
        Search acme/api for risky changes around authentication, API keys,
        billing checks, and webhook verification. Return markdown with a
        risk summary, evidence links, and a recommendation.
  - id: review
    name: Review finding
    kind: interaction
    config:
      protocol: request_review
      targets:
        - usr_platform_lead
      prompt: |
        Review Scout's daily security note. Add follow-up instructions or
        mark it clear.
      resolution_policy: any_of
      spec:
        mode: input
        multiline: true
        placeholder: "Clear, or note the follow-up issue to open."
    timeout:
      duration: 8h
      on_timeout: fail

Run it

Start a manual run once before relying on the schedule:

run.started
step.started          step=inspect kind=agent
step.completed        step=inspect
step.started          step=review kind=interaction
interaction.requested step=review
run.suspended

After the reviewer responds:

interaction.responded
wait.resumed
step.completed step=review
run.completed

The output should include Scout's note and the review response:

{
  "inspect": "No high-risk changes found. Watch webhook signature tests.",
  "review": {
    "value": "Clear. Open a follow-up if webhook fixtures drift again."
  }
}

If it gets noisy

It will, at first. Two fixes, in order:

Narrow what it looks at. A check across everything finds something every day, and most of it doesn't matter. One repository, or one risk area, produces a finding worth reading.

Tell it what "nothing to report" looks like. Agents are reluctant to say "all clear" unless you explicitly tell them that's an acceptable answer. Put that in the instructions and the noise drops sharply.

A check reviewers trust is worth ten checks they skim.

Variations

Only bother a person when something's wrong. Add a check step with on_fail: gate between the agent and the review. Clean days finish silently; only findings open a request.

Post a digest instead. Swap the review step for slack.message.post when the team wants visibility but not an approval queue.

Open a follow-up automatically. Add github.issue.create, or your own ticket-creating action, after the review.

Give it a workspace. Use a managed environment when the check needs to download files and inspect them rather than just search.

Pointing it at your own systems

The pattern here has nothing to do with code. Swap the agent step's tools and you have:

  • A backup check. Read last night's backup results, flag anything that failed or didn't run, write it up.
  • A patch compliance check. Pull device patch status, flag machines that are behind, group by client.
  • A certificate check. List certificates expiring in the next 30 days.
  • A sign-in review. Look at unusual authentication activity and summarize what's worth a second look.

If the system holding that data has an API, build a custom HTTP action to read from it and give that action to Scout. If the data lands in a spreadsheet or a table instead, read it from there. Everything else in this guide stays exactly the same.

Next