Upgrade the identity path before adding more automation.
Enterprise AI makes identity more important, not less. When a user asks an agent to act, the architecture should still be able to answer a basic question: whose authority is being used at the protected resource?
SSO is useful; identity continuity is more useful
A modern sign-on removes password friction, but the larger architectural value is that the enterprise identity can become the consistent starting point for downstream execution. That matters when the same user moves from browser access to Orchestrations, MCP tools or AI-mediated actions.
XpreSSO
Modern identity-provider integration for newer EnterpriseOne environments where the available JDE platform capabilities support that path.
ESI JDE SSO Suite
Established SSO for EnterpriseOne with broad deployment flexibility and an identity base that can also feed newer AI integration patterns.
Why identity belongs in the upgrade plan
Traditional JDE upgrades often focus on release mechanics first and user access later. For a modern capability upgrade, that order can be reversed. Once identity is stable, every later layer can make clearer decisions about the user, the agent and the backend being invoked.
- Users sign in with the enterprise identity already governed by the organisation.
- JDE actions can remain attributable to the actual JDE user rather than a pooled integration identity.
- Windows/AD resources can continue enforcing their existing ACLs where the execution path preserves user authority.
- Audit records can distinguish human, agent and backend rather than collapsing everything into one service account.
Identity for AI is not only authentication
An AI client may authenticate successfully and still execute downstream work under a completely different authority. That can be acceptable for API-backed systems where a deliberately scoped service credential is the correct model. It is less satisfactory where the enterprise already has mature per-user permissions on Windows resources.
Steward is designed for the latter case: after an upstream policy decision allows the call, the downstream resource can still see the human user's Windows/AD authority instead of a substituted shared identity.
“Who authenticated to the AI gateway?” and “who is authorised by the final resource?” are related, but they are not automatically the same thing.