Product · Approved actions· Works with Microsoft 365
HELMGATE. When your person wakes up, it is one guided, approved, provable runbook.
A second pair of eyes on every admin action, and a file you can hand to someone else.
HELMGATE turns the Microsoft 365 moments you dread into guided runbooks where one person acts, another approves, and the record writes itself. Clicking the buttons is free everywhere. What nobody hands you is the structural refusal — the requester cannot approve their own action — and the artifact at the end that an auditor, an insurer or your own client will accept.
Requester never approvesHash-chained evidenceNothing irreversible, ever
What is proven today
1 write action proven
Microsoft Graph session revocation, executed 9 July 2026 against a real Microsoft 365 tenant from an EU container.
2 operators, separated
The operator who submits an action cannot approve it. The runtime refuses with a 403, and records the refusal.
5-event audit chain
From action_planned to action_executed, every event hash-linked, in an append-only store.
EU-resident
North Europe container and Azure Postgres, managed identity, TLS verify-full.
The bleed
The response is the easy part. The proof is what costs you.
Every action in every playbook here can be done by hand, for nothing, by anyone with the right role. That is not the problem. The problem arrives a month later, when somebody outside your company asks what happened, who authorised it, and when — and the answer has to be a document rather than a memory.
The response happens, and then nobody can prove it
Sessions revoked at 23:40, sign-in blocked at 23:52, forwarding rule found on Thursday. Three people, two consoles, no shared record. A month later the insurer asks what you did and when, and the honest answer is a reconstruction.
One admin, alone, at the worst possible moment
The person responding is the person deciding, under time pressure, with nobody checking. That is fine until the day the account they disable is the wrong one, or the day an auditor asks who authorised it.
The paperwork lands days after the work
GDPR gives you 72 hours to notify and a standing duty to document. NIS2 wants an early warning inside 24. Meanwhile the evidence lives in three tools and one person's memory, and writing it up is the job everyone postpones.
Four playbooks, one engine
Each step says what it is, including the ones we have not built.
Every status below is read from the action register at build time, not typed into this page. One write action has been executed against a real tenant. Anything else says so, and says what is missing. If that ratio bothers you, it should — it is also why the design-partner price exists.
Compromise
What we sell first
An account is taken over. Your operator runs the response as a guided runbook, a second named person approves each step, and the file you owe the regulator writes itself as you go.
Trigger: A user reports a phishing click, or a sign-in alert names an account you own.
Revoke every sign-in session
Proven on a live tenant
A stolen refresh token survives a password change. Revocation is the step that actually ends the attacker session.
Block sign-in on the account
Roadmap
Stops re-entry while you work out what was reached.
Needs a graph.user.disable manifest, risk class R2, rollback = re-enable. Not in the register yet.
Remove attacker inbox rules
Roadmap
The rule that files your replies into RSS Feeds is how the fraud stays invisible after you think it is over.
Needs an Exchange mailbox-rule manifest and new Graph scopes. The scope change is disclosed on /trust/scopes in the same release.
Remove external forwarding
Roadmap
Forwarding outlives the session and is routinely missed in a manual response.
Needs a mailbox-forwarding manifest on the same new Exchange scopes.
Produce the incident file
Built
The record you hand to a DPO, an insurer or your client — built from the evidence chain, not reconstructed from memory a week later.
What funds it
GDPR Article 33(5) — the controller documents the facts, the effects and the remedial action, so the supervisory authority can verify compliance.
NIS2 Article 23(4) — early warning at 24 hours, notification at 72 hours, final report one month after that notification.
Change
A Conditional Access or tenant setting changes only after a second named person has seen the diff and approved it, and the approved change record is the artifact your auditor asks for.
Trigger: Someone is about to edit a Conditional Access policy on a Friday afternoon.
Capture the current policy state
Roadmap
You cannot show what changed without what it was.
Needs a Conditional Access / policy read manifest. Not in the register yet.
Submit the change as a reviewable diff
Roadmap
The approver reads a diff, not a description of a diff.
Needs a policy-change submission manifest.
Apply the approved change
Roadmap
The change is applied by the engine so the record and the act cannot diverge.
Needs a policy-write manifest, risk class R2, rollback = restore captured state.
Produce the change record
Built
Who asked, who approved, what the diff was, when it applied.
What funds it
ISO/IEC 27001 A.8.32 — change management; auditors ask for approved change records.
Elevation
Standing admin rights end. A technician asks for a role with a reason and a time box, someone else grants it, and the grant expires on its own.
Trigger: Your insurer asks how privileged accounts are secured, and the honest answer is that four people are permanent admins.
Request a role with a reason and a time box
Roadmap
A request with no expiry is a standing admin with extra steps.
Needs a time-boxed role-request manifest over the plain roleAssignments API.
Grant the role for exactly that window
Roadmap
The second person decides; the engine enforces the window.
Needs a role-assignment manifest, risk class R2, rollback = remove assignment.
Remove the role at expiry
Roadmap
Expiry that depends on someone remembering is not expiry.
Needs the reclaim path on the same manifest.
Produce the elevation record
Built
What was held, by whom, for how long, and who authorised it.
What funds it
Insurance renewal questionnaires ask how privileged accounts are secured; underwriters have moved from MFA to admin separation to elevated-action logging.
Leaver
A departure becomes an approved, executed and evidenced sequence — the execution tier of Offboarding Evidence, built to the convergence spec ratified on 2026-07-12.
Trigger: Someone leaves, and in six months an auditor asks you to prove they lost access.
Revoke every sign-in session
Proven on a live tenant
The same first move as a compromise: end the live sessions before anything else.
Block sign-in on the account
Roadmap
The single most requested leaver action, and the one an auditor checks first.
Needs the same graph.user.disable manifest as the Compromise playbook.
Remove standard group memberships
In the register, not yet run
Group membership is how access survives a disabled account in shared resources.
Remove assigned licences
In the register, not yet run
The part finance notices, and the reason offboarding pays for itself.
Write the remediation rows into the evidence pack
Built
The finding and its closure end up in one artifact rather than two systems.
What funds it
DORA RTS (CDR (EU) 2024/1774) Article 21(e)(iii) — withdrawal of access rights without undue delay upon termination.
CIR (EU) 2024/2690 Annex 11.2.2(b), (e), (f).
NIS2 Article 21(2)(i); ISO/IEC 27001 A.5.18 and A.6.5.
The one that happened
Watch one run: request to revoked, on the record.
This is the first step of the Compromise playbook, and the one thing here that has actually executed: a session revoke run from an EU container against a real Microsoft 365 tenant, requested by one named operator and approved by another. Play it, scrub back to the policy decision, and open the evidence on any stage.
Loading the interactive console
How it works
Every action has a class. The class decides the gate.
HOIST checks every candidate action against the whitelist register before it can run. Each entry carries a risk class, and the class alone decides whether the action runs, waits for a named approver, or never runs at all. Open a rung to see the manifest fields behind it.
R0
Auto-allowed
Reads run automatically. No approval role attached, nothing to gate.
graph.user.read
riskClass
R0
approval
none
rollback
None
evidence
user_idfields_requestedtimestamp
R1
Requires a named approval role
A low-risk write. Held for the role named in the manifest before it runs.
jira.ticket.createConnector on the roadmap
riskClass
R1
approval
requester
rollback
Close or cancel ticket
evidence
ticket_idpayload_hashapprover
R2
Requires approval, elevated
An elevated write. Held for a named security_admin, a different operator than the one who asked. The one action HOIST has executed live.
graph.session.revokeProven in lab
riskClass
R2
approval
security_admin
rollback
User signs in again
evidence
user_idreasonapprovergraph_response
R3
Blocked outright
The role above does not matter. The policy engine refuses to run this action at all.
graph.privileged_group_membership.update
riskClass
R3
approval
security_admin
rollback
Manual break-glass only
evidence
block_eventattempted_targetpolicy_reason
Blocked regardless of the approval role above. No operator can override it.
D
Draft only
HOIST prepares the draft and stops. A human decides whether to execute it.
intune.device.destructive_action.draftConnector on the roadmap
riskClass
D
approval
human_executes
rollback
Manual endpoint recovery
evidence
device_idrisk_reasondraft_id
The draft is the entire output. Execution stays with a human.
Classifications are frozen by a CI eval gate: a silent reclassification fails the build.
Capability Ledger
Live in the lab today. On the roadmap next.
Every claim on this page sorts into one of two columns. Nothing here is called shipping until it has run against a real tenant.
Golden tickets, a prompt-injection corpus and unsafe-action invariants run before any change ships.
Kill-switch, EU-resident hardened stack
Managed identity, Key Vault references, TLS verify-full. Execution flag off by default.
Not yet
On the roadmap
Multi-step offboarding runbooksPlanned
Chained leaver actions beyond the single proven session-revoke write.
Ticket creation and updatesPlanned
Writes into Jira and other ITSM systems. Jira access is read-only today.
Native interactive Teams and Slack buttonsPlanned
Webhook notifications exist today; in-channel approval buttons do not yet.
HRIS and Intune connectorsPlanned
Identity and device actions beyond the current Graph and Jira read scope.
Generic OpenAPI connectorPlanned
A configurable adapter for arbitrary REST systems.
LLM-driven intent routingPlanned
Plus DECKLOG-grounded answers. No LLM chooses which action runs today.
Per-user operator SSOPlanned
Entra ID OIDC, replacing the current shared per-operator credential registry.
GDAP and administrative-unit scopingPlanned
Delegated, tenant-scoped access for customer deployments beyond the lab.
The record is the product
Prove what happened to somebody who was not there.
Every action writes five hash-linked events to an append-only store in the EU. The chain detects mutation, deletion or reordering — it does not prevent them, and the difference matters enough that we say it here. Try it: verify the sample chain, then tamper with an event and watch the break surface.
Tamper-evident audit trail
Every action writes a hash-chained trail
Sample data from the proven lab run: the 5 events persisted for capstone request capstone-20260709183826.
#0 action_planned
Matched the whitelisted action. Anything off the register stays unavailable to the model.
prevHash
computing…
entryHash
computing…
requestId:
capstone-20260709183826
action:
graph.session.revoke
connectorKey:
microsoft-graph-write
submitter:
hoist-trigger
#1 policy_decided
Risk class R2, requires approval by role security_admin.
prevHash
computing…
entryHash
computing…
requestId:
capstone-20260709183826
riskClass:
R2
decision:
requires_approval
approvalRole:
security_admin
#2 approval_requested
Fan-out to 3 channels. Notification carries a signed link and summary only.
prevHash
computing…
entryHash
computing…
requestId:
capstone-20260709183826
approvalId:
appr-9f21c4
channels:
signed-link, teams-card, slack-blocks
ttlMinutes:
60
#3 approval_granted
A different operator grants. Self-approval by the submitter returns 403.
prevHash
computing…
entryHash
computing…
requestId:
capstone-20260709183826
approver:
sec-admin-1
separationOfDuties:
enforced
selfApprovalBySubmitter:
blocked:403
#4 action_executed
Graph POST revokeSignInSessions, EU (North Europe) container, least-privilege token.
prevHash
computing…
entryHash
computing…
requestId:
capstone-20260709183826
connector:
microsoft-graph-write
region:
northeurope
result:
value:true
Every action writes an append-only, hash-linked trail to Azure Postgres. Verification recomputes the chain and reports the first break: mutation, deletion or reordering.
What the obligations actually say
Designed around the control objectives behind these provisions.
Not “compliant with”, and not certified against anything. None of these instruments names a vendor or requires this product — they fund the capability and they require the records. The incident file is built to be the record.
GDPR Article 33(5)
Document the breach — the facts, its effects and the remedial action taken — so the supervisory authority can verify compliance.
NIS2 Article 23(4)
Early warning at 24 hours, notification at 72, final report one month after that notification is submitted.
ISO/IEC 27001 A.8.32
Change management. An auditor asks for the approved change record, not for a screenshot of the setting.
DORA RTS Article 21(e)(iii)
Withdrawal of access rights without undue delay upon termination — the obligation behind the Leaver playbook.
Integrations
What it reads and writes today.
Two systems are proven against a real tenant. Everything else is an adapter on the roadmap, built onto the same policy-gated, evidence-chained path. No connector is called live until it has run.
Microsoft Entra ID
Proven
Identity read and session-revocation write. The one live write action, run against a real tenant.
Jira Service Management
Proven
Read: tickets and search. Nothing is created or changed there today.
Microsoft Exchange
Adapter roadmap
Inbox-rule and forwarding removal for the Compromise playbook. New consent scopes, disclosed before they ship.
ServiceNow
Adapter roadmap
ITSM read and ticket writes planned on the same policy-gated path.
Okta
Adapter roadmap
Identity adapter planned beyond the current Microsoft Graph scope.
BambooHR, Personio, HiBob
Adapter roadmap
Joiner-mover-leaver lookups planned for the Leaver playbook.
Workday
Adapter roadmap
Enterprise HRIS adapter planned for the same evidence-chained pattern.
Microsoft Intune, Jamf
Adapter roadmap
Endpoint state and device actions planned, draft-only where destructive.
Google Workspace
Adapter roadmap
Workspace admin actions planned once the generic connector lands.
Custom REST APIs
Adapter roadmap
A generic OpenAPI adapter for arbitrary REST systems is planned.
For your operations team
Your team stays in control, and can prove that too.
The engine is a service in your operations stack. The whitelist lives in version control. The record lives in an append-only store you can export. The Exit Kit is the deliverable.
Whitelist as code
The 30-action register lives in version control. Each entry is a manifest: risk class, approval role, rollback, evidence fields. The engine reads it at startup, so what runs is what was reviewed.
Evidence export
Every action writes five hash-chained events to an append-only store. Export the trail per tenant and per request, with the instructions to verify it without us.
A kill switch that is yours
Revoke the application's consent in your own portal and execution capability ends immediately, without asking us. We drill it with you during the pilot rather than describing it.
Priced per tenant because the value does not scale with headcount, and because identity-priced tools compress any per-user figure toward zero. All figures exclude VAT; EU business buyers outside Malta reverse-charge.
One organisation
€299/mo
per tenant
One organisation, one tenant. Unlimited incidents, incident files included. Unlimited incidents, incident files included, support from one named engineer next business day.
Managed service providers
from €99/tenant/mo
minimum five tenants
The incident file is written in your client's name while your technician responds. What you do with it commercially is your business.
There is no checkout on this page, and that is deliberate. Turn-up needs an application registration your own administrator consents to, and an administrative-unit scope you choose. A card payment could not deliver any of that, so we do not pretend otherwise. The price is here so you can decide without a call; the call is how you buy.
Design-partner pilot
Three slots. Ninety days. A decision at the end.
No customer tenant has run this yet. A design partner gets the price that reflects that, and gives back the thing we cannot buy: a real tenant, a real incident, and an honest account of what broke. At day 90 you convert or you stop — an open-ended pilot is not on the menu.
Engagement
Design-partner pilot
€1,490 · 90 days · three slots
A scoping call that maps the moments you actually fear, and says plainly which of them this covers today
An application registration in your own tenant, consented to by your administrator, scoped to an administrative unit you choose
The first action whitelist agreed with you, by risk class, with anything irreversible excluded
Lab proof before anything touches your production tenant
Incident files from real runs — the artifact, not a sample
A kill-switch drill: you revoke consent in your own portal and watch execution stop
Exit Kit: the whitelist, the configuration and the evidence chain are yours to keep
What is explicitly not promised
No 24/7 and no response class faster than next business day. Nothing irreversible: no deletes, no wipes, no password or authentication-method resets, in any playbook, in any phase. No certification claims. No multi-tenant console yet.
One write action is proven against a real Microsoft 365 tenant: revoking a user's sign-in sessions, run on 9 July 2026 from an EU container, requested by one operator, approved by a different one, and sealed into a five-event hash-chained record. Everything else in every playbook is labelled roadmap on this page, and each step's status is read from the action register rather than typed by hand, so it cannot quietly overstate itself.
Who approves an action, and can the person who asked for it approve their own?
No. The runtime takes the approver's identity from their own credential and refuses with HTTP 403 when it matches the requester. The refusal is not a warning that can be clicked past, and it is written into the evidence chain like any other decision. That structural refusal is the product; the buttons around it are commodity.
What is the incident file?
The record you hand to someone else. It is generated from the verified evidence chain, so the "measures taken" section — GDPR Article 33(3)(d) — writes itself from what actually ran, with the requester, the approver and the timestamp for each step. It maps the remaining Article 33(3) fields explicitly, marks the ones only you can answer rather than inventing them, and lays out the NIS2 Article 23(4) cascade: 24 hours, 72 hours, and one month after that notification is submitted. It refuses to generate at all if the chain fails verification.
What does it cost?
€299/mo per tenant for a single organisation, and from €99/tenant/mo for managed service providers with a minimum of five tenants. All figures exclude VAT; EU business buyers outside Malta reverse-charge. There is no self-serve checkout, and that is deliberate: turn-up needs an app registration your administrator consents to, so a card payment could not deliver anything on its own. The design-partner pilot is €1,490 for 90 days, three slots, credited in full against your first year if you continue.
Does a language model decide anything?
No language model sits anywhere on the execution path. A request maps to a named action in a whitelist or it is refused, and the policy decisions are frozen by tests in CI — golden tickets, an injection corpus, and register-wide invariants. Hostile text inside an action parameter cannot change a policy decision, because parameters are data and never control. This is the deliberate design, not a stage we are waiting to grow out of.
What access does it need, and can we take it away?
A pilot starts with an application registration in your own tenant that your administrator consents to, scoped to an administrative unit you choose, with the verification output kept by you. You revoke that consent in your own portal, without asking us, and execution capability ends immediately. No customer tenant has run this yet — you would be the first, which is what the design-partner price is for.
What support comes with it?
One named engineer, next business day, in writing. Not 24/7, and no faster tier exists to upsell you to. If a response time in minutes is what you need, this is the wrong product and we would rather say so now than in your first incident.
What happens if we leave?
The whitelist, the configuration and the evidence chain are yours, exported in machine-readable form with the instructions to verify the chain independently. Per-tenant credentials are deleted and the deletion is confirmed in writing. The engine stops; your record stays.
One person acts. Another approves. The record writes itself.
Book a scoping call. Thirty minutes, and it ends with a plain answer about which of the four playbooks covers what you actually fear, and which of them we have not built yet.
Trigger: security alert. User reports phishing, stolen token still valid.
triggerTicket arrives
Operator hoist-trigger submits graph.session.revoke. The actor identity comes from the authenticated operator credential.
action_plannedAction matched to the whitelist
Matched against the 30-action register. Anything off the list stays unavailable to the model, and no free-form command ever reaches Graph.
policy_decidedPolicy decision
Risk class R2 requires approval by role security_admin. Irreversible-adjacent writes get a human gate before anything runs.
approval_requestedApproval requested
Fan-out to three channels. The notification carries a signed link and a summary, never secrets. Native in-channel buttons are on the roadmap.
Signed linkTeams cardSlack blocks
approval_grantedA second operator approves
A different operator, sec-admin-1, grants on the signed page. Separation of duties is enforced by the approval engine.
self-approval by hoist-trigger returns 403
action_executedSessions revoked
Graph POST /users/{id}/revokeSignInSessions returns value: true, executed from the North Europe container with a least-privilege write app.
chain_verifiedEvidence sealed
Five events hash-chained in Azure Postgres under an append-only role. Genesis verified and every link checks out.
Waiting for trigger...
Stage 1 of 7...
TriggerWaiting for triggerSealed
Waiting for trigger
Denied branches: refused by the policy engine
self-approval by hoist-trigger: 403give me Global Admin: R3, blocked even with approval
Representative playback of the proven lab run (2026-07-09). Actions, guardrails and escalation are configured per tenant during the design-partner pilot.