Agentic AI
Let your customers authorize AI agents to act on their accounts.
Your customers are starting to send AI agents to do their errands: booking travel, moving loyalty points, and checking balances. Strivacity's Agentic AI capabilities let you open your Model Context Protocol (MCP) servers and APIs to those agents without giving up control. The agent gets standards-based OAuth2 access, and your customer explicitly consents to what the agent can do. You keep a full audit trail of both.
This page orients you to the moving parts and walks through a first setup at a high level.
Strivacity's Agentic AI support focuses on two situations:
- External agents reaching your public MCP servers and APIs: agents your customers choose and operate, such as a personal assistant built into their browser or chat tool.
- Customer-facing agents you own: agents your brand (or a close partner) operates for your customers, such as a booking agent embedded in your product.
In both cases, Strivacity is the identity provider for the customer's account and the authorization server for the protected resource (the MCP server or API) the agent wants to reach.
The building blocks
- AI agent: an OAuth2/OIDC client with the AI agent client subtype. The agent authenticates with its client ID, and Strivacity treats that client ID as the agent's identity. You can register agents manually, or let external agents register themselves. See Dynamic clients.
- Protected resource: the MCP server or API the agent wants to call, registered in Strivacity with a resource URL, a display name and logo for consent screens, and the scopes it supports, each with a plain-language description.
- Authorization consent: the customer's explicit approval, captured during login, of exactly which scopes the agent may use against the resource. Customers can review and revoke these consents in the My Account portal.
How an authorization works
- The agent calls your MCP server without a token and gets back an
HTTP 401pointing at your Strivacity instance as the authorization server. - The agent starts an OAuth2 authorization code flow with PKCE, naming the MCP server in the
resourceparameter (RFC 8707). - Strivacity authenticates your customer using the login journey and Adaptive Access policy you've configured for the Application.
- Strivacity shows a consent screen: which agent is asking, which account it wants to act on, and the requested scopes described in plain language. The customer can uncheck any scopes you've marked optional, then continue or cancel.
- Strivacity issues an access token whose audience is locked to that specific resource URL. The agent can't reuse it against a different resource.
- If the agent later needs a scope it wasn't granted, the MCP server challenges it (
HTTP 403withinsufficient_scope), and the agent sends the customer back through an incremental consent step.
Every event in this sequence lands in account events with the customer as the subject and the agent as the actor, so you can always tell which actions involved an agent.
Set it up
Before you begin, you'll need an Application with a configured login journey, since agents authorize against an existing Application's policies.
-
Register the MCP server or API as a protected resource, including its scopes and their customer-facing descriptions. See Protected resources.
-
Choose one of the following approaches:
-
Register the agent as an AI agent client: Assign it the protected resources it may request access to. See AI agents.
-
Enable dynamic client support: For a public MCP server whose customers bring their own agents, enable dynamic client support and agents register themselves against a template. See Dynamic clients.
-
- Decide where consent is required and review what the consent screen will show your customers. See Authorization consents.
- Hand the developer of the agent or MCP server the integration details: discovery endpoints, the
resourceparameter, and token validation rules. See Integrating an MCP server with Strivacity.
To verify the setup, run the agent through its first authorization against a test account, then check three places: the consent screen shows the agent and scope descriptions you configured, the My Account portal lists the agent under the customer's authorization consents, and the account events list shows the flow with the agent as the actor.
Where to find it in the Admin Console
Agentic AI has its own item in the left-hand menu, between Applications and Organizations, with three pages:
- AI agents: every client with the AI agent subtype, across all Applications, with an option to create new ones.
- MCP servers: every protected resource of the MCP server type.
- Client registration: the switch for Client ID Metadata Documents and the default dynamic client template it draws configuration from.
The Dashboard also has an Agentic AI tab with widgets covering agent adoption and agents added and removed over time.
Standards support
| Capability | Standard |
|---|---|
| Authorization and token issuance | OAuth2 authorization code flow with PKCE |
| Authorization server discovery | OIDC Discovery (MCP clients fall back to it per the specification) |
| Audience restriction | Resource Indicators for OAuth 2.0 (RFC 8707) |
| Incremental authorization | MCP scope challenge handling (insufficient_scope) |
| Agent registration | Manual registration and Client ID Metadata Documents (CIMD). See Dynamic clients. |
Where to go next
Updated 5 days ago

