04AUTHORIZATION IN DETAIL
The rule evaluates the call at the moment it happens.
- CEL conditions on the call
- Trusted attributes from your context sources
- If the source does not answer, the call is blocked
Agents do only what you allow
- Before the MCP server, we evaluate each tool call as it happens, with its arguments and trusted attributes from your APIs
- The agent never sees the server key
- Every denial carries the reason and the rule that stopped the call
- Your agent and your IdP stay as they are
Agents do only what you allow
- Before the MCP server, we evaluate each tool call as it happens, with its arguments and trusted attributes from your APIs
- The agent never sees the server key
- Every denial carries the reason and the rule that stopped the call
- Your agent and your IdP stay as they are
03TOOL ACCESS
Permission is granted tool by tool, never for the whole server.
- A new tool starts blocked
- Resources granted one by one, beyond the tool
02MCP SERVER ACCESS
Each agent sees only the MCP servers granted to it.
- Tools reviewed before any access
- Separate Sandbox and Production environments
01WHO ACTS, FOR WHOM
The agent proves who it is, and the person authorizes what it does on their behalf. Without that approval, no call goes through.
- Person authenticated by your IdP
- Delegation with consent
- Revocation applies on the next call
04AUTHORIZATION IN DETAIL
The rule evaluates the call at the moment it happens.
03TOOL ACCESS
Permission is granted tool by tool, never for the whole server.
02MCP SERVER ACCESS
Each agent sees only the MCP servers granted to it.
01WHO ACTS, FOR WHOM
The agent proves who it is, and the person authorizes what it does on their behalf. Without that approval, no call goes through.
TRACING
Every call, allowed or denied, goes into the trace with the reason for each step. The export goes over OpenTelemetry (OTLP) or webhook to your SIEM.
Today, an agent's token opens every tool on the MCP server
The token does not know which task the agent was given or who it works for. We keep the rules in one place and check every tool call before it reaches the server.
Scattered rulesEvery agent and every MCP server keeps its own permission ifs, and nobody reviews them together.
RULES OUTSIDE THE CODE
Each agent's tools, resources and conditions live in one model, out of the agent's reach. Every publication keeps the author, the date and what changed.
Broad accessThe token unlocks every tool on the MCP server and accepts any argument. A refund of 50 goes through the same way as one of 50,000.
LIMITS ON THE ARGUMENTS
Each tool is granted per agent and per person, with limits on amount or account. A revocation applies to the very next call, and if the attribute lookup fails, the call does not go through.
Hard to explainWhen an agent gets something wrong, no record ties the call to the person and to the rule that allowed it.
THE REASON BEHIND EACH BLOCK
Whoever was stopped gets a short reference, for example bdrr-e2kj. In the Admin, it shows the agent, the person, the tool and the rule that stopped the call. We do not store arguments, responses or tokens.
We sit between the agent and the MCP server
Every tool call goes through policy before it reaches the server, from a coding agent or from a headless service.
The agent never sees the key
After an allow, the PEP makes the call on the agent's behalf. The agent's token stops there, the PEP injects the destination server's credential, and each server gets only what it needs to serve the call. Secrets stay encrypted, with keys that never leave the KMS.
THE TOKEN STOPS AT THE PEP
The agent's token never reaches your systems.at+jwt
CREDENTIAL INJECTION AT THE PEP
- Right before the call, checks again that the token is valid and the tool is still approvediss · exp · catalog
- Vendor server: uses its OAuth token or API key, encrypted with the environment's keyenvelope encryption · KMS
- Your server: gets a token made only for it, with the person and the agent, signed in the KMSJWT · aud (RFC 8707) · sub · act
VENDOR MCP SERVERSTORED CREDENTIAL
Gets the credential of the account that connected the server, and applies that account's permissions. It does not see the person or the agent: those are checked earlier, by the policy.OAuth · API key
YOUR MCP SERVERAUDIENCE-BOUND TOKEN
Checks that the token is genuine and meant for it, then can filter results by person and agent.iss · aud · exp · JWKS
A refund above 500 doesn't go through
Common questions
01Does Xokepoint replace our identity provider?+
No. Keep your existing OIDC identity provider, including Microsoft Entra ID, Google Workspace, Keycloak or Okta. Identity tells you who is acting; Xokepoint evaluates what that agent is allowed to do.
02Is it SaaS or does it run in our infrastructure?+
SaaS. Xokepoint runs the gateway and the control plane; your MCP servers, APIs and identity provider stay where they are.
03Do we need to change the agent's code?+
No. A coding agent such as Claude Code or Codex connects and signs in. A headless agent in your service points to the Xokepoint MCP endpoint instead of the server, and its code stays the same.
04What can Xokepoint control in MCP?+
Xokepoint lets you define which agents can access MCP servers and execute specific tools. Authorization is evaluated at the action level, not just when an agent connects to a server.
05Does Xokepoint see what happens inside the MCP server?+
No. Xokepoint checks the call before it reaches the server. Inside, the server keeps its own permissions, and a tool that calls another API with its own credential stays out of our view.
06Can we limit what an action does, like an amount?+
Yes. Beyond who can call which tool on which resource, a CEL call condition can check the arguments and trusted attributes from your APIs, such as a refund limit or an account status.
07How do we cut an agent's access right now?+
Disable the agent in the Admin. It gets no new token, and its next call is rejected.
08Can an agent call the MCP server directly?+
Your MCP server only accepts the token Xokepoint issues for it, so a direct call is refused. For vendor servers, the credential stays with Xokepoint and the agent never receives it; just don't hand the agent another credential for the same service.
09What happens if Xokepoint is unavailable?+
Protected calls stop. A failure on our side never grants access: without a check, the call does not go through.
10Can we audit why an agent was able to do something?+
Yes. Each checked call records the agent, the person it acted for, the permission revision in force and the reason. Permission changes keep an immutable history with author and note.