As we begin connecting more applications to access our account data and act on our behalf, it’s important to consider what potential security risks may come along. As people and companies embrace cloud tools and AI-driven agents, every new integration becomes another potential vector for data exposure.

Although consent management has been around for some time, it rarely gets real attention until there’s a problem. All too often, access is granted without much scrutiny, and third-party integrations are built and connected without adequate guardrails. At Stytch, we set out to make consent management easy to adopt and automatic for every Connected App, handling the entire process from the moment you connect to a third-party service.

The new consent surface

In the context of OAuth, consent refers to the explicit permission a user gives to a third-party application to access specific data or perform actions on their behalf. This consent is typically granted via an OAuth flow, where the user is shown what scopes (or types of access) the third party is requesting.

What makes this process more complex is that adding an OAuth connection extends your application's trust parameters to include third parties. Multiply that across dozens of tools, and you've built a surface area of consent that's difficult to keep track of, let alone keep secure. OAuth tokens are persistent, can be over-permissive, and are rarely audited. Most systems don't make it easy to see who has access to what, or for how long.

Why revocation matters

For most scenarios, consent access is granted once and forgotten about. But part of the risk is that as business needs and technology standards change, access permissions don’t. With core infrastructure changes happening though the years, like employees leaving over time or dev tools becoming obsolete, auditing existing app permissions is often deprioritized. And the longer a token remains active, the greater the risk it poses.

There are quite a few well-known breaches that trace back to stale credentials. In 2022, GitHub revoked dozens of OAuth tokens after attackers exploited them to access private repos. Not because of an active user decision, but because the tokens were still valid. Similarly, in 2025 Microsoft noticed evidence of OAuth token replay attacks being used to gain access to unauthorized Microsoft 365 accounts, where stolen OAuth tokens from previously authorized applications were reused by hackers to bypass security.

These examples show how persistent and overly broad access, when left unchecked, can lead to significant security concerns, and highlights why revocation needs to be fast, scoped and auditable. Whether through an admin dashboard or an API call, revoking access should be just as easy as granting it.

The IT admin lens

The solution to this is consent management, which lets teams define, grant, and maintain permissions for third-party applications to access user data or act on a user’s behalf via OAuth. For example, it can let you decide whether a scheduling tool can read your calendar or an AI agent can send an email on your behalf.

With OAuth, this consent isn't just a one-time approval, but instead a delegated trust relationship that persists until it’s explicitly revoked. That’s why it’s so critical for administrators to have clear, actionable ways to manage it. To grant this, we believe admins should be able to:

• Enforce organization-wide policies for what apps can be connected
• Require specific scopes or expiration for tokens
• View audit trails of third-party authorizations

The best time to harden your access controls is before someone connects a risky app, not after.

AI agents on your behalf

Today, users authenticate into apps. Tomorrow, they’ll delegate to AI agents that will authenticate and interact with apps on their behalf.

Imagine an AI-powered scheduling assistant that books meetings using your calendar. It needs your credentials to do that. Now imagine it misinterprets a prompt or gets hijacked by a cleverly crafted message. Suddenly, your credentials aren’t just in the hands of an app—they’re in the hands of an autonomous, unpredictable actor.

Today, we already see vectors like AI hallucinations and prompt injection attacks that show how easy it is for agents to misbehave. We need to prepare for a world where:

• Agents request access to sensitive APIs
• Delegated access needs to be highly scoped and temporary
• Users (and admins) can see and control what agents are doing

To prepare for this future, new standards like Model Context Protocol (MCP) aim to make agent-based access safer and easier to scale by formalizing how models interact with user data and third-party services. But these standards still require proper tooling to control consent.

Stytch’s approach: organization-wide visibility and control

We built Connected Apps to help teams visualize and manage their third-party integrations. By using an auth provider instead of handing over direct login credentials, we can give every organization visibility into the apps authorized by their members, including what scopes are granted and where access needs to be reined in. And to give more granular control, we have Organization App Policies, where organization admins can:

• View all third-party apps authorized by users in their tenant
• See granted scopes and token details in one place
• Define a pre-approved allowlist to control what apps are permitted
• Revoke access programmatically or from the dashboard

This way admins can both prepare ahead of time within the dashboard by setting up an allowlist of applications, while also keeping infrastructure prepared to manage and revoke access on demand programmatically.

Here’s what an example flow may look like using this feature via the Stytch API, where we want to investigate access of connected apps for individual members.

• List all connected apps associated with a member, where it will return a connected_app_id for each entry.

curl --request GET \
  --url https://test.stytch.com/v1/b2b/organizations/ORGANIZATION_ID/members/MEMBER_ID/connected_apps \
  -u 'PROJECT_ID:SECRET' \
  -H 'Content-Type: application/json'

• Once the connected app(s) whose access needs to be revoked is identified, revoke the access for that member.

curl --request POST \
  --url https://test.stytch.com/v1/b2b/organizations/ORGANIZATION_ID/members/MEMBER_ID/connected_apps/{connected_app_id}/revoke \
  -u 'PROJECT_ID:SECRET' \
  -H 'Content-Type: application/json'

Looking ahead

The next decade will bring more delegation, more automation, and more connected apps, especially as more third party applications, such as AI agents, begin gaining access to accounts. Security infrastructure must keep up. What you should enforce to maintain security is:

• A clear map of who (or what) has access
• Tools to enforce policy before a connection is made
• Revocation paths that are fast and intuitive

We built consent infrastructure for the future—so you don’t have to.

Ready to secure your app ecosystem?

Explore Stytch's docs or reach out to our team to see how Connected Apps and Organization App Policies can help you build trust from the first integration.