How it works

How SecureAuth Agent Authority authenticates, authorizes, and audits every MCP tool call between your AI agents and your services.

Instead of wiring each AI agent to every service directly, your agents connect to one gateway endpoint that fronts all of them. Every tool call is authenticated and decided against your policies before it ever reaches an upstream service — and every call, allowed or denied, is recorded.

AI agents connect to Agent Authority, which authenticates and authorizes every tool call before forwarding it to upstream services, and records every call — allowed or denied — in the audit logAI agentsClaudeCursorCopilotCodexYour servicesSlackGitHubJiraMicrosoft 365Agent AuthorityAuthenticateAuthorize (policies)Audittool callforwardresponse · audited

The gateway is both server and client

The Model Context Protocol (MCP) is an open standard that lets AI agents call external tools. It uses a client–server model: the agent is the MCP client, and each service (Slack, Jira, and others) runs an MCP server that exposes tools.

SecureAuth Agent Authority sits in the middle. It is an MCP server to your agents and an MCP client to your upstream services. Your agents point at a single endpoint that aggregates the tools from every configured resource, so you can add or remove resources without reconfiguring a single agent.

Request flow

Request flow for one tool call: the agent calls the gateway, which authenticates the agent and user, evaluates policy rules (a denial is blocked and audited here), forwards allowed calls upstream with the user's connection credentials or the org's shared credential, applies data protection filters to the response, returns it to the agent, and writes an audit recordAgentGatewayPolicy engineUpstream MCP1 tool call2 authenticate agent + user3 evaluate policy rulesif denied: blocked + audited, request ends4 forward with user or org credentials5 response6 data protection filters7 response to agent8 audit record written
  1. Your AI agent sends an MCP tool call to the gateway's single endpoint.
  2. The gateway authenticates the agent and resolves the user it is acting for.
  3. Policy rules are evaluated top to bottom, and the first match decides. A deny stops here — the call is blocked, and it is still recorded. A call that matches no rule at all is denied too.
  4. If the call is allowed, the gateway forwards it to the upstream MCP server. Resources that require a per-user connection — every catalog resource, and custom servers that use OAuth sign-in — carry that user's own credentials. Custom servers configured with an API key or a client-credentials app use the shared credential an admin configured instead.
  5. The upstream MCP server returns its response to the gateway.
  6. Data protection filters run over that response, masking anything a matching filter covers. If a matching filter is broken, the gateway blocks the response rather than passing it through unfiltered.
  7. The response is returned to the agent.
  8. The full interaction — agent, user, decision, and result — is written to the Audit log.

Key benefits

  • Single endpoint — Agents need one MCP configuration, regardless of how many services they reach. When an agent enforces a per-connection tool limit, point it at a single MCP's endpoint instead to keep its tool list small.
  • Centralized control — Admins manage every resource and policy from one dashboard.
  • Per-user credentials — For resources that require a connection, each user authenticates with their own account, so upstream calls carry that user's own identity rather than one shared account.
  • Full audit trail — Every tool call is logged with the user, agent, decision, and request details in the Audit log.

Next steps

  • Get started — stand up the gateway and make your first call.
  • Policies — write the rules that allow or deny each action.
  • Connect an agent — point Claude, Cursor, Copilot, or Codex at the gateway.

On this page