HOIST.
It revokes the compromised account before a human wakes up.
The agent acts inside a whitelist, on the record, in the EU.
HOIST resolves Tier-0 internal requests by taking the action, not just describing it. Today it runs identity remediation end to end: a request to revoke a compromised user’s sessions is classified, gated by policy, approved by a second operator, executed against Microsoft Graph from an EU container, and sealed into a hash-chained audit log. Anything outside the approved action list is not available to the model. Anything elevated stops and waits for a named human.
Microsoft Graph session revocation, executed against a real M365 tenant from an EU container.
From action_planned to action_executed, every event hash-linked and tamper-evident.
Separation of duties is enforced: the operator who submits an action cannot approve it.
North Europe container and Azure Postgres, managed identity, TLS verify-full.
Watch one run: request to revoked, on the record.
This is the one flow HOIST has actually executed live: a compromised-account session revoke, run from an EU container against a real Microsoft 365 tenant. Play it, scrub back to the policy decision, and open the evidence on any stage.
Your engineers are the incident-response bottleneck.
Internal IT and security queues are full of work that requires no judgement and no senior context, yet still waits on a human because acting is risky. The same containment step, the same access request, the same audit question, thousands of times per year, at the expense of every initiative the team should be working on.
A phished account stays live while a human sleeps
A user reports a phishing click at 2am. The stolen token is still valid. The account sits live for 48 hours, waiting for someone to log in and revoke the sessions by hand.
Internal SLAs measured in days
New-hire access requests queue up behind incident response. The leaver who needs their account locked waits 48 hours. The auditor who asks "show me who has admin" gets a manually-assembled spreadsheet.
Generic chatbots that route everything to a human anyway
The "we have an AI helpdesk" project that recognises a handful of intents and escalates the rest. Users learn to skip the bot. The investment becomes the office joke.
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.
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.
Proven in the lab
- Live Graph write, executed
session.revoke ran against a real Microsoft 365 tenant from an EU (North Europe) container. Capstone requestId capstone-20260709183826.
- Microsoft Graph identity read
Users, group membership and licences read from the tenant today.
- Jira Service Management read
Ticket read and search. Read-only: no ticket is created or changed today.
- Policy engine, R0 to R3 plus D
30-action whitelist. Every action is classified before it runs; elevated actions stop for a human.
- Approval loop with separation of duties
The operator who submits an action cannot approve it. Three notification channels: signed link, Teams webhook, Slack webhook.
- Hash-chained, tamper-evident audit trail
Five events per action, persisted in Azure Postgres. Genesis check and chain links both verified.
- Eval harness as a CI gate
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.
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.
Prove what happened to an auditor.
Every action writes five hash-linked events to an append-only store in the EU. The chain detects mutation, deletion or reordering. Try it: verify the sample chain, then tamper with an event and watch the break surface.
Every action writes a hash-chained trail
Sample data from the proven lab run: the 5 events persisted for capstone request capstone-20260709183826.
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
Risk class R2, requires approval by role security_admin.
- prevHash
- computing…
- entryHash
- computing…
- requestId:
- capstone-20260709183826
- riskClass:
- R2
- decision:
- requires_approval
- approvalRole:
- security_admin
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
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
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.
DORA. NIS2. GDPR. ISO 27001. Alignment, documented.
A control mapping ties HOIST's mechanisms to the frameworks above, and the hash-chained trail gives an auditor a verifiable record of every action. This is alignment evidence. HOIST claims no certification. The evidence pack is part of the pilot deliverable.
Third-party ICT-risk evidence: model provider, hosting region, sub-processors, exit strategy.
Technical baseline: MFA-bound action surface, audit logging, incident-response integration.
Records of processing produced as a side effect; data subjects, categories and retention documented.
A.5 organisational and A.8 technological controls mapped per action class with timestamped evidence.
What HOIST 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.
Input language is not a separate workflow.
Routing is deterministic against the whitelist, so the policy gate and the audit trail stay identical whatever language the request arrives in. When language-model assistance for intent routing lands, requests in the major European languages will ride on that same whitelist and evidence chain. The audit trail records the operation in your canonical reporting language for regulatory consistency.
Your operations team stays in control.
The agent is a service in your operations stack. The whitelist lives in version control. The audit trail lives in an append-only store you can export. The Exit Kit is the deliverable.
The 30-action register lives in version control. Each entry is a manifest: risk class, approval role, rollback flag, evidence fields. The agent reads it at startup, so what runs is what was reviewed.
Every action writes five hash-chained events to an append-only store. Export the trail per tenant and per request for your auditor. Any mutation, deletion or reordering is detectable.
One command exports the whitelist, the prompts, the action-library configuration and the audit trail in machine-readable format. The agent stops; your data stays. No lock-in.
Start with one scenario. Keep everything.
HOIST runs as a scoped design-partner pilot. There is no self-serve checkout. Every engagement starts with a scoping call, and every engagement ends with an Exit Kit.
Design-partner pilot
- A scoping call to map your repetitive scenarios and score them for fit
- The first action whitelist agreed with you, by risk class
- Lab proof: your scenarios run end to end against a test tenant
- An evidence pack: the hash-chained audit for every proven action
- Exit Kit: the whitelist, the configuration and the audit trail are yours to keep
What scales later
Multi-department rollout, and regulated or sovereign options for DORA and NIS2 estates. Each is scoped to you and quoted after the pilot proves the first scenarios.
Prefer to own the deployment outright instead of running it with us? Scope a bespoke implementation.
The questions internal-ops leads ask before a pilot.
Will HOIST act on its own without our approval?
Only inside the action whitelist you approve, and only within the policy class each action carries. Reads run automatically. Elevated writes stop and wait for a named approver who is not the operator who triggered them. Anything off the whitelist is not available to the agent in the first place.
How is HOIST different from a helpdesk chatbot?
A chatbot answers questions. HOIST executes a whitelisted action against a real system and records it. Today that means one proven write, session revocation, run against a live Microsoft 365 tenant, gated by policy, approved by a second operator, and sealed into a hash-chained audit log.
Where does the inference happen, and which model chooses the action?
Today no language model chooses actions. Routing is deterministic against the whitelist: a request maps to a named action or it is refused. When LLM assistance for intent routing lands, it will run EU-resident under the cloud provider's data protection terms, and a self-hosted open-weights option is on the roadmap.
What audit evidence do we get?
Five events per action: action_planned, policy_decided, approval_requested, approval_granted, action_executed. Each is hash-linked to the last and stored in an append-only Azure Postgres table in the EU. Verification recomputes the chain and reports the first break from mutation, deletion or reordering. Regulatory mapping to DORA, NIS2, GDPR and ISO 27001 is provided as alignment evidence per action.
How do we start, and how long does it take?
Every engagement starts as a scoped design-partner pilot. A scoping call maps your scenarios, you agree the first action whitelist, and HOIST proves those actions in the lab before anything touches production. The timeline depends on the scenario set and the systems in scope, which is why it is quoted after that call.
What happens if we want to leave?
The whitelist, the configuration and the audit trail are yours, exportable in machine-readable format. The agent stops; your data stays. If you want to own the deployment outright rather than run it with us, scope a bespoke implementation.
Stop running senior engineers on Tier-0. Start with one scenario.
Book a scoping call. We map your repetitive scenarios and agree the first action whitelist you want proven in the lab. No obligation, no high-pressure pitch.
Prefer written scope first? Email us