# How we handle access requests

Someone asks for access in Slack and an agent checks the policy, looks up their role and drafts the smallest grant that fits. A person approves every grant, and each one is logged.

Canonical page: https://themachine.myapps.ai/use-cases/access-requests

"Can I get into the billing repo?" "Who can give me that role in Okta?" Asks like
these land in Slack all day, usually with a deadline attached. Whoever owns the
access then has to figure out what this person's job actually calls for, find the
smallest permission that gets them moving, apply it and write it down somewhere.
When you're busy, it's tempting to hand over something broad and get back to your
own work. Do that enough times and nobody can say for sure who holds what.

Our fix is simple to describe: every grant is tied to the request that asked for
it and to the policy that decides it. Below is how we run this on Machine, step
by step, with the connections and safety rails, so you can copy it.

- **Team:** Machine
- **Trigger:** Someone asks for access in Slack
- **Connected systems:** Okta · GitHub · Cloud IAM
- **Mode:** Checked against policy · A person approves · Every grant recorded

## The problem

We tried the usual answers and none of them held up. Ticket queues just move the
ask to a human, who still looks everything up and clicks the grant through
manually. Giving people a permanent wide role ends the back-and-forth, but now
they hold far more than any single task requires. Letting people grant themselves
access with no policy check is quick, and quietly unsafe. And not one of these
leaves a tidy trail of what was given out, or the reason.

What we wanted instead: each ask measured against policy, trimmed to the least
access that gets the job done, applied only once a human says yes, and written to
a log.

## What we built

Now a Slack message asking for access wakes up an agent on Machine. The request
gets its own **session**: a fresh cloud computer (a sandbox) used only for that
run, with narrow connections into Okta, GitHub and cloud IAM. The agent reads the
ask, compares it with policy, pulls up the person's role and team, works out the
tightest scope that fits and drafts the grant. A person must approve every grant
before it's applied, and every one is logged.

## How it works

### Make a Slack message the starting gun

We hook Slack up as a **channel**, which means a posted request is what kicks
things off. Each ask spins up a brand-new **session** in a sandbox of its own,
already told who is asking and for what. A single ask gets a single throwaway
computer, and nothing is shared between them.

### Teach the agent your access rules

Your policy lives in **skills** and **memory**: the playbook the agent loads on
every run and keeps up to date. It spells out which roles get which grants, what
"least privilege" looks like in each system, and which kinds of asks deserve a
closer look. So the agent follows your rules instead of making them up, and when
the policy changes, so does the playbook.

### Wire up the systems a grant touches

The agent works through **connectors**: scoped connections to your tools, with
the keys held on the server so the model never sees a raw token. With them it
can:

- **Look things up in Okta**: who the requester is, which team they sit on and
which groups they already belong to.
- **Draft a GitHub grant**: access to a repo or team, sized to the job at hand.
- **Draft a cloud IAM grant**: the smallest role or set of permissions that
clears the blocker.

### Put a human in front of every grant

Handing out access changes what people can do, so nothing gets applied until a
person approves it at a **human approval gate**. Once approved, the grant is
logged alongside the original ask, the policy check and the scope that was given.
Credentials are stored encrypted in the **Secrets Manager** and only handed to
the agents you grant them to.

### Get back a tight grant with a paper trail

From then on, a Slack ask returns as a least-privilege grant that has already
been checked against policy, waiting for someone to approve it, with its record
attached. "Can I get into this repo?" turns into a narrow GitHub grant. "I need
that cloud role" turns into the smallest IAM permission that does the job. Both
wait for a yes.

> **The pattern**
> Let a Slack **channel** start each run, hand the agent narrow **connectors**
> into Okta, GitHub and cloud IAM, write your access rules down as **skills**
> and **memory**, and make a person approve every grant, with a log kept each
> time.

## Guardrails

Letting an agent near access decisions only works if you can trust it. Here's
what keeps it in line on Machine:

- **Isolation.** Each request gets its own sandbox and its own branch. The
  session can reach only the systems it was scoped to, and it can send back out
  only what it has been explicitly allowed to.
- **Scoped secrets.** Credentials are stored encrypted in the Secrets Manager,
  delivered into the sandbox when the run starts, and only handed to the agents
  you grant them to.
- **Human approval gate.** A grant stays unapplied until a person says yes, and
  every approved grant goes into the log.
- **Everything is code.** The agent's persona, skills and permissions are files
  in your repo. They have version history, and you change them through a
  reviewed **change request**, never a toggle in some dashboard.

## The outcome

- **Least privilege:** Each grant sized to the job, nothing extra
- **Approval-gated:** A person says yes before any access goes live
- **Logged:** Each grant saved with the ask and the scope given

Requests that once got waved through with broad access in a rush now arrive
trimmed, checked against policy and waiting for a person's approval, and they
leave a record behind. Want to cover another system? Connect one more platform.