Background AI Agents: Controls Before They Run

Background AI agents are agents that keep working while nobody is watching the conversation. In Insulin, that means jobs, which run on demand, on a cron schedule or when an event arrives, and goals, which keep working round after round until the objective is met or you stop them. Neither stops to ask for approval, so the controls that matter are set before a run, read while it runs, and used to stop it.

Updated 2026-10-23: Insulin now has a third access level, Full, which is the default; the boundary and set-up advice below now give all three levels, the built-in assistant’s included.

---

The IT or security owner tends to ask one question before the first schedule goes on: if agents will run at 09:00 every weekday and on every accepted offer, with nobody at the keyboard, what has to be in place first? The team lead about to create the job asks it from the other side: what can this job actually change, and how will I know what it did?

Insulin’s answer comes in an order, and the order is the point. The approval card that holds some actions in chat isn’t offered in a job run, so nothing a job does waits for an Allow. What a background agent may change is settled before it runs, what it did is on record while and after it runs, and each kind of work has its own stop. This post sets out those controls in that order, uses AWS’s Agentic AI Security Scoping Matrix to show why the first group carries the weight, and points each control to the post that covers it in full.

What controls should background AI agents have?

Three groups, in the order you use them: a boundary set before the run, a record you read while and after it runs, and a stop for each kind of work. In Insulin the first group carries the most weight, because no run waits for a person. Insulin’s Jobs page gives the rule in one line: “Decide what the agent may change before you schedule it.”

Stage	Control	What Insulin does	Covered in
Before	The agent’s boundary	A job runs as the agent you asked for it, with that agent’s integrations, knowledge bases, skills and model, and never more. On a custom agent, each integration is Read-only, Edit or Full, and each knowledge base Read or Edit	Where read-only access for AI agents is set
Before	What can start a run	You, a cron expression or an event. A push job’s filter decides which events run the agent	Below
Before	Who can see and stop it	Only the job’s owner; not even an org admin can. Work Planner schedules in an organization channel belongs to the channel	Below
Before	A ceiling on spend	The monthly spending limit: once the month’s spend reaches it, AI requests pause for the rest of the month	Below
During	The run record	Every fire leaves a run, Filtered and Rate limited included. Steps keeps the tool-call transcript, even when a run fails	How to see past runs of a scheduled AI job
During	Runs that didn’t happen	A Disabled badge, a blank Next, or a Filtered or Rate limited row says why	What to check when a scheduled AI job doesn’t run
During	Who hears when it finishes	A Slack direct message to the owner of a manual or cron single-turn job; none for event-started, goal or channel jobs	Insulin in Slack: tools, approvals and job notifications
Stop	A stop for each kind of work	Terminate a manual job’s run, Disable a cron or push job, Cancel goal on a goal	How to stop work in Insulin
Stop	The automatic brakes	A fixed cap on the runs Insulin starts, 60 an hour per job and 300 per organization, and the monthly spending limit	Below

The sections that follow explain the order: where background agents sit on AWS’s scale, which of AWS’s controls Insulin documents, and what to set, watch and stop at each stage.

Where do background AI agents sit on AWS’s scoping matrix?

Goals and manual jobs fit Scope 3, supervised agency; push jobs fit Scope 4, full agency; and cron jobs sit on the line between them. The Agentic AI Security Scoping Matrix is a framework AWS published on its Security Blog in November 2025 that sorts agentic AI systems into four scopes by how much agency and autonomy they have: No agency, Prescribed agency, Supervised agency and Full agency. What separates the top two is who starts the work.

• Scope 3 systems “execute complex autonomous tasks that are initiated by humans (or at least from an upstream human-managed workflow)” and act on connected systems “without further approval”. Humans “define the objectives and trigger execution”.
• Scope 4 systems “can initiate their own activities based on environmental monitoring, learned patterns, or predefined conditions”. AWS’s own Scope 4 example starts from an event: a calendaring agent sees that a meeting has taken place, reads its action items and books the follow-up session, and “at no point does a user directly instantiate the request for calendaring”.

Insulin work	What starts each run	Fours’ placement
A goal	Your request in a conversation; the agent then keeps going round after round	Scope 3
A manual job	You, each time you press Run	Scope 3
A cron job	A schedule a person asked for, with nobody starting each run	Borderline: Scope 3 or Scope 4
A push job	An event: a Fours marketplace event, such as an offer accepted, or a GitHub, Google Calendar or Gmail event	Scope 4

A goal is the clearest Scope 3 case. You ask, the agent “may keep going across many turns” rather than stopping at the end of its first reply, and you can steer it while it works, which matches a trait AWS lists for Scope 3: “Human ability to adjust parameters or provide context mid-execution”.

Cron is the borderline case. A person asked for the schedule, which reads like Scope 3’s “upstream human-managed workflow”. But nobody starts each run, and when AWS describes self-directed behavior, it names scheduling, beside environmental monitoring and learned patterns, among the ways an agent can “initiate activities … without human instantiation or review”.

