By NHI Mgmt Group Editorial TeamBased on WorkOS: “Widget Skills: WorkOS-powered UIs, generated for your stack” (March 20, 2026)

TL;DR: The governance issue is not the workflow itself, but who can generate, modify, and ship identity-related code inside production repositories, while Widget Skills let AI coding agents generate app-native implementations of enterprise workflows such as user management, domain verification, and SSO setup, keeping the same underlying APIs and letting teams own the code in their own stack, according to WorkOS.


At a glance

What this is: WorkOS describes Widget Skills as a way to generate app-native enterprise workflows, such as user management and SSO setup, directly into a customer codebase using the same underlying APIs as Widgets.

Why it matters: This matters because IAM teams must govern identity-related code generation, review and ownership inside the application stack, not just the workflow surface delivered to users.


Context

Widget Skills are a code-generation pattern for enterprise workflows: instead of dropping a workflow into an embedded component, the same function is generated directly into the application’s own framework, routing and design system. The identity governance issue is not whether the workflow exists, but how identity-related code is created, reviewed and maintained once it lives in the product repository.

For IAM and NHI practitioners, that shifts attention from UI embedding to application ownership. User management, domain verification and SSO setup remain identity-critical flows, but the control question becomes whether AI coding agents are allowed to generate or alter those flows without a clear review boundary and change-management process.


Key questions

Q: How should security teams govern AI-generated identity workflows in application code?

A: Treat them as controlled code changes, not convenience scaffolding. AI-generated identity workflows should go through the same review, testing, and release gates as any other access-related implementation because the generated output can alter role assignment, invitation handling, and SSO setup behaviour inside production code.

Q: Why do app-native identity workflows create governance risk for IAM teams?

A: Because the workflow is no longer isolated behind a fixed embedded surface. Once identity logic lives in repository-owned code, teams must govern code provenance, policy drift, and approval boundaries across development, security, and release management.

Q: What should security teams check before allowing coding agents to generate SSO or user-management code?

A: They should check whether the agent can write to repositories that contain identity logic, whether a human approves the resulting pull request and whether the deployment pipeline can block unreviewed changes from reaching production.

Q: How do you keep customized identity workflows consistent with policy?

A: Separate the policy decision from the presentation layer. The organisation should define which elements are fixed by identity policy, which can be styled or routed locally and which require explicit security sign-off before they change.


How it works in practice

How app-native workflow generation changes the control surface

Widget Skills use AI coding agents to generate code for enterprise workflows directly into the customer application, rather than serving them only as an embedded widget. That matters because the security boundary moves from a hosted UI component to source code, build pipelines and repository governance. The same underlying APIs still power the workflow, but the implementation now inherits whatever controls exist around code review, branch protection, dependency hygiene and deployment approval. In practice, the workflow itself may be stable while the delivery mechanism becomes more exposed to accidental change or malicious modification.

Practical implication: treat generated workflow code as production code subject to the same review and release controls as any other identity-critical change.

Why identity workflows become code ownership problems

When user management, domain verification or SSO setup are generated into an application stack, identity governance no longer stops at the access control decision. Teams now own the implementation details, including route structure, UI behaviour, data handling and error states. That expands the attack surface because identity logic is now part of a codebase that may be extended by developers or generated by agents over time. The main risk is drift: the workflow still looks standard, but local customisation can create inconsistent enforcement, hidden exceptions or unreviewed changes to trust boundaries.

Practical implication: require a named owner for each identity workflow in code and keep policy, implementation and release approval tied together.

What AI coding agents change in enterprise identity delivery

AI coding agents do not change the underlying identity APIs, but they do change who can author the implementation and how quickly that implementation can evolve. That speed is useful, but it also compresses the window in which teams notice unsafe customisation, privilege creep or fragile assumptions inside generated code. For NHI governance, the important question is not whether the agent is autonomous in the formal sense, but whether it can produce identity-bearing code faster than the organisation can review it. That is a governance and assurance problem, not just a developer-experience problem.

Practical implication: define review gates for agent-generated identity code before it is merged, not after users depend on it.


NHI Mgmt Group analysis

App-native workflow generation turns identity governance into code governance: when enterprise identity flows are generated into the repository, the decisive control is no longer the embedded UI boundary but the repository and release boundary. That shifts assurance into code review, branch protection and change control because identity logic is now editable product code. Practitioners should treat the generated workflow as a governed application asset, not a convenience layer.

AI coding agents change the speed at which identity assumptions can drift: the article describes a development model where a coding agent can generate user management, domain verification and SSO flows directly inside the app. That means approved API behaviour can still be wrapped in locally customised code that diverges from the original workflow intent. The practical conclusion is that speed without review discipline creates identity drift inside otherwise standard enterprise flows.

