3-week governance sprint; Co-ordinator modelled principals, resources and approval policies; dry-run policies tested before any live workflow use.
Operating layerOnboardingAI teammates
Five category pages for sector-specific case studiesView categories →
Case study·Platform
Permission and review policy setup
From a default-allow assistant — to scoped principals, resources and reviewed approval policies
34
Grants rationalisedOver-broad Okta and Entra grants reduced to the minimum the workflow needs
“The assistant had boundaries before it had power.”
Mid-market enterprise (regulated)·~500 staff across 3 regulated business units·3-week governance sprint·United Kingdom and Ireland
01Pilot envelope
Pilot length3 weeks
First signal5 days
First ROI21 days
Team alongside8 seats · 2 colleagues
02What it owns
Reports toIT Lead, dotted line to the Data Protection Officer on regulated-data scopes.
Owns
- Principal model — every virtual colleague mapped to a named identity in Okta or Entra with the minimum group set the workflow needs
- Resource model — Slack and Teams channels, Drive and SharePoint folders and CRM record sets defined as named resources the policies refer to
- Approval policy catalogue — read, draft and write policies for each workflow with the review rule, escalation owner and SLA written in plain language
- Dry-run pack — every candidate policy replayed against the historical workflow audit log with the would-allow and would-block list ready for security to review
- Quarantined sign-off — every policy lands in a SharePoint review folder; nothing is enabled in production until the IT lead approves it line by line
Does not do
- Granting access — proposes the minimum scope, the workspace administrator grants
- Closing a security finding — surfaces the dry-run evidence, the IT lead closes
- Deciding regulated-data classification — escalates to the Data Protection Officer
Done looks like
Security can answer 'what could this colleague do' before it does anything. Every live workflow inherits a reviewed policy with a named owner, and the next workflow is one approval cycle away — not a renegotiation.
03The team
AI teammates2
TheoReads identity, channel, folder and CRM scopes and models them as principals, resources and policies the security team can sign off on.







MayaDry-runs each candidate policy against the historical workflow audit log, surfaces what would have been allowed or blocked and prepares the review packet for security.


Human team8
- Workspace administratorIT
- IT and security leadIT
- Data Protection OfficerLegal
- Workflow team leadOperations
- Operations managerOperations
- Legal counselLegal
- Unify customer success leadUnify
- Data ownerData
04Connected stack
05What it returned
34Grants rationalisedOver-broad Okta and Entra grants reduced to the minimum the workflow needs
9Risky write paths blockedSurfaced by the dry-run replay before any live workflow used them
1 cycleApproval rules accepted by securityWorkflow approval rules signed off in a single review cycle
- Day 0Co-ordinator sessionIT lead, DPO, workspace admin and the workflow team lead align on the principal, resource and policy taxonomy and the first three policies to model.
- Day 5First signalTheo completes the read-only pass over Okta, Entra, Slack, Teams, Drive and SharePoint; the first 34 over-broad grants are surfaced for review.
- Day 10Resource model liveChannels, folders and CRM record sets registered as named resources; the workflow inventory references them by name in its draft policies.
- Day 15Dry-run replayMaya replays the candidate policies against the historical workflow audit log; 9 risky write paths surfaced and rewritten before any live workflow uses them.
- Day 21Security sign-offIT lead and DPO accept the workflow approval rules in a single review cycle; the first live policies graduate from the SharePoint quarantine folder.
06Related templates
↗Get started
Want this for your team?
Each design-partner pilot starts the same way: one workflow, the minimum useful context, and a first ROI signal measured in days.
