MCP agents can manage Authdog resources

An MCP agent that can only read status still needs a human for every user edit and every client change. Authdog MCP agents can now manage users, projects, environments, and OIDC clients end to end, so provisioning and cleanup can stay inside the same authenticated tool session.

This is the longer note behind the July 25 changelog entry.

How it works

The management tool set covers the resources operators already touch in the console:

• Users: search, get, update, activate, and delete tools for environment users
• Tenants, projects, environments, and OIDC clients: create, update, and delete
• get_public_key: fetch the publishable pk_ value SDKs need to resolve an environment
• whoami: richer caller detail so the agent can see which account and scope it is acting as
• OIDC redirect validation: checks used by agent workflows before a client is treated as ready

These are control-plane tools. They change Authdog resources. They are not the same as MCP runtime telemetry (MCP_TOOL_INVOKED, MCP_TOOL_DENIED) or a registered agent identity in the Agents module.

get_public_key returns the environment's publishable identifier, not a signing private key. That pk_ value is what SDKs embed to find the right environment and validate sessions.

Set it up

1. Connect an Authdog MCP agent with credentials that can already administer the tenant and environment you intend to change.
2. Call whoami first and confirm the account, tenant, and environment match the target.
3. Use user search / get before update, activate, or delete.
4. Create or update tenants, projects, environments, and OIDC clients through the matching tools. Validate redirect URIs before you treat a client as production-ready.
5. Call get_public_key when an SDK or hosted flow needs the environment's pk_ value.

Keep tool access on verified agent identities and narrow scopes. Start from MCP security and the Agents registry.

Trust boundaries

A management tool call is an authenticated admin action. Search and get are not harmless if the agent is over-scoped; they expose directory data. Delete and activate are irreversible from the agent's point of view — treat them like console operator clicks.

whoami describes the caller. It is not a permission grant. Redirect validation catches misconfigured OIDC clients; it does not prove the application behind the URI is safe.

Do not put a human session cookie into an unattended MCP runtime. Register the workload as an agent, pin allowed tools, and revoke the identity when the job is done. Management CRUD and runtime tool-call audit stay different categories.

Try it

Connect an agent, run whoami, then fetch get_public_key for a non-production environment before changing users or clients. Background is on MCP security and MCP servers. The original release note is in the changelog.