Identity and sign-in

When an agent acts for a person, the audit log names that person, and policy conditions can match their groups. Your workspace comes with its own identity pool, so you can sign in as the tenant administrator and finish setup before you connect a directory.

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. Their group memberships can drive policy conditions once the workspace reads groups from the directory instead of the pool, as described in Where the gateway reads groups. 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.

Two settings in SecureAuth Connect decide what that response carries:

• The identity provider connection – maps the group claim your directory sends into the authentication context. See Identity providers.
• The workspace groups claim – in Identity → Token Claims, on the ID Tokens tab. By default its Type is User, so it reads groups from the workspace identity pool and ignores your directory. To use your directory's groups, click the groups row and set Type to AuthN Context and Source to List of groups that user belongs to. Edit this claim rather than adding a second one, and leave User info only turned on, because that switch is what puts the claim in the userinfo response.

The claim reads from one source at a time, so groups come from the identity pool or from your directory, never both. After you switch it to your directory, groups you created by hand in the pool no longer reach the gateway.

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.