How we catch compliance drift
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.
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
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.
More use cases
How we answer GDPR data-subject requests before the deadline
Our Machine agent checks each GDPR access or deletion request, finds the person's data across our product database, builds the report well within the SLA and hands it to legal before anything is sent.
How we keep our docs matching what the code does
Once a day a Machine agent reads every commit merged since its last pass, finds the doc pages those changes made wrong, rewrites them and sends you one pull request to review.
How we test every pull request without lifting a finger
Our Machine QA agent works with GitHub and our test environment. For each pull request it checks out the branch, runs the tests, tries the change for real, and posts what it found.
Put your first agentto work today.
- SSO
- RBAC
- Governed agents
- Full audit trail