This placement is Fours’ reading of AWS’s definitions, not AWS’s assessment of Insulin. It places each kind of work by how a run starts, not by every trait AWS lists for a scope.

Which of AWS’s Scope 3 controls does Insulin document?

Four of AWS’s six: boundaries set at initiation, monitoring, kill switches and, for goals, a way to intervene without stopping the work. AWS lists six implementation considerations for Scope 3. The table maps each to Insulin’s documented answer and to the stage where it acts.

AWS’s Scope 3 consideration	Insulin’s documented answer	Stage
”Clear execution boundaries defined at initiation”	The agent a job runs as: each integration Read-only, Edit or Full, each knowledge base Read or Edit, and never more than that agent’s access	Before
”Real-time monitoring of agent actions during execution”	Each run’s status and its Steps transcript, kept even when the run fails; a goal’s card and drawer, with its live status and the round it’s on	During
”Automated kill switches for runaway processes”	Two automatic brakes, the fixed rate limits and the monthly spending limit, plus three manual stops: Terminate, Disable and Cancel goal	Stop
”Non-blocking intervention mechanisms”	For goals, a steer typed into the goal’s drawer is picked up on its next round, “so you never have to wait for a gap to redirect it”. No equivalent is described for a job run	During
”Behavioral baselines for normal agent operations”	Not described	—
“Regular validation of agent alignment with original objectives”	Not described as a control. A goal’s objective changes only when you steer it: “the agent cannot quietly rewrite it on its own”	—

The automatic brakes count rather than watch. The rate limits count runs and the spending limit counts dollars, so neither notices an agent doing the wrong thing at a normal pace.

Insulin doesn’t claim AWS’s Scope 4 controls. For full agency, AWS adds “continuous monitoring with machine learning-based anomaly detection”, “automated response systems for behavioral deviations” and “failsafe mechanisms that can halt operations when confidence drops”. Fours’ documentation describes none of them. So a push job, the one kind of work Fours places in Scope 4, runs with Scope 3’s controls, and AWS’s advice for Scope 4 applies: be “cautious and selective when analyzing use cases and bounding controls”.

That is the autonomy view of these controls. For the risk-by-risk view, the OWASP Agentic Top 10 checklist for an AI workspace maps the same controls to OWASP’s ten risks.

What should you set before a background agent runs?

The boundary: the agent the work runs as, what that agent may change in each system, which events can start it, and who owns it. It carries the weight because nothing later in a run checks with a person. Insulin’s Jobs page says it plainly: “Runs never pause for approval.” The approval card isn’t offered in a job run, so “the turn proceeds without pausing”, and a goal’s background rounds can’t show the card either, so they don’t get the Slack send tool: “a goal never posts to Slack on its own.” With no pause and no behavioral check, a job that makes one wrong change each morning can stay under both automatic brakes.

1. Ask the right agent. A job runs as the agent you asked for it, with that agent’s access to resources and integrations. Ask the built-in Insulin assistant and it runs as the assistant, on your own connections, and a job you set up by asking the assistant in Slack does the same: it “runs with your access and your connections”. On the assistant, the boundary is each connection itself: what you granted when you connected it, such as your Fours MCP server connection’s access level, which is Read by default. The assistant’s own settings take the same Read-only, Edit and Full levels for your other integrations, but Fours’ Jobs page spells out a job keeping its agent’s integration access only for a custom agent, so a job that should only read is safest asked for in a chat with one.
2. Set each of that agent’s integrations to Read-only unless the job must write there. On Read-only, the agent can use “only that integration’s read tools”, and “a tool Fours does not recognise as a read is treated as a write”. Edit also creates and changes records but never deletes them, and Full, which adds deleting, is the default. A job keeps the setting, or as Insulin’s Jobs page puts it, “Read-only stays read-only”. On an organization agent, only an org admin can change the integrations, and each system’s own credential still sets the ceiling underneath.
3. Attach knowledge bases in Read mode unless the job maintains them. Read retrieves and searches “for grounded context only”. Edit can also create, update and deprecate files, and never deletes them.
4. Give a push job a filter. An event that fails the filter expression is skipped and recorded as Filtered; with no filter, “every event passes and triggers an agent run”. For the one kind of work Fours places in Scope 4, the filter is the boundary on what starts it. Fours event payloads are scrubbed of personal data, such as emails, secrets and tokens, before the agent sees them or a run record is stored.
5. Decide who should own it. A job is private to its owner: “being an org admin does not give you someone else’s jobs.” Only the owner can see it, run it, edit it or delete it, so only the owner can stop it. The exception is work Planner schedules in an organization channel, which belongs to the channel; every member sees it. Because an org admin can’t see a member’s jobs, ask the people who create jobs to say what they schedule.
6. Set a monthly spending limit. It’s a ceiling on what the organization may spend in a calendar month, set on Settings → Billing. Once the month’s spend reaches it, AI requests pause for the rest of the month, and the check sits on chat, agent runs and jobs. It’s the one stop that reaches jobs nobody but their owners can see.

