Applications

An Application is a software identity that belongs to an Account. Applications usually represent software agents that access upstream tools and services.

An Application can also represent a backend service, browser application, or command-line tool. It is separate from the User who authorizes access and the upstream account it accesses.

Example: A Support Agent uses an Application to access ticketing and messaging tools. The Application identifies the agent, not Alex, the User who asks it to read tickets.

Application Credentials

An OAuth client defines how software identifies itself to Axec and authenticates. A platform-managed Application can own multiple clients with independent configurations.

Axec supports two client types:

• Public: The client has no client secret. Delegated authorization uses PKCE (RFC 7636).
• Private: The client proves its identity with a client secret or a signed assertion. OAuth calls these clients confidential.

A client ID identifies the client. It is not a secret and does not grant access by itself. It can be an Axec-issued identifier or a hosted metadata URL.

Client type and registration method are separate choices. See Registration for how Axec establishes a client.

Example: The Support Agent has a Public browser client and a Private background-worker client.

See Application Credentials for client details, authentication examples, and the credential lifecycle.

Registration

Registration establishes the Application and its OAuth client configuration in Axec. Registration does not itself grant access to an upstream account.

Platform-managed Applications

An administrator creates and manages an Application and its clients through the Axec Console or management API. These clients can be Public or Private.

Example: An administrator creates the Support Agent and configures its browser and background-worker clients before deployment.

A managed client can use a URL credential. Using a metadata URL does not make it a Dynamic Application.

Dynamic Applications

A Dynamic Application is an Application that Axec establishes through a registration protocol rather than administrator setup. Dynamic Applications have Public clients and use delegated authorization.

Axec supports two methods:

• Dynamic Client Registration (DCR): The client submits its configuration to the OAuth registration endpoint and receives a client ID. Axec implements RFC 7591.
• CIMD: When enabled, Axec establishes the client during authorization using its hosted Client ID Metadata Document URL as the client ID. No DCR request occurs.

DCR example: A coding agent registers at runtime before starting delegated authorization. An administrator does not need to create that Application in advance.

CIMD example: An assistant supplies its metadata URL as the client ID during authorization. If an administrator enables CIMD, Axec reads the document and establishes the Public client.

Registration method and client type answer different questions. Registration describes how Axec establishes the client. Client type describes how it authenticates.

Operating modes

An operating mode describes whose authority the Application uses. It is separate from the credential that the client uses to authenticate.

Delegated access

In delegated access, an Application acts on behalf of a User. Access remains limited to the authority established for that User and client.

Example: Alex asks the Support Agent to read tickets using Alex’s upstream account. The agent uses delegated authorization rather than its own autonomous access.

Public clients use this mode. See Act on behalf of a User for the authorization flow.

Autonomous access

In autonomous access, an Application acts as itself, without User delegation. Its Private client uses the OAuth Client Credentials grant (RFC 6749 §4.4).

Autonomous access requires an active dependency and an eligible workspace-owned credential or no-auth path. It cannot use User-owned Connections.

Example: A scheduled Support Agent reads shared tickets using an eligible workspace Vaulted Credential. The task does not use Alex’s upstream account.

Private clients currently use this mode only. See Autonomous Applications for the execution flow.

Dependencies

A dependency declares which Connector or Gateway Application an Application may access. Direct Connector dependencies also define the allowed capability keys.

Dependencies set access limits. Creating a dependency does not connect a User’s upstream account or create User consent.

Example: An administrator gives the Support Agent a dependency on a ticketing Connector with permission to read tickets. That dependency does not authorize use of Alex’s ticketing account.

An Application can depend directly on Connectors or access them through a Gateway Application.

Gateway Applications

A Gateway Application is a special Application type that exposes a protected MCP endpoint. It aggregates compatible downstream Connector capabilities through dependencies.

A Gateway Application is secretless. It owns no OAuth clients or Application credentials. Calling Applications authenticate to Axec separately to access the gateway.

Example: A Support Gateway exposes ticketing and messaging capabilities at /ws/acme/g/support/mcp. The Support Agent authenticates through its own client to access that endpoint.

Secretless does not mean anonymous. The caller still needs valid authority for the gateway and the selected operation.

See MCP Gateways for the request path.

Consent

Consent is the User’s approval of delegated access. Consent mode controls whether Axec requires its consent screen for a new authorization.

Administrators configure consent mode on each Connector, not on the Application.

Required consent

With required, the User must explicitly approve the new authorization in Axec. This is the default mode.

Example: Alex reviews the Support Agent’s requested ticketing access and approves it before authorization continues.

Implicit consent

With implicit, Axec can complete an eligible managed authorization without a separate Axec consent screen. It does not reuse an earlier approval.

Automatic completion requires all selected Connectors to:

• Use implicit consent.
• Support personal OAuth with Authorization Code.
• Exclude acquisition through Client Credentials.

Example: A managed assistant uses eligible personal OAuth Connectors configured for implicit consent. Axec can complete authorization without a separate Axec consent screen.

The User may still need to authenticate or authorize Axec at the upstream provider. Some recovery cases still require explicit consent.

Dynamic Applications always require explicit consent, even when a Connector uses implicit. Consent mode does not change credential or delegated-access lifetimes.

Disabling access

Disabling an Application denies access through all its clients. Disabling one client denies access through that client without disabling its siblings.

Revoking a credential denies authentication and protected use tied to that credential. An existing bearer token does not override these restrictions.

Example: An administrator disables the Support Agent’s browser client. The background-worker client remains active, but the disabled browser client cannot continue using its existing token.