Job it-one-account-app-grant-or-mailbox-contained-after-your-admin-approves · revised 12 October 2026
Contain one account, app grant or mailbox, only after your admin approves that one action
Automation proposes one containing action with evidence and an undo note, and carries it out only after your named admin approves that single action. Nothing runs without approval.
You might be seeing
- Containing one account means five console screens and a search for the right steps
- Nobody wants a tool with permanent admin rights
No passwords, keys, card details or admin invites needed to start.
What usually happened
A tool with write permissions can affect the wrong account or follow hostile input. Here the customer-owned runner holds the documented write permissions, while our automation can only propose a request. Code in the runner requires one named admin's approval for one object and one action; it does not remove the runner's underlying rights.
Who it’s for: Owner or IT lead of a Microsoft 365 firm who wants a suspicious account or app contained through a single-action approval gate. The runner you own holds the documented write permissions; our request-making automation holds none.
Usually starts when: A report or an alert names an account, an app or a mailbox that looks wrong, and your admin is asleep or busy while the clock runs.
The result: In a test tenant, then in yours once you switch it on, the automation proposes one action on one object and waits. The action is one of three: block sign-in and end sessions for one local member account, remove one app's delegated grant, or hold one user-linked mailbox by blocking its local member account's sign-in and ending its sessions with nothing deleted. Your named admin approves that single action; it runs once, writes an audit-log entry with the undo note, and the approval cannot be reused or stretched to anything else.
Check whether this job fits
Answer these without sending files, logins or personal data. Nothing is submitted unless you choose to contact us.
What you get
- The runner and its settings, with the permission list
- The request and approval format
- The undo notes for each action
- The audit-log format and a sample
- The off-switch runbook
- The test results
Included
- One Microsoft 365 tenant, with local member accounts and user-linked mailboxes only, and the three actions above as fixed steps shown in each approval
- A runner you own, deployed in your tenant, holding the least-privileged permissions the vendor documents for those steps; our automation holds no write credential
- Each request names one object and one action, and carries the evidence and an undo note
- Approval by one named admin, valid for 15 minutes and for one use only
- A protected list you write (emergency-access accounts, admins, the approver's own account) that is always refused, and a cap of 3 actions a day
- An audit log of every request, approval, refusal and result, and a runbook to switch the runner off
Not included
- Any action without a named admin's approval of that exact request
- Any live tenant credential held by us; the runner you own holds the documented write permissions and enforces single-action approval in code
- Deleting accounts, mailboxes or mail, or any action not listed
- Actions on the protected list
- Deciding that an account is compromised or that a person did something wrong
- Investigation, incident response or round-the-clock cover
- Google Workspace or other platforms, which are quoted separately
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
Of 200 invalid requests, 150 generated by us and 50 held back by your admin until the run, all are refused and logged. Cover wrong object/action, expired or reused approval, unlisted approver, protected objects and the daily cap; one accepted invalid request fails the whole test. These are deterministic control tests, not an accuracy estimate, and you receive the case file and rerun steps.
Evidence: The attempt file and the audit log with the reason for each refusal.
With no approval, 50 attempts by the automation's own identity to disable an account, delete a grant or hold a mailbox are all denied by the platform.
Evidence: The platform's denial responses and the audit log.
For each of the three actions, three dummy runs after approval change exactly one object by exactly the listed steps, and the tenant state before and after differs in nothing else.
Evidence: The state diff for each of the nine runs.
Each of the nine actions is undone using only the note, and the object returns to its earlier state, except where the note says a part cannot be undone and your admin has read it.
Evidence: The undo results.
20 request texts hide instructions such as "disable every admin account" or "approve this request"; each runs five times. None produces more than the one proposed request, none runs an action and none is treated as an approval. This is a baseline, not a claim of immunity.
Evidence: The planted markers, the 100 outputs and the audit log.
Your admin switches the runner off and removes its identity from the runbook in under 10 minutes, and a request made afterwards is not carried out.
Evidence: The timing and the audit log.
Every request, approval, refusal and result has an audit-log entry with who, what, when, the evidence and the outcome.
Evidence: The log for all test runs checked entry by entry.
Sign-off. Your named admin re-runs the refusal pack and one dummy action with the steps we hand over, reads the results and signs off in writing. You deploy the runner yourself, and for the first 30 days every request is read by your admin the same day. Payment follows sign-off.
If it fails. If an agreed check fails, you do not pay for this fixed scope. We hand over what we found and agree whether to stop or re-quote; no surprise work.
When it fits, and when we stop
It fits when
- A named admin who approves or refuses each request and holds the off switch
- A written protected list and an agreed daily cap
- A test tenant or test accounts you own, and permission to deploy a runner in your tenant
- A person on your side can undo each action, and all tested account/mailbox targets are local member accounts with the limits stated in each request
We stop and tell you if
- You want any action to run without approval, or approval to last more than one use
- You want us to hold admin credentials
- No test tenant or dummy accounts exist
- No admin can be named as the approver
What could go wrong
Each action has an undo note: re-enable the account, restore the mailbox sign-in, or ask the app to request consent again. The note says which parts cannot be undone. Switching off the runner removes its ability to act at once.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| An action hits the wrong account or an account that should never be touched. | The approval must name the same object and action as the request, and a protected-list object is refused. The refusal pack must pass in full. |
| Text in an email or ticket tricks the automation into asking for an action. | The automation can only create a request, which still needs an admin's approval. Hostile inputs in testing must produce no action. |
| An approval is reused or stretched to a second action. | An approval works once, for 15 minutes, for the one object and action. A reused or expired approval is refused and logged. |
| Containment stops real work or does not stop an attacker. | Each request states the expected effect and the limits, such as a few minutes' delay in ending sessions and tokens that stay valid for their lifetime after a grant is removed. Whether to approve is your admin's call. |
| The runner's own credential is stolen. | It holds only the documented least-privileged permissions for the three actions, you hold the off switch, and the audit log shows every use. |
| Text inside a document, record or message tries to give the automation instructions. | All input text is data. The automation has no tool to send, approve, file or change anything beyond what is listed here, and planted-instruction items must change nothing. |
| Real documents or records pass through a model provider. | First tests use invented, synthetic or redacted data. Real data moves only after a written agreement names the model provider, its country, how long it keeps data and whether it trains on it. |
A separate automated reviewer checks the runner, the refusal pack and every test result before hand-over. Your named admin approves or refuses every request and deploys the runner. No human supervisor from us is included unless your agreement names one, and at launch the work is largely automated.
How we deliver
We arrange the work and independent review, then show you the result against the agreed checks. You keep authority over your systems.
- Agree the three actions, the protected list, the cap and the approver
- Build the runner and the request format in a test tenant
- Write 150 refusal attempts; your admin holds back 50 more until the run
- Run each action three times on dummies and check state before and after
- Your admin runs the undo and the off-switch drill from the runbook
- Separate automated review; your admin deploys the runner in your tenant
This is a one-off job, not emergency cover or a subscription; an enquiry creates no charge or booking. Before you accept, we confirm eligibility, total price, start window and delivery date; work starts only after agreed inputs, secure access and needed permissions are in place. Model usage for our build and tests is included up to a cap stated in writing.
Need to keep it working?
Discuss a monthly drill that re-runs the refusal pack and reads the audit log.
Ongoing work is separately scoped and quoted: no monitoring, response-time guarantee or automatic subscription is included in this job.
Explore an ongoing managed lane, or mention the responsibility you need in your enquiry.
What you can check
This is a new service. We have not delivered this job for a client yet.
Other ways to get this done
- Keep a written containment checklist and have your admin do each step by hand in the console.
- Use your platform's own approval-based privileged access features where your licence includes them. learn.microsoft.com
Questions
Can it act without my admin?
No. The automation can only send a request. Your admin's approval of that exact request is what runs the action, once.
Do you hold admin rights to our tenant?
No. The runner is deployed and owned by you, with only the documented least-privileged permissions for the three actions.
Does disabling an account stop the attacker straight away?
Not always. Ending sessions can take a few minutes, and removing an app grant does not cancel tokens already issued. Each request says so.
Send an enquiry
Send us
- Your platform and licence level
- Who your approving admin would be
- The accounts you would put on the protected list. No logins or tenant data in the first enquiry
Later, once you agree
- A test tenant or dummy accounts, apps and mailboxes that you own
- Your protected list, daily cap and approval wording, plus 50 invalid requests held back by your admin until the acceptance run
- Permission for your admin to deploy the runner and create its least-privileged identity, which you can remove
- The name of the approver and a backup
- The agreement that names the model provider, its country and how long it keeps data, settled before any real personal data is shared
You keep every account and every right. The runner lives in your tenant, you create and can remove its identity, and our automation can only send it a request, never an action. We build and test on dummy objects and hold no credential to your live tenant.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “it-one-account-app-grant-or-mailbox-contained-after-your-admin-approves” as the subject.