How do you follow a background agent while it runs?

Through the record every run leaves, a goal’s card and, for some jobs, a Slack direct message. Every fire of a job leaves a run, including events the filter skipped and runs over the hourly limit, so “nothing that fired is invisible.” Each run keeps its Output, Steps and Input, and a failed run opens on Steps, where each tool call shows its Args and its Result or Error. A goal reports on its card, which tracks its status and the round it’s on, and the card opens a drawer with a timeline of rounds. In Jobs, it appears as a goal job.

Decide before the first run how you’ll hear about it, because the Slack message covers some background work and not the rest:

Work	A Slack direct message when a run finishes?	Where to follow it
A manual or cron single-turn job you own	Yes, if your organization has connected Slack and Fours finds your account’s email in that workspace: finished, failed, or rate-limited with a result that may be partial	The message, then the run it links to
A push job	No	Its Runs list in Jobs
A goal	No: a goal posts nothing to Slack on its own	Its goal card, or Jobs
Work Planner schedules in an organization channel	No	The channel, where every member sees it

A push job is the case to plan for. It is the one Fours places in Scope 4, and it sends no message, so someone has to read its runs.

How do you stop a background agent?

With the stop that belongs to the kind of work: Terminate for a manual job’s run and Disable for a cron or push job, both the job owner’s alone, and Cancel goal for a goal.

• Terminate stops a manual job’s run that is in flight, and the run is recorded as Cancelled.
• Disable pauses a cron or push job without deleting it, so it doesn’t fire on its own. It’s a pause, not a lock: Run now still fires a disabled job.
• Cancel goal, in the goal’s drawer, ends a goal. So does writing Stop., Cancel, pause or drop it in the conversation. In an Insulin channel, anyone in the room who can send messages stops a channel agent’s long-running work by writing stop.
• Delete removes a job and its run history, so read the runs first.

Two brakes act without anyone pressing anything. Runs that Insulin starts, a cron tick or an arriving event, are capped at 60 an hour per job and 300 an hour per organization, over a rolling hour. The limits are fixed, and a run over either is recorded as Rate limited instead of executing. Running a manual job skips the cap, and every job has one run in flight at a time. The monthly spending limit is the other brake, and the only stop that reaches a job someone else owns. Adding credit doesn’t lift it; raising or removing the limit brings service back within about a minute.

Frequently asked questions

What is a background AI agent?

An agent that keeps working while nobody is watching the conversation. In Insulin, that means jobs, which run on demand, on a cron schedule or when an event arrives, and goals, which keep working round after round until the objective is met or you stop them.

Do Insulin jobs wait for approval before acting?

No. The approval card isn’t offered in a job run, so the run proceeds without pausing. Decide what the agent may change before it runs: set each of its integrations to Read-only unless the job has to write there, and attach knowledge bases in Read mode.

Which AWS scope fits scheduled and event-driven AI agents?

In Fours’ reading of AWS’s Agentic AI Security Scoping Matrix, a push job, started by an event, fits Scope 4, full agency. A goal or manual job a person starts fits Scope 3. A cron job is borderline: a person set the schedule, but nobody starts each run.

Can an org admin see or stop another member’s background job?

No. Only a job’s owner can see, run, edit or delete it; not even an org admin can. Work Planner schedules in an organization channel belongs to the channel. The organization-wide brake is the monthly spending limit, which pauses AI requests for the rest of the month.

Does Insulin detect a background agent behaving abnormally?

No. Fours’ documentation describes no anomaly detection or automated response to behavior. The automatic brakes count runs and spend: a fixed cap on the runs Insulin starts, 60 per job and 300 per organization an hour, and the monthly spending limit. Set the boundary before the run.

Will I hear when a background agent finishes?

For a manual or scheduled single-turn job you own, yes, if your organization has connected Slack: Insulin sends you a direct message with the result or error. Jobs started by events, goal jobs and channel jobs send none, so follow those in Jobs or on the goal’s card.

Takeaways

• Order the controls: before, during, stop. No background run waits for approval, so what an agent may change is decided before it runs.
• The boundary is the agent. A job runs as the agent you asked for it, and never more: set each integration to Read-only unless the job must write, and attach knowledge bases in Read mode. Asked of the built-in assistant, a job runs on your own connections.
• Push jobs are the Scope 4 case. In Fours’ reading of AWS’s matrix, goals and manual jobs fit Scope 3, cron jobs sit on the line, and event-started jobs fit Scope 4. Insulin claims none of AWS’s Scope 4 controls.
• Every run leaves a record, Filtered and Rate limited included, with Steps kept when a run fails. Slack hears only about manual and scheduled single-turn jobs you own.
• A job’s stops belong to its owner. Only the owner can Terminate or Disable a job; a goal stops with Cancel goal or a written Stop. The monthly spending limit is the one brake that reaches everyone’s work.

Jobs and goals are the half of Insulin that keeps working after you log off. To see how a job runs unattended with its agent’s access and every run on record, start with scheduled AI jobs in Insulin.