SecureAuth Agent Authority
Let Claude and other AI agents manage your agents and policies, within the roles of the person they belong to
Other resources connect your agents to outside apps through the MCP gateway. The SecureAuth Agent Authority MCP Server connects an agent such as Claude to Agent Authority itself, so it can list your agents and policies and, for an admin, rewrite policies and change role assignments. Each call runs with the roles of the person the agent belongs to, and your policy rules decide which of these tools each agent gets.
Setup
- In the Agent Authority console, go to Tools & Services and click Add Resource.
- Select SecureAuth Agent Authority from the catalog.
- Click Install SecureAuth Agent Authority.
You have nothing else to configure. You don't create an app, and nobody signs in to connect an account.
Verify the connection
Ask your agent to run a request:
List my agentsIf your agents come back, the connection is working.
Who the tools act as
Each call runs as the person the calling agent belongs to. The gateway already knows that person from the agent's own credential, so nobody connects a second account. An agent owned by your organization, not a person, gets no access to these tools.
Available tools
Every SecureAuth tool carries one of the built-in tags read-only, write, or destructive.
Each tool is one management API operation and takes its name, for example policies_list.
Your agents see it with a secureauth_ prefix, for example secureauth_policies_list.
Each person gets only the tools their roles allow.
The viewer role gets read tools.
The admin role also gets write tools such as policies_create.
Your policies, response filters, and rate limits apply to these tools.
The audit log records each change.
Agents acting for a person with the admin role can change Agent Authority itself
With write tools, the agent can rewrite its own policies (policies_update),
create API keys (api_keys_create), or change who holds which role
(user_roles_replace). Deny the write tools it doesn't need, as in Policy
examples. Agents reach these tools only through the
gateway, so your policies apply to every call. The management API
rejects the agent's own credential. An API key the agent creates with
api_keys_create still works there, outside your policies.
Policy examples
Rules match tool names without the secureauth_ prefix.
New deny rules go to the top of the list, ahead of the seeded Allow all rule.
Add restrictions as deny rules.
See Rule order.
- Stop agents from changing policies, API keys, and role assignments.
Deny
policies_create,policies_update,policies_remove,api_keys_create,api_keys_rotate, anduser_roles_replaceon the SecureAuth Agent Authority resource. - Block the common write tools.
Deny
*_create,*_update,*_remove,*_delete,*_revoke,*_rotate, and*_replaceon the SecureAuth Agent Authority resource. A few write tools use other names, such astag_assignments_set. Check the management API for the ones you need to block. - Block destructive tools.
Add a deny rule with the built-in
destructivetag (Tools pill) for this resource (MCP pill).
Next steps
- Create a policy. Start from the patterns in Policy examples above.
- Roles. See what each role lets a person do. Their agent gets the same access.
- Audit log. Review the changes your agents make.