Where your users and groups come from

Your workspace can authenticate people before you configure anything, because it comes with its own identity pool acting as its identity provider. You sign in as the tenant administrator from day one, which is enough to complete every step in this guide.

Agent Authority keeps no directory of its own: it is the Agentic AI workspace inside SecureAuth Connect, and it uses Connect's identity layer.

Where identity comes fromCopy Anchor Link

Identity lives in SecureAuth Connect, and you administer it in the Agentic AI workspace under Identity. Two ways to add people, and they're not exclusive:

• The workspace identity pool (the default) – add users directly to the pool and they can sign in immediately. Nothing to federate, no external system involved.
• Your existing directory – if you already run one, any standards-based OIDC or SAML provider can be federated so people sign in with the account they use everywhere else, and their group memberships come along for policy conditions. This is normally configured once at tenant onboarding, not per agent or per resource.

Use Try Sign-in on the Identity Providers page to confirm either path end to end. For setup steps, including provider-specific guides for Okta, Microsoft Entra ID, and others, see Identity providers in the SecureAuth Connect documentation.

What Agent Authority does with itCopy Anchor Link

• Per-instance identity – every agent instance has its own identity and carries it on every call. Instances are registered to the person who authorized them, so an entry in the audit log names the agent that acted and the user it acted for, rather than blurring the two together.
• Groups drive policy – group claims arrive as user.groups, which policy conditions can match, for example allowing a tool only when "platform" in user.groups. Groups scope analytics and Agent Trail filters too, which is how you separate one team's activity from another's.
• Per-user credentials – after sign-in, each user links their own accounts to downstream services, and for catalog resources the gateway calls upstream with that user's own connection rather than a shared account. Custom resources configured with an API key or client credentials use the shared credential an admin set instead. See Connections.

Where the gateway reads groupsCopy Anchor Link

The gateway takes groups only from the identity provider's OIDC userinfo response, and only from a claim named groups. A claim placed in the ID or access token, but absent from the userinfo response, leaves user.groups empty. An identity provider that is sending groups correctly can still produce an empty user.groups, so read the userinfo response itself rather than trusting the configuration.

If the claim is missing, it is configured on the identity provider connection in SecureAuth Connect. See Identity providers.

Verify and troubleshootCopy Anchor Link

Confirm people can sign in:

• Sign-in works – a user in the pool, or one coming from a federated directory, can sign in. Use Try Sign-in on the Identity Providers page to test the flow without a full login.
• Groups arrive – if policy conditions on user.groups never match, read the userinfo response before you change anything at your identity provider. See Where the gateway reads groups.
• A group change has reached the user – if a rule scoped to a group someone just joined does not match, check what your identity provider returns for them on /userinfo. See When a group change takes effect.

For provider-specific sign-in problems, see the SecureAuth Connect documentation. For gateway-side issues, see Troubleshooting.

Next stepsCopy Anchor Link

People can now sign in, and you know where their group claims come from and what the gateway does with them. The next task is to connect the MCP servers those users will call.

• Add resources – connect the MCP servers your now-authenticated users will call.
• Policies – write the rules that decide who can do what, including conditions on user.groups.