Identity
Every request through Axec involves a software identity and an authority source. The Application identifies the software making the request, while authorization determines whether it acts for a User or uses its own automation access. When an upstream service requires credentials, Axec uses the exact User Connection or shared credential allowed by that authorization, rather than treating the caller’s identity as permission to use any available account.
Example: Alex asks a support agent to read tickets. The Application identifies the agent, Alex is the User who approves its access, and Alex’s Connection identifies the ticketing account it may use. A Grant records the bounded access Alex approved. If a sensitive action requires review by support-approvers, that group helps determine who can review it; it does not give the agent additional access.
Applications identify the caller
Section titled “Applications identify the caller”An Application is an Account-owned software identity, such as a support agent, backend service, browser assistant, or command-line tool. Its OAuth client identifies the exact client requesting access, and Application Credentials explain how that client authenticates or uses a public-client authorization flow.
The Application is distinct from both the User who authorizes it and the upstream account it accesses. Proving which Application is calling does not prove whose credentials it may use, and a token issued for one gateway or Connector is not a general token for everything in the Account.
Users supply personal authority
Section titled “Users supply personal authority”A User is a person who signs in to an Account to use agents and decide what those agents may do on their behalf. Users sign in through the organization’s configured identity provider, such as Okta or Microsoft Entra ID, and first-time sign-in enrolls them as Users without management roles.
A User can connect an upstream account, review the access an Application requests, and approve or revoke it. These steps establish different parts of the request’s authority:
| Concept | What it establishes |
|---|---|
| User | The person whose authority the Application is using. |
| Connection | That User’s authenticated upstream account for a Connector, such as Alex’s ticketing account. |
| Grant | The exact Connector access approved under a user-to-Application authorization, including its credential source and access limits. |
A Connection alone does not authorize every Application to use it, and signing in does not grant an agent access to all of a User’s accounts. For Axec-mediated MCP and HTTP calls, Axec uses the approved credential source to execute the operation without handing the upstream credential to the Application. See Connectors for credential ownership and Connect an upstream provider for setup.
Whose authority is used?
Section titled “Whose authority is used?”The caller remains an Application whether a person is present or the workload runs in the background. What changes is the authority it can exercise:
| Access pattern | Authority source | Example |
|---|---|---|
| User delegation | A User’s approved access, with the exact Connection or eligible shared credential pinned by the Grant. | Alex authorizes a support agent while signed in. |
| Autonomous access | The Application’s configured automation access through eligible shared Vaulted Credentials or no-auth Connectors, never a User’s Connection. | A scheduled worker reads shared tickets without a User. |
| Previously approved background access | A User’s existing, bounded authorization through an eligible offline or impersonation flow. | A backend continues work Alex approved earlier. |
Naming a User, sharing their email address, or holding an Application credential is not enough to act on their behalf. Background access must follow the supported authorization flow and remains subject to its existing approval and lifecycle limits. Authorization Modes explains delegation, autonomous access, offline access, and impersonation without conflating absence of a User with absence of consent.
Groups inform policies and approvals
Section titled “Groups inform policies and approvals”A group is a named collection of Users in the Account’s directory, such as platform-engineers or support-approvers. Groups let authorization policies refer to a team and let human approval flows select eligible reviewers, rather than listing each person separately.
Axec’s directory is read-only through the management API and console. Provisioning can supply groups and their complete membership sets, while a successful User sign-in can update that User’s memberships from the identity provider’s configured group claim. Provisioned memberships remain current while the User, group, and membership are active; identity-provider observations remain current only until the browser session created by that sign-in expires. Replacing or disabling the owning identity-provider configuration also makes its earlier observations non-current.
Groups supply facts for decisions, not permissions of their own. Membership grants neither Application or Connector access nor a management role, and it cannot replace a Connection or Grant. An approval flow can select a source-qualified group and freeze the assigned User reviewers for a request, so group membership and an existing review assignment are not interchangeable.
Continue
Section titled “Continue”- Applications for software identities and their clients.
- Authorization Modes to choose how an Application obtains access.
- Connectors for upstream accounts and credential ownership.