Skip to content

Account

An Account is your organization’s isolated environment in Axec. It contains the Applications, Connectors, gateways, Users, and policies that govern how agents access your systems, while keeping Connections, credentials, approvals, and access evidence within that Account.

Example: Acme configures a support agent, Connectors for its ticketing and messaging systems, and policies for sensitive actions in its Account. Users sign in to connect their own upstream accounts and approve the access the agent needs.

An Account holds the Applications that request access, the Connectors to upstream services and the shared credentials they use, and the MCP gateways that expose them to AI clients. It also holds the Users who sign in and approve access, the groups they belong to, each User’s upstream Connections, the policies and approvals that govern tool calls, and the evidence those calls produce.

People who manage Axec are Operators, with an administrator or viewer role. Administrators can change configuration, while viewers have read-only management access across the Account. Operators sign in with a password or the Account’s configured single sign-on, separately from Users.

Management access does not let an Operator use a User’s personal Connections or act on that User’s behalf. Matching emails or a shared identity provider do not merge these identities, and neither being a User nor belonging to a User group grants a management role.

Service Accounts let pipelines and scripts automate management tasks with explicitly granted permissions. They cannot invoke MCP tools or act for a User; workloads that execute tools need an Application and the appropriate authorization.

The Account is the isolation boundary. An Application in one Account cannot use another Account’s Connectors, and a User’s Connections and approvals belong to the Account in which they were made. Within an Account, access still depends on the Application’s configured dependencies, the approved credential source, and the applicable policies; belonging to the same Account does not grant unrestricted access.

Each Account currently has one Workspace, which represents the same environment in API routes, OAuth configuration, and SDKs. There is no separate Workspace container to create or manage within an Account, and multiple Workspaces per Account are not currently supported.

Where a setup guide asks for your Workspace key, use your Account’s slug, such as acme. Existing routes retain Workspace terminology, including /ws/acme and /api/v1/ws/acme, and SDK management methods such as workspaceApi() select that Account’s environment. Gateway MCP URLs use the gateway’s own key, for example https://axec.dev/g/support/mcp, rather than a Workspace-prefixed gateway address.

  • Identity to understand callers, Users, groups, and approved access.
  • Applications to see how software is registered in an Account.