Question 1

What is Agent Authority?

Accepted Answer

Agent Authority is SecureAuth's identity and access layer for autonomous AI agents. It gives each agent a verified identity, authorizes it at the level of individual actions rather than broad sessions, and keeps a record of every tool call an agent makes through the gateway — so you can see what agents are doing and apply controls before an incident forces your hand.

Question 2

What are the main capabilities?

Accepted Answer

Per-instance agent identity — every agent instance gets its own verified identity, carried on every call it makes and linked to the person who authorized it, so an agent stays distinguishable from the user it acts for. Activity visibility — who did what, which tool they used, and when, for every call made through the gateway. It's delegation-aware, so it follows authority as it passes from one service to the next. Policy enforcement — fine-grained, request-level control over what each agent instance can reach. The engine is deny-by-default: a call is blocked until a policy allows it.

Question 3

How is this different from role-based access control (RBAC)?

Accepted Answer

It isn't your existing roles relocated into a new system. The agent path is fundamentally different from the human path: the same data reached through a different interface (MCP rather than a browser), and an agent can take thousands of actions from a single instruction, at machine speed. That's why authorization and an audit record are applied at each action, not once per session.

Question 4

Do I need to bring my own identity provider?

Accepted Answer

No. Your workspace comes with its own identity pool and you can add users to it directly, so nothing has to be federated before you start. If you already run a standards-compliant enterprise directory, you can federate it instead — SAML 2.0, OIDC, or OAuth 2.0 — and users and groups then come from there.

Question 5

How do my users connect their agents?

Accepted Answer

You connect from Agent Registry: pick the agent and click Connect. Your users do the same from their self-service portal's Quickstart: pick the agent and follow the on-screen modal. Both open the same dialog with that agent's setup instructions — for most agents the steps are identical. Claude is the exception: admins see the steps for adding the org-wide custom connector, while users see the steps for enabling the connector you added and signing in. Share the portal URL with your users so they can self-onboard.

Question 6

Can end users add their own connectors?

Accepted Answer

No. Only administrators add new connectors. As an end user, you sign in and authorize your own access to a connector an administrator has already set up.

Question 7

Why does the gateway block everything by default?

Accepted Answer

SecureAuth Agent Authority is deny-by-default: a tool call is blocked until a policy rule allows it. New organizations start with a default Allow all rule so agents work out of the box. Once you remove or tighten that rule, you need at least one active Allow rule covering the agent, resource, and tools before calls succeed.

Question 8

How do I quickly stop an agent or cut off its access?

Accepted Answer

You have a few immediate options. Cut off a single client from an agent instance's detail page — open it from the agent's instance list in Agent Registry, or from Agent Instances in the sidebar. Revoke access cuts the instance off where your deployment supports it; Delete always removes the instance. Disable a policy rule, or add a Deny rule, to block tools going forward. Disconnect a user's connection to revoke the stored credentials for a service.

Question 9

Does the gateway store my prompts and responses?

Accepted Answer

No. The audit log records only structured metadata about each gateway call: the timestamp, the user and agent, the action, the resource and tool, and the policy decision. It does not store the raw prompt or response text of your conversation with the LLM.

Question 10

Does the gateway inspect or change tool responses?

Accepted Answer

Only if you tell it to. Data Protection response filters rewrite sensitive text — SSNs, API keys, email addresses — out of a tool's response before the agent sees it. It's a separate layer from Access Policies: a policy decides whether a call runs at all, a filter decides what's in the response once it does. Only filters you make Active run, and the audit record of a redacted call stores the rule names that matched and how many spans each replaced — never the matched text.

Question 11

Is licensing per agent or per user?

Accepted Answer

Per AI-enabled user, not per agent — one person running 25 agents is a single license, not 26. Your SecureAuth account team confirms current licensing terms.

Question 12

Does connecting Microsoft 365 require a Copilot license?

Accepted Answer

Yes. The Microsoft 365 integration is built on Microsoft's Agent Tools API, which only operates in tenants with active Copilot licensing, so every user who reaches Microsoft 365 tools through the gateway needs a Microsoft 365 Copilot license assigned. This applies to both credential modes: bringing your own OAuth app does not sidestep it.

Question 13

How do I connect my AI agent?

Accepted Answer

Go to your self-service portal and open Quickstart to connect your agent, or follow the guide for your agent in Agent integrations. For Claude, your administrator adds the connector for the whole organization, so you find it in Claude's Connectors settings and sign in.

Question 14

Do I need to connect my accounts ahead of time?

Accepted Answer

No. The gateway acts using your own credentials, so you link each service once, but not in advance. The first time your agent uses a tool that needs a service (for example, Slack), the gateway returns a link to connect that account. Complete the sign-in once and future calls reuse it.

Question 15

Why doesn't a tool I authorized show up?

Accepted Answer

Claude caches the tool list per connector. In Claude, go to Settings → Connectors, find the SecureAuth AI Gateway connector, click the vertical three-dot menu (⋮), and select Refresh tools list. The newly authorized tool then appears.

Question 16

Will my existing Claude recurring tasks keep working after I switch to the gateway?

Accepted Answer

Mostly. They pause once while you approve the new connector's tools, then resume on their schedule. Make sure a policy allows the tools those tasks use, and re-check the connection if a task seems stuck.

Question 17

Does the SecureAuth AI Gateway tool list refresh automatically in Claude?

Accepted Answer

The gateway updates its own tool list right away when a connector changes, so the gateway is never the bottleneck. Claude, though, caches its own copy of the connector's tools and doesn't re-fetch automatically, so a newly authorized tool may not appear until you refresh it manually in Claude. See the answer to 'Why doesn't a tool I authorized show up?' for the exact refresh steps.

FAQ

For administrators

Product and concepts

Setup and onboarding

Security and access

Licensing

For end users

Getting connected

Using your tools

Still have questions?

On this page