Console configuration

Everything AIGW does for a merchant integration is configured in the AIGW Console. This guide sets up the objects in the order you need them, then explains the settings you will come back to: Resource fields, signing keys, Agent policy and end users.

How the Console is organized

Who owns the Account depends on who operates the integration. A merchant running its own MCP or UCP service normally owns it. A third-party provider normally owns it and creates merchant Resources in Projects it operates.

Create an account

On first sign-in the Console shows the Account selector. Choose Create Account, enter a name (the merchant or MCP provider organization works well), and create it. You become the Owner.

The Account home summarizes the last 30 days: agent sessions, discoveries, possession checks and consents. Use Team to invite members as Admin, Developer or Viewer with a single-use invite link, and Settings, API Management for account API keys. Treat API keys like any server-side secret.

Create a project

Go to Project Management, New Project. The name is the only input, and you can rename it later with the pencil icon. Name it after a real boundary, such as Acme MCP - Prod.

Keep the service and its users in one Project

Credential redemption only works when the user's AIGW token and the Proxy token come from the same Project. A Proxy client from Project A cannot redeem a user token from Project B.

Enable identity providers

Open IdP Management at the Account level and toggle on the providers your users should sign in with. Built-in providers need no configuration. Only providers enabled here can be selected on a Resource.

Provider	Type shown in the Console
Apple	OIDC, Sign in with Apple
Facebook	OIDC, Facebook Login
Google	OIDC, consumer and Workspace
LoginID	Passkeys, passwordless
Microsoft	OIDC, consumer and work accounts
Phone verification	Phone possession and identity verification

Planned Connect provider for a custom identity provider is not available in this release. Instead, use the built-in providers above.

Register a resource

Open the Project, then Resources, Register resource. Pick the kind first, because it changes what AIGW does:

Kind	Use it when	AIGW's role
Token exchange	An agent acts through your MCP or UCP service and needs a merchant API that has its own authorization server.	Authorizes the user and agent, then obtains and manages a merchant access token from your AS.
OAuth client	A web or mobile app needs ordinary human sign-in.	Acts as the app's identity provider and issues OAuth/OIDC client configuration.

The Resource is created when you click Continue on step 3 of the wizard, and a signing key is generated at the same time. Step 4 shows the Reference values to hand to the merchant IAM team and the agent developer. Field details are under Resource reference.

Create a Proxy client

Who: MCP or UCP operator

Open Proxy clients in the Project and choose Generate new client. AIGW shows a client ID and a client secret.

The secret is shown once

Save it straight into your server-side secret manager. If you lose it, generate a new client and revoke the old one. Never send the secret or the Proxy token to an agent or a browser.

Your service exchanges it for a Proxy token with the client credentials grant:

Get a Proxy tokenhttp

Copy code

POST https://core.api.aigw.eval.loginid.ai/oauth2/tokenAuthorization: Basic base64(<CLIENT_ID>:<CLIENT_SECRET>)Content-Type: application/x-www-form-urlencodedgrant_type=client_credentials

Supported The token returned is a bearer token valid for one hour (expires_in: 3599). A Project can hold several Proxy clients, so you can rotate without downtime: generate a new one, switch your service, then revoke the old one from the list.

Resource reference

A Resource detail page has three tabs: Configuration (editable settings, Reference values and a Danger zone), Signing keys and Sign-in & consent. Deleting a Resource is permanent; agents using it can no longer exchange tokens for it.

Token exchange fields

The wizard has four steps: Identity & endpoint, Authentication, Exchange & scopes, and Reference. Collect the merchant values from the merchant IAM owner first.

The Reference step groups outputs by audience. For whoever verifies subject tokens: the expected aud, the client_id AIGW presents, the client authentication method, the per-resource authorization server, and a Download oauth-protected-resource.json button. For the agent developer: the JWKS URI, the OIDC and OAuth AS metadata discovery endpoints, the per-resource authorization endpoint and the core token endpoint.

Setting up the merchant side of this Resource is covered in Configure your authorization server.

OAuth client fields

The Reference step shows the client secret once. Store it server-side immediately; it can't be retrieved again. It also lists the client ID, the per-resource authorization endpoint, both discovery endpoints and the authorization server base URL.

Signing keys

Each Resource has EC P-256 keys that sign ES256 assertions sent to the merchant AS. The tab shows the JWKS URL https://api.aigw.eval.loginid.ai/<RESOURCE_ID>/.well-known/jwks.json and every key with its kid.

Sign-in and consent

Per Resource, Sign-in & consent sets appearance (logo URL, color scheme, radius, accent and action colors), behavior (emailed one-time code fallback, scope descriptions on consent, verified agent on consent) and screen text for both screens, with a live preview. The preview can differ from the real flow, so test the actual sign-in too.

Agent policy

Agent policy decides the status an agent gets the first time it asks for one of a Project's Resources. It lives under Agents, Agent policy and has four pages: How it works, Domain rules, Approval rules and KYA issuers.

Agent statuses

Agent approval is separate from user consent. An approved agent still needs each user to consent to its scopes, and a blocked agent fails even with a well-formed OAuth request.

Evaluation order

The first time an agent asks for a Resource, AIGW applies the first rule that matches, in this order:

1. A person's decision wins. If someone approved, rejected or revoked the agent in the Console, no rule changes it.
2. Domain rules. Planned See Domain rules.
3. Proof rules. Each proof the agent presents maps to a rule, and the most open outcome wins.
4. The Unverified agents rule for an agent with no proof.

A Resource's own rules replace the Project's. A Resource without rules follows the Project, and a Project without rules uses the system default. Changing approval rules affects agents the first time they ask; agents already decided keep their status.

Approval rules

Each row is set to Reject, Hold (the agent goes to Pending) or Approve. Click Apply changes to save. Reset to system default removes the Project's rules, and Edit rules on a Resource gives it its own policy.

Agent verification and user verification

These are two separate checks, configured in different places.

• Agent verification proves which agent is asking. It uses the proofs above (platform-trusted, Web Bot Auth, reverse DNS, a KYA credential, or CIMD) and feeds Agent policy. A KYA credential is one of these agent proofs: a third-party issuer vouching for the agent.
• User verification (KYC) proves who the person is. It happens at sign-in through the identity providers enabled on the Resource. Phone verification, for example, checks phone possession and identity. Agent policy does not control it.

KYA issuers

KYA issuers is the list of Know Your Agent credential issuers whose credentials count for the KYA credential rule. Switch between the Project list and per-Resource lists at the top. For each issuer, turn acceptance on and set a minimum trust level:

If no issuer is accepted, agents are decided by the approval rules like any other agent. Planned Some issuers in the catalog show as Disabled and can't be enabled in this release. Instead, accept an enabled issuer, or rely on the other proofs and approval rules.

Domain rules

Planned Domain rules (approve, hold or reject agents from a domain and its subdomains) are not available in this release. Instead, set the Approval rules to Hold so new agents land in Pending, then approve or reject each agent by hand under Agents. A person's decision always wins over policy.

End users

End Users lists the people your agents have acted for, at the Account level and per Project (filterable by Resource).

What works in this release

Next steps

• Configure your authorization serverMake Keycloak or another OAuth server trust your new Resource.
• Protect an MCP or UCP serviceUse your Proxy client to redeem merchant tokens server-side.
• Discovery and registrationThe endpoints agents use to find and register with your Resource.