Authorization consents

An authorization consent is a customer's explicit approval for an AI agent (or any OAuth2 client) to access their account through a protected resource. It's the OAuth2 consent pattern: the customer authenticates, sees who's asking and what they're asking for, and decides. Strivacity records the decision, enforces it in every token it issues, and lets the customer change their mind later.

When customers see an authorization consent screen

An authorization consent screen appears during the login flow when a client requests scopes from a protected resource with Consent required enabled, or claims through a client with Require consent for scopes enabled. Scope and claim consent always appear together on the same consent page.

The configuration is split between the two entities involved. The protected resource defines which scopes exist and their customer-facing descriptions. The client defines what a given agent or Application may do with them: which scopes it's allowed to request, which are required versus optional for the customer, and which are shown on the consent screen versus granted automatically. See Protected resources and AI agents.

AUthorization consent is requested at two moments:

• Initial authorization: the first time the client asks for access to the customer's account. The customer authenticates first, through the Application's normal journey and Adaptive Access policy, then sees the consent screen.
• Incremental authorization: later, when the agent attempts something outside its granted scopes. The resource challenges the agent, the agent re-requests authorization, and the customer is asked to approve just the additional access. This uses the Model Context Protocol (MCP) scope challenge mechanism; see Integrating an MCP server with Strivacity.

What the authorization consent screen shows

The authorization consent screen is a single page presenting everything the customer needs to decide:

• Which client is requesting access, using the display name and logo from its client configuration.
• Which account the client wants to act on.
• Which protected resource the access applies to, using the resource's display name and logo.
• The requested scopes, each described by the display name you configured on the protected resource. Required consents are fixed; optional ones the customer can uncheck.
• Data shared with the client (claims), when claim consent applies.
• A choice: continue, or cancel the login.

For dynamic clients, the display name and logo come from the agent itself rather than from a brand admin, so the consent screen marks them as unverified. The protected resource's display name and scope descriptions, which you did configure, are the vetted anchors of the screen. See Dynamic clients

You can add your own text to the consent screen around the consent list. Combined with automatically granted consents, this lets you describe the access entirely in your own words when the built-in list isn't the right presentation.

The screen uses the branding policy of the Application, so it matches the rest of the customer's login experience.

Carefully consider what information is needed for the customer-facing scope names and descriptions. The customer is mid-task and won't research what a scope means; "One-time approval to transfer points" (for example) provides a clear answer that stands alone.

How customers manage their consents

Customers review and revoke agent access in the My Account portal:

1. Log in to the My Account portal.
2. Go to Privacy & Data.
3. Under the consent section, each authorized agent appears with its logo, name, and the scopes it holds, described in plain language.
4. To revoke an agent's access entirely, select Delete next to the agent.

Dynamic clients appear here with the same unverified marker on their name. For agents using Client ID Metadata Documents, revoking the consent here is the customer's primary control: no client record exists for an admin to disable.

How admins manage a customer's consents

Brand admins can review and revoke a customer's authorization consents from the customer's account:

1. Log in to the Admin Console, and go to Account management in the left-hand menu.
2. Find and open the customer's account.
3. Select the Authorization consents tab.

The tab lists each consent with the client (an agent or an Application), the resource, the scopes it covers, and which scopes the customer accepted. To revoke one, open the row's action menu and select Revoke consent.

Dynamic clients carry the unverified marker on their name, and for agents using Client ID Metadata Documents the client identifier shown is the agent's metadata URL.

The neighboring Consents tab holds the customer's privacy consents from the consent management feature; the two are separate records.

Auditing consents and agent activity

Account events record agent activity with both parties identified: the Subject column shows the account the event relates to, and the Actor column shows the agent's client when an agent was involved. Events the customer performed themselves show the account in both columns. The event detail view carries the same subject and actor fields.

Authorization consent grants are captured inside the login flow's account event rather than as separate events. When consent is part of a login, the flow timeline includes an AuthorizationConsent entry with the step's outcome.

Expanding the entry reveals the full exchange. The response that rendered the consent screen carries everything the customer was shown: the client's display name and logo, the resource, and each scope with its display name and whether it was optional. The request that follows carries the customer's decision. Together they reconstruct exactly what the customer saw and allowed, even if the consent configuration has changed since.

Where to go next

• Protected resources: where scope descriptions are defined.
• AI agents: the client-side consent settings.
• Account events: the full account events reference.