Discord is tightening how apps access message content, server member lists, and user presence data. Apps reaching 10,000 or more users must undergo review and renew approval annually, replacing the former threshold based on membership in 100 servers. Most users will notice no change, though apps that lose access may need to replace features such as text-command bots with slash commands.
## Updated Access Requirements
- The changes affect access to:
- Message content
- Server member lists
- User presence information, such as online or offline status
- Apps serving fewer than 10,000 users are generally unaffected.
- Apps reaching 10,000 or more users must complete Discord’s review process.
- Approved apps must reapply every year to demonstrate that their data access remains necessary.
## Why Discord Is Changing the Rules
- The previous review threshold was based on being installed in 100 or more servers.
- Server count did not accurately reflect how many people an app could reach, especially when installed in one large community.
- Annual reviews account for apps changing purpose over time.
- Discord aims to ensure apps only retain access to data that is necessary, actively used, and consistent with their stated purpose.
## Impact on Developers and Users
- Developers will receive notice and generally have 90 days to maintain access while applying or adapting their apps.
- Developers may resubmit applications at any time.
- Apps that lose access may continue working for features that do not depend on restricted data.
- Text-based commands that require reading message content may need to be redesigned as slash commands.
- Apps will not receive access to any new categories of data; the change concerns approval requirements and limitations.
Discord recommends that developers review the updated requirements and that users inspect app profiles before deciding which apps to allow in their servers.
ID-JAG extends enterprise SSO trust to API access between AI agents, applications, and services. It uses an enterprise IdP to centrally evaluate permissions and issue a signed JWT that can be exchanged for a resource-specific access token. This can reduce consent prompts, improve auditing, and limit token sprawl, but organizations should adopt it cautiously while the specification remains an Internet-Draft.
## The Authentication Challenge in the AI Era
- AI agents increasingly perform real work, including:
- Searching systems
- Querying databases
- Sending messages
- Creating tickets
- As the number of connected services grows, authentication and authorization become more complex.
- Poorly coordinated integrations can turn AI from a productivity tool into an operational bottleneck.
- ID-JAG is being discussed by the IETF OAuth Working Group as a potential solution.
## What ID-JAG Is
- ID-JAG, or Identity Assertion JWT Authorization Grant, extends the enterprise IdP’s SSO trust relationship to API access.
- The IdP centrally determines:
- Which application or agent may access an API
- Which user or identity it acts for
- Which scopes or permissions are allowed
- It combines:
- OAuth 2.0 Token Exchange (RFC 8693)
- JWT Profile for OAuth 2.0 Authorization Grants (RFC 7523)
- The IdP issues a cryptographically verifiable JWT as an “introduction” or authorization assertion.
- The target authorization server validates that assertion and issues the final access token.
## The ID-JAG Participants and Flow
The model involves four main parties:
- **Requesting Agent:** An AI agent or application calling another service’s API
- **Enterprise IdP:** Provides SSO and enforces centralized organizational policies
- **Authorization Server:** Issues tokens for the target application
- **Resource Server:** Hosts the API being accessed
The basic five-step flow is:
1. The user signs in to the requesting agent, which obtains an ID token from the IdP.
2. The agent presents the ID token to the IdP and requests an ID-JAG through token exchange.
3. The IdP evaluates organizational policy and issues the ID-JAG if access is allowed.
4. The agent presents the ID-JAG to the target authorization server and receives an access token.
5. The agent uses the access token to call the resource server.
The key architectural shift is that authorization decisions move from isolated agent-to-service relationships toward a centrally governed relationship between the enterprise IdP and target authorization servers.
## Benefits for User Experience and Auditing
- Centralized IdP policies can reduce repeated consent screens.
- This is especially useful when AI agents connect to many tools and services.
- ID-JAG claims can record important context, such as:
- The user whose authority is being delegated (`sub`)
- The requesting agent (`client_id`)
- The target authorization server (`aud`)
- Approved scopes (`scp`)
- Issuer, issue time, expiration, and unique token ID
- Centralized issuance logs provide a clearer view of service-to-service relationships.
- Security teams can more easily determine which agent accessed which service, on whose behalf, and with what permissions.
- The same records can support incident investigation, compliance audits, and accountability.
## Centralized Control and Reduced Token Sprawl
- The IdP can help detect and control unauthorized “shadow AI” integrations.
- It can evaluate every token exchange using consistent organizational policies.
- Requested scopes can be narrowed or overridden according to enterprise security requirements.
- Blocking future access can be handled centrally instead of by changing policies across every endpoint.
- ID-JAG may reduce token sprawl by avoiding additional long-lived refresh tokens.
- The draft recommends that resource authorization servers generally not issue refresh tokens when an ID-JAG is exchanged.
- Agents can instead submit a new ID-JAG to obtain another access token, replacing scattered API keys, service credentials, and refresh tokens with dynamic, policy-based trust.
## Adoption Requirements and Risks
- ID-JAG is still an IETF Internet-Draft, not a finalized RFC.
- Its behavior may change, so systems should avoid tightly coupling their core architecture to the current draft.
- Before implementation, organizations need to verify that:
- The requesting agent is registered as an OAuth client with both the enterprise IdP and the target authorization server.
- Explicit trust relationships exist between the IdP and agent, and between the IdP and authorization server.
- The IdP has pre-authorized the agent to act on users’ behalf for the relevant services and scopes.
- Deployment also requires coordinated support from agents, enterprise IdPs, authorization servers, and resource servers.
Organizations should treat ID-JAG as a promising architectural direction for governing AI-agent access, while isolating its implementation behind adaptable interfaces until the standard stabilizes. Pilot deployments should focus on centralized policy enforcement, detailed audit logging, strict scope control, and minimizing long-lived credentials.
