Concepts
Axec sits between AI agents and the systems they need to use, such as GitHub, Jira, Slack, or your own internal APIs and MCP services. It lets an agent retrieve information and perform actions in those systems without ever holding the upstream credentials, and it keeps every step of that access under the control of the people and policies responsible for it.
These pages explain the ideas behind that, and the way to read them is to follow a single request. A person or a scheduled job runs an agent, the agent connects to an Axec gateway, Axec authenticates it and works out whose authority it is using, and Axec then calls the right upstream service with the right credential. Each concept below answers one part of that story.
Where everything lives
Section titled “Where everything lives”An Account is your organization’s isolated environment in Axec, holding its Applications, Connectors, gateways, Users, and policies. Each Account currently has one Workspace, which is the name used for that same environment in API routes, OAuth configuration, and SDKs, rather than a separate container to create or manage.
Identity connects who is calling to whose authority they use. Users sign in through your identity provider, connect their own upstream accounts, and approve what agents may do for them, while Operators administer the Account through separate management identities. Groups collect Users from your directory so that policies and approvals can refer to a team, but membership alone does not grant access.
How agents get access
Section titled “How agents get access”An Application is the software identity of an agent or client, and it is what Axec recognizes when something asks for access. Application Credentials describe how an Application proves who it is, whether as a Public client that relies on PKCE or as a Private client that holds a secret or key.
Knowing who the Application is does not settle whose authority it uses, and that is the job of Authorization Modes. An Application can act for a signed-in User, act on its own behalf with shared credentials, or act for a User who approved it earlier and is no longer present, and each mode determines which credentials and approvals are involved.
What agents can reach
Section titled “What agents can reach”A Connector represents an upstream service, whether an enterprise product from Axec’s catalog or one of your own HTTP APIs and MCP servers, and it defines how Axec reaches the service, which operations it offers as capabilities, and how Axec authenticates to it. The credentials a Connector uses are either a User’s own Connection, such as an OAuth link to their GitHub account, or a shared credential that the Account stores in its vault.
MCP Gateways are how agents reach Connectors in practice. A gateway is an MCP endpoint that Axec hosts and secures with OAuth 2.1, it combines tools from several Connectors behind one URL, and AI clients such as Claude, Cursor, and opencode can add it like any other MCP server while Axec handles authentication and applies the upstream credentials.
Managing Axec
Section titled “Managing Axec”Administration covers Operator sign-in and Service Accounts. Service Accounts let a pipeline or script manage an Account’s resources through the management API, but they cannot call tools or act for a User.
Where to go next
Section titled “Where to go next”Concepts describe how Axec is organized, and the rest of the documentation shows how to use it. The Guides walk through connecting a client, acting for a User, and running autonomous Applications, and the Connector reference lists the supported integrations. Security Architecture explains the trust boundaries behind those workflows.