Notifications
Clear all
Topic starter
22/06/2026 10:24 am
TL;DR: App teams are pushing identity controls deeper into developer workflows as August updates add standalone OAuth for MCP, BYOK support in Vault, disposable email blocking, and OIDC attribute mapping, according to WorkOS. The pattern matters because authentication, key governance, and signup abuse are converging into one operational identity surface.
NHIMG editorial — based on content published by WorkOS: August updates covering standalone OAuth for MCP, BYOK in Vault, disposable email blocking, and OIDC attribute mapping
Questions worth separating out
Q: How should security teams govern OAuth access for MCP servers?
A: Treat each MCP server as a delegated identity surface with explicit scope, token lifetime, and revocation ownership.
Q: When does BYOK meaningfully improve vault governance?
A: BYOK helps when the organisation needs independent control over encryption key lifecycle, revocation, and audit evidence.
Q: How do custom OIDC attributes affect identity lifecycle control?
A: Custom OIDC attributes matter because they determine whether provisioning, entitlement assignment, and offboarding receive consistent identity data.
Practitioner guidance
- Govern MCP OAuth as delegated application identity Define the scopes, refresh behaviour, token revocation path, and owner for every MCP server that can touch enterprise data.
- Separate vault key custody from application administration Require documented ownership for customer-managed keys, including KMS policy review, revocation authority, and break-glass access.
- Normalize OIDC claims before they reach downstream systems Map external identity provider attributes to a stable internal profile model and test the mapping against provisioning, role assignment, and audit events.
What's in the full article
WorkOS's full update covers the operational detail this post intentionally leaves for the source:
- How WorkOS Connect handles enterprise OAuth setup for MCP servers in practice
- The Vault BYOK setup flow for connecting AWS KMS and managing customer-owned keys
- The exact OIDC attribute mapping options for standard and custom profile fields
- The disposable email domain subscription workflow and signup-blocking behaviour
👉 Read WorkOS's August update on MCP OAuth, BYOK, and identity controls →
MCP OAuth and vault BYOK: what it means for IAM teams?
Explore further
22/06/2026 11:18 am
MCP authentication is becoming an identity governance problem, not just an integration problem. Once an MCP server exchanges OAuth tokens for enterprise access, it inherits the same accountability questions that IAM teams already handle for delegated application access. The difference is that MCP now sits closer to AI-assisted workflows, which makes scope design and token containment more sensitive than conventional app auth. Practitioners should treat MCP onboarding as part of the broader machine identity estate.
A few things that frame the scale:
- 62% of all secrets are duplicated and stored in multiple locations, causing unnecessary redundancy and increasing the risk of accidental exposure, according to The 2025 State of NHIs and Secrets in Cybersecurity.
- 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches.
A question worth separating out:
Q: Why do disposable email controls belong in identity governance?
A: Disposable email controls reduce low-quality account creation and help protect free trials and self-service onboarding from abuse. They belong in identity governance because signup hygiene affects downstream access quality, fraud exposure, and support burden. They work best when paired with broader risk signals rather than used as a standalone defence.
👉 Read our full editorial: MCP OAuth and vault BYOK tighten identity controls for apps
