Daily security check

This is the recurring 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 every day's result has its own run conversation.

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. Ask for it by hand 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 approve a routine.

What you'll build

• Scout inspecting a repository and writing up what it found.
• A review request, so the service desk lead sees the finding and can leave notes.
• A routine that repeats the whole thing at 08:30 on weekdays.

Before you start

• GitHub connected, with access to acme/api.
• An agent named Scout granted github.code.search, github.file.get, and mobius.principal.list, and nothing else. Read-only, deliberately.
• A Mobius user to receive the reviews. You'll need their email address.

1. Ask for the check by hand

Start a conversation with Scout and ask for one run of it:

Search acme/api for risky changes around authentication, API keys, billing
checks, and webhook verification. Give me a risk summary, evidence links, and a
recommendation. If there is nothing worth reporting, say so in one line.

Read what comes back. Then read tomorrow's. This is the week that decides whether anyone will trust the check later.

That last sentence matters more than it looks. Agents are reluctant to say "all clear" unless you explicitly tell them it's an acceptable answer, and a check that always finds something is a check nobody reads.

2. Add the review

Once the finding is worth reading, add the human step to the request:

Same check, and when you're done, ask the platform lead to review it. Find them
with mobius.principal.list by their email lead@northwind.example, and open a
request_review interaction with your note in it, asking them to mark it clear
or say what follow-up to open.

Scout writes the note and calls mobius.interaction.open. Asking doesn't hold Scout up: it finishes the turn, and nothing runs while the request is open.

The reviewer sees it under Work > Inbox, reads the note, and answers. The answer arrives in the same conversation, and Scout responds to what they said.

mobius.interaction.open is built in. There is nothing to grant for it.

3. Put it on a schedule

Open Routines and select New routine. Choose Scout, paste the check and review instructions you tested, and set a weekday schedule for 8:30am in the right timezone. Under Accounts, bind the exact GitHub connection used for the reads.

Under Custody, choose The business when the check belongs to the company. Name the platform lead under Responsible, then add anyone who should follow its results under Followers. Open Advanced, review Credits per run and Credits per 24 hours, and select Create routine.

The conversation where you tested the check remains separate. The routine now owns the recurring work and each occurrence gets its own run conversation.

Read it the next morning

Open Routines > Runs and choose Open run. That day's conversation shows the 08:30 instruction, Scout's searches, its note, the review request, and the reviewer's answer in order. Earlier days remain separate rows in the routine ledger, which makes one failed or noisy check easier to inspect.

An occurrence that says skipped means the previous one was still running when this one was due. If you told Scout to wait for the review, that happens when a review sits unanswered overnight, and it is usually the right outcome: one open review at a time.

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. Edit the routine rather than starting a new one.

Tell it what "nothing to report" looks like. Say plainly that an all-clear is an acceptable answer, and give it the one-line shape you want. The noise drops sharply.

A check reviewers trust is worth ten checks they skim.

Variations

Only bother a person when something's wrong. Tell Scout to open the review only when it found something, and to answer in the conversation otherwise. Clean days finish silently.

Post a digest too. Grant slack.message.post when the team wants a channel copy. If the post should be reviewed, tell Scout to open an approval interaction with the exact draft and channel, and to post only after approval. Mobius does not insert that review automatically.

Open a follow-up after review. Grant github.issue.create and tell Scout to prepare an issue once the reviewer asks for one. If the existing review did not show the proposed issue, add a separate interaction before Scout creates it.

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 Scout'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 grant 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

• Understand what you approved: routines.
• Grant tools through tools and skills.
• Pause for review with interactions.
• Keep long checks bounded with guardrails.