September 2026 Summaries

At LDX3 NYC, a conference for senior engineers and engineering leaders, discussions centered on how AI is changing software teams, including the implications of AI-generated code, uncertainty over which tools are genuinely useful, and concerns that automating junior-level tasks may weaken future talent development. Conversations at the event particularly emphasized agentic identity and authorization, with a proposed approach for allowing agents to act on a user’s behalf in third-party tools such as Notion while restricting access to sensitive resources. Where providers do not offer granular native permissions, the approach uses an identity provider, on-behalf-of token exchange, a gateway that enforces rules, and a secure credential store that injects the user’s real third-party credential only after validating the agent’s token, audience, and subject. Survey findings presented at the conference added urgency: 69% of teams using AI in software development lack a plan to measure its effectiveness, while 24% allow developers to use personal credentials for AI tools, limiting auditability, separate access controls, and revocation. The account argues that agents should always receive distinct identities and access tokens so organizations can monitor their actions, constrain permissions, and determine whether a human or an agent caused an incident.

Model Context Protocol (MCP) servers using HTTP rely on OAuth, with clients obtaining and presenting access tokens while servers enforce token permissions rather than directly authenticating users. Clients may act independently through client credentials or, more commonly, act on behalf of users through the authorization code flow and consent. MCP supports static pre-registration for known clients, but automated registration is better suited to broad, unknown client ecosystems; the newer Client ID Metadata Document (CIMD) approach uses a URL-hosted JSON configuration and TLS-based domain identity, while authorization servers retain discretion through trust policies such as allowlists and domain checks. Dynamic Client Registration (DCR), an older standard, is deprecated in the July 2026 MCP specification and should be used only for compatibility during migration. Public clients generally require PKCE because they cannot securely retain secrets, while private_key_jwt may provide stronger authentication where supported. Security is layered through server-selected authorization issuers and scopes, authorization-server client policies, user authentication and consent, and refresh-token controls. The recommended registration approach depends on the audience: consumer and SMB services should generally use CIMD, developer-focused services may tolerate pre-registration, and enterprise deployments should use MCP’s enterprise-managed access extension.

Frontend-only single-page applications face token-theft risks even when using secure transport and HttpOnly cookies, because stolen bearer tokens can be reused from another client. FusionAuth Enterprise supports Distributed Proof of Possession (DPoP), an OAuth 2.0 sender-constraining mechanism defined in RFC 9449 that binds tokens to a browser-generated key pair, requiring each request to include a signed proof tied to the request method, URI, time, and token. The tutorial demonstrates securing a React application with FusionAuth’s JavaScript SDK by configuring the provider, protecting routes through login-state checks, and adding login and logout controls through the SDK’s hook. Enabling DPoP requires setting `useDpop` in the provider configuration and updating FusionAuth CORS settings to allow the DPoP and authorization headers from the frontend origin. FusionAuth’s React, Vue, and Angular SDKs handle the underlying cryptographic proof generation and validation workflow, reducing the implementation effort while limiting the usefulness of stolen tokens unless an attacker also has the associated private key.

Customer-facing AI changes identity management by allowing software agents to interpret user intent and perform actions across data, tools, and applications, creating authorization requirements beyond conventional login verification. Organizations need to maintain a traceable link among the user, AI system, task, resources, permissions, and resulting actions while enforcing limits based on scope, duration, context, and risk, including step-up authentication for sensitive operations. Fragmented identity systems across products can make these controls inconsistent and require custom integrations, increasing implementation complexity and errors. Detailed audit records are also needed to explain who initiated an AI task, what permissions were used, what systems were accessed, and whether additional verification occurred. The text argues that companies should assess and modernize identity infrastructure as part of AI readiness, and presents FusionAuth as a deployable identity platform intended to support accountable, context-aware AI-enabled actions.

Authentication systems can accumulate “identity debt” gradually, remaining functional while increasingly slowing releases, requiring workarounds, and creating operational risk. Key indicators that a company has outgrown its current solution include identity-related changes delaying product delivery, enterprise requirements such as SSO, MFA, tenant isolation, and custom workflows becoming expensive one-off projects, and critical system knowledge being concentrated in a small number of engineers. Additional signs include a growing backlog of deferred security improvements and unpredictable costs, performance, or architectural limitations as the business expands across products, regions, user volumes, or acquisitions. The original authentication choice may have been appropriate at the time, but organizations should reassess it as business needs, security threats, and customer expectations evolve. FusionAuth presents its platform as a customizable customer identity solution intended to help organizations modernize deliberately while retaining control over their architecture, data, and user experience.

SaaS became widely adopted by eliminating installation, infrastructure, upgrade, and operational responsibilities, but the passage argues that treating hosted software as the only modern option can create limitations, particularly for identity systems. Because identity governs user access, protected data, security, compliance, availability, architecture, and costs, selecting an identity provider is presented as a long-term architectural decision rather than a simple product purchase. A SaaS-only provider can simplify operations but may restrict an organization’s ability to address future needs such as data residency rules, alternative deployment models, acquisitions, outage risk, integrations, and growing usage costs. The passage contends that dependency can deepen as applications and processes become tailored to a provider’s assumptions, increasing switching costs over time. It advocates for identity infrastructure that preserves deployment and integration flexibility while still reducing unnecessary operational burdens, rather than forcing a choice between fully self-hosted systems and exclusively SaaS-based services.

Homegrown authentication systems create business continuity risks alongside security concerns because outages can block customer access, disrupt transactions, increase support demand, and harm revenue and reputation. These systems often rely on a small number of engineers with undocumented institutional knowledge, while accumulated legacy rules, customer-specific flows, and acquired-product integrations make failures and recovery more difficult to manage. Effective resilience requires more than redundant infrastructure, including tested recovery plans, observability, reliable session and token controls, controlled configuration changes, and personnel able to respond under pressure. Security incidents can also become availability crises when organizations must revoke sessions, reset credentials, rotate keys, or disable affected flows without unintentionally disrupting customers. Leaders are encouraged to assess ownership, staffing, documentation, recovery testing, selective credential invalidation, and dependency awareness, while purpose-built identity platforms such as FusionAuth are presented as a way to reduce the operational burden of maintaining foundational identity capabilities without relinquishing organizational accountability.

Authentication and identity management are presented as core components of customer experience rather than merely technical entry points, influencing registration, login, recovery, multi-factor authentication, consent, and access decisions. While early limitations such as generic hosted login pages or awkward redirects may seem minor, they can become strategic constraints as companies expand across brands, enterprise requirements, regulated markets, devices, and channels. Reliance on inflexible identity providers can restrict control over customer journeys, data, deployment, security policies, and product evolution, even when a company owns its application and customer relationship. The passage argues that businesses should treat identity as a strategic customer platform, balancing standardized security with purposeful customization and ensuring the architecture can support adaptive security, portable permissions and preferences, and future AI-assisted interactions without increasing operational complexity through custom code, duplicate user stores, and manual exceptions.