Hard fencing (access scope governance)

Restrict system credentials to approved users via remote identity-provider groups — the difference between "this integration can read every mailbox in the tenant" and "this integration can read mailboxes for these workspace members only".

System credentials (OAuth client_credentials) are powerful by default. A Microsoft 365 app registration set up for the platform can read every mailbox, calendar, and SharePoint site in your tenant — the same is true for most cloud vendors that offer service-principal-style credentials.

Hard fencing is the platform's mechanism for narrowing that reach. Once enabled, a system credential is restricted to the members of a specific identity-provider group (e.g. a Microsoft Entra ID Security Group), and the platform keeps that group in sync with the relevant workspace's membership.

Hard fencing is optional, but strongly recommended for any system credential that grants tenant-wide access. The setup wizard makes it a one-time configuration.

When to use it

Use hard fencing when:

The integration uses a system credential (client_credentials grant), not per-user OAuth.
The credential's effective scope is broader than the workspace using it (e.g. "all of Microsoft Graph" instead of "this user's mailbox").
You want workspace membership changes to flow automatically to the security group, without manual sync.

You do not need hard fencing for per-user OAuth integrations (each user authenticates themselves), API-key integrations scoped to a specific resource, or system credentials that are already narrowly scoped at the vendor.

How it works

   Workspace                          IdP Security Group
   ┌──────────────────────┐           ┌──────────────────────┐
   │  - Maya  (member)    │  ◀────▶   │  - Maya              │
   │  - John  (admin)     │   sync    │  - John              │
   │  - Sarah (owner)     │           │  - Sarah             │
   └──────────────────────┘           └──────────────────────┘
                                                │
                                                │ controls who the system
                                                │ credential is allowed to
                                                │ act on behalf of
                                                ▼
                                      System credential
                                      (e.g. M365 app registration)

The platform syncs the workspace members to the security group. The system credential's access policy at the vendor (e.g. Microsoft Graph's RBAC for Applications) restricts the credential to act only on members of that group.

Setup

Hard fencing is configured per workspace credential through the Governance Wizard under Settings → Integrations → Microsoft → Workspace credentials → Configure governance.

The wizard opens with a setup guide for your identity provider. Today this is supported for Microsoft Entra ID Security Groups.

Follow the setup guide. The guide walks you through:

Creating a Security Group in Entra ID (named e.g. Scrydon — Workspace Alpha).
Assigning the system credential's App Registration access via RBAC for Applications, scoped to the Security Group.
Copying the Security Group's Object ID for the next step.

Paste the Security Group's Object ID into the wizard. The wizard validates that:

The system credential's App Registration has the required Graph permissions (Group.Read.All minimum; GroupMember.ReadWrite.All for sync).
The Security Group is reachable.
Initial membership is empty or already aligned with the workspace.

Click Sync Now. The platform:

Reads the current Security Group membership.
Compares it to the workspace's member list.
Computes the delta — adds and removes.
Calls the IdP to apply the delta.
Records every mutation in the audit log as INTEGRATION_ENTITLEMENT_* events.

Open the IdP and confirm the Security Group's membership matches the workspace. From the wizard, the Members tab shows the live IdP view next to the workspace view.

After this one-time setup, the platform keeps the group in sync automatically — see below.

Auto-sync events

After setup, the platform syncs membership on every relevant workspace event:

Event	Triggers sync?	What happens
Add workspace member	Yes	New member added to the IdP Security Group
Remove workspace member	Yes	Removed member taken out of the Security Group
Accept workspace invitation	Yes	The new member is added once acceptance completes
Add team to workspace	Yes	All team members synced
Remove team from workspace	Yes	Team members may lose Security Group membership (kept if they're also direct members)
Configure hard fence (set scope ID)	Manual	The initial sync is "Sync Now" in the wizard — automatic after that

User-to-vendor identity mapping

The platform needs to know each Scrydon user's identity in the vendor (e.g. the Entra ID user object ID) to add or remove them from the group. The mapping resolves in this order:

Email lookup — the platform looks up the user in the IdP by their primary email.
Linked OAuth account — if the user has connected their own OAuth account for the same provider, the linked account's vendor-side user ID is used.
Skip with warning — users that can't be mapped are logged as warnings; the rest of the sync continues. Unmappable users typically need an admin to reconcile mailbox / directory state at the vendor.

The unmapped-users count appears in the wizard's Status panel and on every sync's audit log entry.

Removing hard fencing

To take a credential off hard fencing, open the wizard and click Disable governance. The platform:

Stops syncing the Security Group on workspace events.
Leaves the Security Group itself intact at the vendor (you can clean it up manually).
Reverts the system credential to its broader default scope.

Disabling is itself an audit event — INTEGRATION_ENTITLEMENT_DISABLED.

Troubleshooting

"Insufficient privileges" on initial sync

Most common cause: the App Registration backing the system credential does not have the GroupMember.ReadWrite.All Graph permission with admin consent granted. Fix it in Entra ID under App Registrations → API permissions.

Users keep getting skipped as "unmappable"

The email Scrydon uses (the user's primary email) does not match any user object in Entra ID. Either fix the user's email in Scrydon, or have them link their own OAuth account so the platform can find them via the linked vendor account ID.

The Security Group is missing members after a sync

Check the audit log for the most recent INTEGRATION_ENTITLEMENT_SYNC event. The event records the delta the platform computed and which add / remove calls succeeded or failed. A failed addMember is logged as an error with the vendor's response body.

Workspace member changes are not flowing to the IdP

Verify auto-sync is enabled in the wizard. If it is and changes still aren't flowing, check that the system credential's access token has not expired — system credentials use the OAuth client_credentials grant and need refresh just like any other credential. The wizard shows the token's expiry in the Status panel.

Identity & Provisioning (SCIM) — the user-side counterpart to hard fencing.
Permission model — three-tier authorisation hierarchy.
Audit logging — every sync mutation is auditable.
Security → Secrets management — where the system credential's tokens live.

Hard fencing (access scope governance)

On this page