Generated code in the repository creates a durable accountability chain: once the workflow lives in the customer stack, the team owns the implementation, not just the feature request. That strengthens auditability when review is real, but it also makes ownership explicit in a way embedded widgets often do not. App-native identity control plane: this is the governance pattern that emerges when identity workflows are implemented where product code, release approval and policy enforcement intersect.

This model raises the bar for NHI governance around development tooling: AI coding agents become part of the identity delivery chain even when they are not themselves the identity subject. The question for practitioners is whether the organisation can distinguish safe generation of identity flows from unreviewed changes to those flows. That distinction should sit in the application security and identity governance programme, not in developer convenience alone.

From our research library:

What this signals

App-native identity flows: once authentication and provisioning logic is generated into the application repository, the control problem shifts to source control, review and release governance. That is where teams should expect drift, because the workflow can be correct at the API layer while the implementation quietly diverges in local code.

Identity programmes need to decide whether AI coding agents are allowed to author identity-bearing code at all, or only to assist under human approval. The practical boundary is not the API call itself, but the ability to introduce unreviewed changes into the code that handles trust decisions.


For practitioners

  • Define review gates for generated identity code Require pull request review, ownership approval and deployment checks for any code that implements user management, domain verification or SSO setup generated by a coding agent.
  • Separate workflow policy from UI customisation Document which parts of an identity flow are fixed policy, which are allowed presentation changes and which require security sign-off before they can be edited.
  • Inventory AI coding agent access to production repositories Track which agents can write or modify code in repositories that contain authentication, provisioning or access-management logic, and revoke unnecessary permissions.
  • Establish ownership for each identity workflow Assign a business and technical owner to every generated workflow so changes to role assignment, invite flows and SSO setup have clear accountability.
  • Test generated flows against deployment guardrails Check that routing, error handling and data-handling changes introduced by generated code still conform to your secure SDLC and release standards.

Key takeaways

  • WorkOS’s Widget Skills move enterprise identity workflows from embedded components into customer codebases, which changes the control surface from UI delivery to source control and release governance.
  • The main governance issue is no longer whether the workflow exists, but who can generate, inspect and modify identity-related code inside production repositories.
  • Teams need review gates, ownership and deployment controls for agent-generated identity logic or they will inherit implementation drift inside otherwise standard IAM flows.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Agentic AI Top 10, OWASP Non-Human Identity Top 10 and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Agentic AI Top 10ASI03 — Identity & Privilege AbuseAI coding agents are generating identity-bearing code that can alter access behaviour.
Recommendation — Constrain agent-generated identity code changes behind human review and least-privilege repository access.
OWASP Non-Human Identity Top 10NHI-10 — Human Use of NHIThe article centers on AI coding agents acting on behalf of developers inside production repos.
Recommendation — Define when coding agents may act on identity workflows and require human approval for sensitive changes.
NIST SP 800-53 Rev 5CM-3 — Configuration Change ControlGenerated workflow code becomes a governed production change in the application stack.
Recommendation — Apply CM-3 to review and approve agent-generated identity code before it reaches production.
NIST CSF 2.0PR.AA-05 — Access Permissions, Entitlements and AuthorizationsThe article is about controlling identity logic and authorisation behavior embedded in app code.
Recommendation — Use PR.AA-05 to govern who can alter access-related application logic and identity flows.
OWASP API Security Top 10API5 — Broken Function Level AuthorizationIdentity workflows still depend on correctly constrained function access through the underlying APIs.
Recommendation — Verify that generated flows only expose the functions intended for each role or access path.

Key terms

  • App-native identity workflow: An app-native identity workflow is an access or verification flow implemented directly inside the customer’s own application code rather than delivered only as a fixed embedded component. It improves flexibility, but it also makes governance depend on the organisation’s repository, review, and release controls.
  • AI Coding Agent: An AI coding agent is software that writes, edits, reviews, or tests code with limited human prompting. It operates as an agentic system that can plan actions, call tools, and modify development artifacts, so its identity, permissions, and audit trail must be governed like any other privileged software actor.
  • Generated identity code: Generated identity code is code created by an AI coding agent from a prompt or skill package to implement identity-related functionality such as user management or SSO setup. It is still production code, so it must be reviewed for policy drift, access behaviour, and release integrity.
  • Workflow Governance: Workflow governance is the control layer that defines who or what can act, which tools are available, what must be logged, and when approval is required. It sits outside execution logic so policy remains consistent, auditable, and enforceable across frameworks and providers.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
NHIMG Editorial Note
Published by the NHIMG editorial team on June 6, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org