# How we catch compliance drift

Each day an agent checks our cloud setup against policy, flags public buckets, missing tags and roles with too much access, and suggests every fix as a change a person approves.

Canonical page: https://themachine.myapps.ai/use-cases/compliance-monitoring

Nobody sets out to break policy. Someone opens a bucket to the public to share one
file. A new resource goes live without its tags. A role keeps a permission from a
project that ended in spring. Each choice made sense on the day. Stack enough of
them up, though, and an auditor or an incident finds the whole pile in one go,
with no easy way to tell when each one crept in.

Our answer is boring on purpose: compare the infrastructure with policy every
single day, so a slip shows up the same day it happens. Below is how we run that
check on Machine, including what it connects to, what it does and where it stops,
so you can copy it.

- **Team:** Machine
- **Trigger:** One scheduled check per day
- **Connected systems:** AWS · Audit logs · Slack
- **Mode:** Runs on a schedule · fixes wait for review

## The problem

Every familiar approach has a catch. Audit by hand once a quarter and you find
months of drift at once, long after anyone remembers why. Write a rules engine and
it spots exactly the cases you programmed and is blind to the rest. Let a tool fix
things automatically and one day it will "correct" a setting that a live service
was quietly relying on.

What we wanted was simple to say. Check the infrastructure against policy daily.
Put the findings where the team already looks. Suggest fixes as changes a person
reviews, never quiet edits behind everyone's back.

## What we built

A daily schedule starts an agent on Machine. Every check runs in a fresh session,
which is a cloud computer of its own (a sandbox), and it gets narrow read access
to AWS and the audit logs. The agent looks for things that break policy, such as
public buckets, resources missing tags and roles with more access than they need,
and reports them in Slack. Fixes come as reviewed proposals. Nothing gets applied
on its own.

## How it works

### Start the check on a schedule

A **cron** trigger kicks off the check every day. Each kick-off creates a new
**session**: a fresh cloud computer (sandbox) built for that one run and then
thrown away. Because nothing is carried from one day to the next, every check
begins from a clean slate.

### Teach the agent your policy

Your rules live in **skills** and **memory**, the playbook the agent loads at the
start of every session. They spell out which buckets are allowed to be public,
which tags every resource needs, and what a role may or may not hold. The agent
measures against that playbook instead of a frozen rule list, and when the policy
changes, the playbook changes with it.

### Decide what it can see

**Connectors** are scoped connections to your tools, with the keys kept on our
servers and never shown to the model. Through them the agent can:

- **Look at AWS:** bucket policies, the tags on each resource, and IAM roles.
- **Look at the audit logs:** what changed a setting, and when.
- **Post in Slack:** findings land in the channel your team keeps an eye on.

### Draw the lines

The agent can only **read** AWS. It looks; it never touches. Any fix is written up
as a reviewed **change request** and waits at a **human approval gate**, so nothing
happens by itself. Credentials are stored encrypted in the **Secrets Manager** and
only handed to the agents you grant them to, at the moment a run starts.

### Let the daily check do its job

From there, each morning's run compares the infrastructure with policy, posts what
has slipped to Slack, and attaches a suggested fix for someone to look over. A
bucket that just went public turns into a finding plus a draft policy change. A
resource with no tags turns into a flag plus the tags it should carry. A role with
too much access turns into a tighter policy, parked for review.

> **The pattern**
> Trigger the check with **cron**. Give the agent read-only **connectors** into AWS
> and the audit logs. Write your compliance rules down as **skills** and
> **memory**. Then have every fix arrive as a reviewed **change request**, never as
> an automatic edit.

## Guardrails

Letting an agent look at your infrastructure every day is a matter of trust. Here
is what keeps it in bounds on Machine:

- **Isolation.** Each check runs in a sandbox and on a branch of its own. The
  session reaches only what it was scoped to read, and the findings it files are
  the only thing that comes back out.
- **Scoped secrets.** Credentials are stored encrypted in the Secrets Manager and
  only handed to the agents you grant them to, injected into the sandbox when the
  run starts.
- **Human approval gate.** The agent proposes; it never applies. A person reads
  each change and is the one who puts it in place.
- **Everything is code.** The agent's persona, its skills and its permissions are
  files in the repo. They keep a version history and only change through a
  reviewed **change request**, not a setting buried in a dashboard.

## The outcome

- **Daily:** Policy compared with the real infrastructure each day
- **Same-day:** Slips spotted long before they pile up for an audit
- **Review-gated:** Every fix arrives as a proposal, never applied alone

Drift used to arrive as a heap at audit time. Now it trickles into Slack as small
daily findings, each paired with a suggested fix that a person checks before
anything changes. Reviewing one change is a lot nicer than piecing together six
months of history, and our infrastructure stays much closer to policy as a result.