Case study·Platform

Permission and review policy setup

From a default-allow assistantto 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.
IT Lead · Mid-market enterprise (regulated)
01Pilot envelope
Pilot length3 weeks
First signal5 days
First ROI21 days
Team alongside8 seats · 2 colleagues

3-week governance sprint; Co-ordinator modelled principals, resources and approval policies; dry-run policies tested before any live workflow use.

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
OktaMicrosoft EntraSlackMicrosoft TeamsGoogle DriveSharePointHubSpotWorkflow inventoryWorkflow audit log
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 0
    Co-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 5
    First 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 10
    Resource model liveChannels, folders and CRM record sets registered as named resources; the workflow inventory references them by name in its draft policies.
  • Day 15
    Dry-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 21
    Security 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.
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.