Identity and sign-in

Every action the gateway records is attributed: to the agent that made the call, and to the user it was acting for. That means Agent Authority needs to know who your users are. It keeps no directory of its own — it's the Agentic AI workspace inside SecureAuth Connect, and it uses Connect's identity layer.

There's nothing to set up before you start. Your workspace comes with its own identity pool acting as its identity provider, so you sign in as the tenant administrator from day one, and anyone else you add to the pool can sign in straight away. That's enough to complete every step in this guide.

Where identity comes from

Identity lives in SecureAuth Connect, and you administer it in the Agentic AI workspace under Identity & SSO. Two ways to get people in, 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 details, see the SecureAuth Connect documentation.

What Agent Authority does with it

• 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.

Verify and troubleshoot

Confirm people can actually get 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, the issuer most likely isn't returning a groups claim. The gateway reads groups only from the issuer's OIDC userinfo endpoint, so a groups claim placed in the ID or access token but absent from the userinfo response still leaves user.groups empty. Check the userinfo response specifically; the claim is configured on the IdP connection in Connect, and it's the most common gap that affects policy.

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

Next steps

• 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.