Standing service it-approval-gated-actions-drilled-and-audit-log-read-every-month · revised 12 October 2026
Standing service
Re-drill your approval-gated actions and read the audit log every month
Each month the refusal pack is re-run on a test tenant, one action is undone on a dummy, and the audit log and runner permissions are read for anything outside the approvals.
This starts a conversation by email. Nothing is charged, and nothing is run, until we have agreed scope, access and terms with you in writing.
The responsibility you hand over
An approval gate fails quietly: a permission creeps in, the protected list goes stale, or a new admin is not on the approver list. The monthly job re-tests the refusals, reads the log for any action without a matching approval and compares the runner's permissions with the agreed list.
Who it’s for: Owner or IT lead who has an approval-gated containment runner and needs to know each month that it still refuses what it should and has not gained rights.
Usually starts when: The runner has been live for weeks, nobody has looked at its log, and your tenant settings have changed since.
The result: Each month you receive the re-run of the 200-attempt refusal pack on a test tenant, one dummy action undone from its note, a check that every logged action has a matching approval, and a comparison of the runner's permissions with the agreed list. Any action without an approval, or any extra permission, goes first.
What stays true, and what we do about it
No response-time guarantee is published for this new service. A target for delivering each month's report is agreed in writing before it starts, set to what a service at this stage can keep.
Hours are agreed in writing before the service starts. At launch the service is not staffed round the clock and runs once each month. The runner runs in your tenant and you hold its off switch.
What must remain true
- Every logged action has a matching, unexpired, single-use approval by a listed approver
- The runner holds only the agreed least-privileged permissions
- The frozen refusal pack is still refused in full
What we watch
- The month's audit-log export
- A read-only export of the runner's permissions
- The protected list, approver list and cap
- The test tenant
When something happens
Scroll the table sideways to read it all.
| When | What we do |
|---|---|
| A month closes and the exports arrive. | We match the log to approvals, compare permissions and re-run the refusal pack. |
| The runner, an approver or the protected list changes. | We re-run the whole pack before you rely on the change. Linked job: Approval-gated single action |
| An action appears in the log without a matching approval. | It goes first in the report with the log lines, and the report points to the off switch. |
We do on our own
- Re-run the frozen refusal pack on the test tenant
- Read the exports and write the report
- Offer the one-off job when the runner or lists change
We ask you first
- Any change to the runner, its permissions, the lists or pass marks
- Any access to your live tenant
- Approving or running any action
We escalate to you when
- An action ran without a matching approval
- The runner holds a permission outside the agreed list
- The same failure appears two months running
How you know it held. Each month the report states requests, approvals, refusals and actions, any action without a matching approval, permissions compared with the agreed list, the refusal pack result and the dummy undo result, with unknowns kept.
How we keep it true
This service is never finished. Each month's report shows whether the thing it watches stayed true, and it continues until you end it.
Contain one account, app grant or mailbox, only after your admin approves that one action Job Optional
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.
Bought separately, each time it is needed; not part of the monthly fee
What is included, and what is not
- Monthly drill report
- Log-to-approval match
- Permission comparison
- List of changes since last month
Included
- One tenant and one runner
- The frozen refusal pack and one dummy action and undo, run on a test tenant
- The month's audit-log export, matched action by action to approvals
- A read-only export of the runner's permissions compared with the agreed list
- The protected list and approver list checked for names that have left
Not included
- Approving, running or undoing any action on your live tenant
- Holding any credential to your live tenant
- Changing the runner, its permissions or the lists without your written approval
- Incident response or round-the-clock cover
- Any response-time guarantee
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
Each month all 200 frozen attempts are refused and logged on the test tenant.
Evidence: The refusal pack results.
Each month every logged action in the export has a matching, unexpired, single-use approval by a listed approver, or is listed first as a breach.
Evidence: The log-to-approval match.
Each month the runner's permissions equal the agreed list, or each difference is listed.
Evidence: The permission comparison.
Each month the frozen test pack is re-run and every previously passing case still meets its agreed check. A regression fails this check even if reported, and the report lists it first with its cause.
Evidence: The monthly test report.
Your admin approves, runs and undoes one dummy action using the runbook; the before/after/undo states match the specified action and restoration limits. Any other object changed or any action without its exact approval fails the month.
Evidence: Your admin's signed drill result, state comparisons and approval/audit logs.
After any runner or approval-rule change, all 50 new invalid requests your admin holds back until the run are refused and logged. One accepted request fails the test, and you receive the cases and rerun steps.
Evidence: The buyer-held request file and refusal log.
Sign-off. You read the report and test results and accept or send them back in writing. A month counts as delivered only when its agreed acceptance checks pass; receiving a report alone is not acceptance.
If it fails. If we cannot run a month because an input is missing or has changed shape, we say so, explain what we need and do not guess. If the service is not working for you, you can end it at the end of any month.
When it fits, and when we stop
It fits when
- The matching one-off set-up is done, or an equivalent runner with a frozen refusal pack exists
- Your admin sends the audit-log export and the permission export each month
- A named admin who reads each report
We stop and tell you if
- The audit log is not exportable
- Nobody on your side reads the monthly report for two months running
- You want any action to run without approval
What could go wrong
The service reads, tests and reports. Ending it leaves your systems and the way you work exactly as they are, and you keep every report we sent.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| A clean report is read as proof that the runner cannot be abused. | The report says it checks the logs and permissions you send and the refusal pack, and nothing else. |
| The exports are incomplete. | The report compares the log count with the runner's own count and states any gap. |
| 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 each month's report against the agreed test before it is sent, and your named person decides what to do with it. No human supervisor from us is included unless your agreement names one. At launch the work is largely automated, and we say so.
Stays with a person
- Your named admin decides what to do with each report
- You approve every action and hold the off switch
Access we would need
- Exports sent through a secure route agreed in writing, and a test tenant
- No credential to your live tenant and no write access
Questions
Can you stop the runner if you find a breach?
No. We hold no credential to your tenant. The report points to your off switch and your admin decides.
Do you run actions for me?
Your admin approves and runs the dummy drill in the test tenant. We never approve or run live actions; the runner you own carries them out after your admin approves.
Also part of
Send an enquiry
Send us
- How many actions the runner takes a month
- Who receives the report. No tenant data or logins in the first enquiry
Later, once you agree
- The first month's audit-log and permission exports through a secure route agreed in writing
- A test tenant, a dummy action/undo result supplied by your admin, current lists and the runner's own request/action counts
- The frozen refusal pack and pass marks; 50 new invalid requests held back by your admin until the run after any runner or approval-rule change
You keep every account and right. We read exports and run refusal checks on the test tenant; your admin approves, runs and undoes the dummy action and supplies its evidence. We hold no live tenant credential and never approve or run a live action.
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-approval-gated-actions-drilled-and-audit-log-read-every-month” as the subject.