Applications

An Application is a tenant-owned software principal. It identifies the software requesting access; it is not a User, a Service Account, or an upstream account.

An Application can have either or both of these roles:

• An OAuth client that requests Axec authorization.
• An MCP gateway that exposes a protected Resource.

The client Application and gateway Application can be different in a delegated User flow. For an Application-principal Client Credentials flow, they must be the same Application.

What an Application owns

Depending on its role, an Application can own:

• An OAuth client profile, including its client ID, redirect URIs, registration method, offline-access limits, and lifecycle state.
• An MCP gateway, including its route key, canonical Resource URI, authorization digest, and lifecycle state.
• An active Application Credential that proves which client is calling.
• Administrator-defined Connector attachments that form the gateway’s authority ceiling.

Creating an Application does not create a Connection, GrantBundle, or Grant. Those records appear only when their own setup or authorization flow succeeds.

Delegated and autonomous use

In a delegated flow, a User authorizes a client Application to use selected authority at a gateway Application. The resulting GrantBundles and Grants preserve that relationship.

In an autonomous flow, a confidential Application uses Client Credentials against its own gateway. It can use only eligible workspace-owned vaulted or no-auth Connector attachments—not User Connections.

An agent is product terminology for an Application doing agentic work. It is not a separate principal or authentication kind.

Lifecycle effects

Disabling an Application, its OAuth profile, its gateway, or its exact credential removes a required link from live authority. Existing bearer tokens do not override that state.

Next, learn how Application Credentials prove the caller and how MCP Gateways expose governed Resources.