How Axec works

Axec sits between your agent and the services it uses. The agent never holds a service credential. It sends each request to Axec, and Axec works out who is asking, decides whether the request is allowed, makes the call with the right credential, and records what happened. This page follows one request through that path, then explains how the agent gets its access in the first place.

Three terms come up throughout. Your agent is an Application, each service it uses is a Connector, and a gateway is one URL that brings the tools of several connectors together. Examples use a support agent that reads tickets for Alex. An administrator or developer sets these up once, as the Quickstart shows.

Follow one request

When the agent decides to call a tool, the request travels through the same checks every time. This matters because a model can choose a different tool or repeat a call as the conversation changes, so an earlier approval is never enough on its own.

1. Who is asking. Axec identifies the Application making the call and checks that the access token was issued to it for this exact connector or gateway. A token for one connector cannot be used for another.
2. Whose access is used. The request either acts for a person, using only what that person approved, or acts for the Application itself, using only shared credentials set up for automation. Axec never lets one stand in for the other.
3. Is that access still valid. Axec reloads the current state on every request instead of trusting the token alone. If Alex revokes his approval, disconnects his account, or an administrator removes the connector, the next call stops.
4. Do the rules allow it. Policies can block an action or require a person to approve it first, but they can only narrow access, never widen it.
5. Axec calls the service. Only now does Axec use the stored credential, and it uses it inside Axec. The agent sends what it wants done and gets the answer back, and the credential never reaches the model, its prompts, or its logs.
6. The result comes back protected and recorded. Supported results can have sensitive values masked before the agent sees them, and Axec records the call.

How the agent gets its access

Access starts in one of two ways, depending on whether a person is involved.

When the agent acts for a person, the person approves it once. The agent sends Alex to Axec, Alex signs in with your company login, connects his account at the service if he has not already, reviews what the agent is asking for, and approves it. The agent receives a token that works only within that approval.

When the agent acts on its own, such as a nightly job, no one is signed in. The agent proves its identity to Axec with its own credential and can use only the shared credentials an administrator set up for it, never anyone’s personal account.

Two variations follow from these. An agent that must keep working after Alex has gone offline can ask for offline access when he approves, which gives it a bounded token that Axec can rotate and revoke. And managing Axec itself, such as listing Applications, uses a separate Service Account that cannot call tools at all. Authorization Modes explains how to choose between them.

See it with curl

The SDKs make these calls for you. Underneath, getting access takes two requests and using it takes one. The examples use a workspace named acme and a gateway at https://axec.dev/g/support/mcp.

Acting for a person

First, send the person to Axec to sign in and approve. This is a browser request, so open it as a link:

GET https://axec.dev/ws/acme/oauth2/authorize
  response_type=code
  client_id=<your client ID>
  redirect_uri=http://127.0.0.1:3000/callback
  resource=https://axec.dev/g/support/mcp
  scope=mcp:invoke
  code_challenge=<hash of a secret you keep>
  code_challenge_method=S256
  state=<random value>

Alex signs in and approves, and Axec sends the browser back to your redirect_uri with a one-time code. Trade it for an access token, along with the secret you kept:

curl https://axec.dev/oauth2/token \
  -d grant_type=authorization_code \
  -d client_id="$CLIENT_ID" \
  -d code="$CODE" \
  -d redirect_uri="http://127.0.0.1:3000/callback" \
  -d code_verifier="$CODE_VERIFIER" \
  -d resource="https://axec.dev/g/support/mcp"

The response contains an access_token. It works only for this gateway and only within what Alex approved.

On its own

An agent running on its own has no sign-in. It uses its own client secret to ask for a token:

curl https://axec.dev/oauth2/token \
  -u "$CLIENT_ID:$CLIENT_SECRET" \
  -d grant_type=client_credentials \
  -d resource="https://axec.dev/g/support/mcp" \
  -d scope=mcp:invoke

The response contains an access_token. It can use only the shared credentials set up for this Application, never a person’s account.

With either token, the agent calls a tool. Each request stands alone, so there is no session to manage. Send a tools/list request first to see the tool names you can use.

curl https://axec.dev/g/support/mcp \
  -H "Authorization: Bearer $ACCESS_TOKEN" \
  -H "Accept: application/json, text/event-stream" \
  -H "Content-Type: application/json" \
  -H "MCP-Protocol-Version: 2025-06-18" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"tickets__tickets.list","arguments":{"state":"open"}}}'

The response is the tool’s result. Your code never sees the service credential.

Approvals, limits, and records

• Approval. A policy can require a person, or a team such as your support leads, to approve a sensitive action first. Axec pauses the request, and once it is approved, the agent retries the identical request and Axec checks access again before running it. An approval covers that one request, not the agent in general.
• Limits. Through MCP tools and Axec’s HTTP proxy, credentials stay in Axec. The one exception is for confidential clients, which can be released a limited token to call a provider directly. Axec cannot see or restrict those direct calls, so use the normal paths when you need per-request controls.
• Records. For each call, Axec records which Application acted, whose access it used, what was decided, and what happened, without credentials or full request and response contents. You can review calls in the console.

Security Architecture covers all three in detail.

Built on open standards

Axec uses OAuth 2.0 with PKCE and resource-bound tokens, so standard MCP and OAuth clients can sign in without custom code. The SDKs handle these steps for you.

Where to go next

• Quickstart makes a governed tool call with the SDK.
• Concepts explains Applications, connectors, identity, and authorization modes in more depth.
• Guides cover acting for a user, autonomous applications, and offline access.
• SDK reference shows the TypeScript and Python interfaces for each path.