Skip to content
AxecAxec Docs

How Axec works

Axec sits inside an agent’s act-and-observe loop. Before an agent can call a tool, Axec establishes which Application is acting, whose authority applies, which capability is allowed, and whether that authority is still valid. The agent receives a governed result rather than an upstream credential in the common MCP and proxy paths.

The design follows a strict separation:

agent planning -> authenticated request -> live authorization -> credential use -> business action -> governed result

Planning may begin with natural language, but authorization begins only when the Application requests a concrete Axec resource, Connector, capability, and operation.

Start with the job

Section titled “Start with the job”

Choose the authority path from the job the agent must perform, not from its programming language:

Agent job Use this Axec path Why it fits
Answer or act for a signed-in User Delegated authorization The User connects an upstream account and consents to the exact Connector authority the Application may use.
Run a scheduled or backend agent against shared automation access Autonomous Application The confidential Application uses only its own gateway and workspace-owned vaulted or no-auth attachments. It cannot borrow a User’s Connection.
Provision or maintain Axec tenant resources Service Account management A Service Account receives a short-lived, permission-bounded management token. It is not an agent gateway identity.

An agent is an Application doing agentic work. Axec does not create a separate agent credential class that could blur User, Application, and Service Account authority.

Terminology across the boundary

Section titled “Terminology across the boundary”

The AI Agent Authentication and Authorization Internet-Draft describes a broad architecture in which an agent is a workload that may act for a User, a system, or itself. Axec implements a focused authorization and credential-governance boundary within that model.

Agent architecture concept Axec representation
Agent workload Application doing agentic work
Agent identifier and credential Application identity and Application Credential; optional configured workload actor context
User-delegated authority GrantBundle with independent Connector Grants
Agent acting on its own behalf Autonomous Application authority for its own gateway
Tool, service, or resource Connector capability exposed through MCP or the mediated proxy
Authorization server Axec tenant OAuth endpoints
Protected resource One canonical Axec gateway Resource
Downstream credential User Connection or workspace Vaulted Credential used after admission

The optional workload actor is additional context bound to Application authority. It does not replace the OAuth client, Grant, gateway Resource, or upstream credential provenance.

The agent access loop

Section titled “The agent access loop”
flowchart LR
  Agent[Agent selects a capability]
  Identity[Axec authenticates the Application]
  Authority[Axec reloads live authority]
  Decision[Policy denies, requires approval, or allows]
  Dispatch[Axec dispatches the admitted capability]
  Protection[Data Protection handles supported results]
  Result[Agent receives a governed result and evidence]

  Agent --> Identity --> Authority --> Decision --> Dispatch --> Protection --> Result

This loop runs for each governed operation. It matters because an LLM can choose a different tool or repeat a call as new context arrives; a bearer token alone must not preserve authority after a Grant, Connection, attachment, credential, or tenant is restricted.

1. Establish the Application identity

Section titled “1. Establish the Application identity”

Axec first resolves the downstream software principal and its current client registration. A public client has no client secret; S256 PKCE binds authorization-code redemption to the client instance that started the flow. A confidential Application authenticates with its active Application Credential. That credential is accepted only at Axec and is never used with the upstream provider.

2. Bind the request to one Resource

Section titled “2. Bind the request to one Resource”

The OAuth request names the canonical gateway Resource. The resulting bearer is audience-bound to that Resource and carries only the operation scopes established by the corresponding authorization path. A token for one gateway is not a general tenant token.

3. Resolve the principal and authority path

Section titled “3. Resolve the principal and authority path”

Axec distinguishes two principal modes:

  • User principal: the request must resolve an active GrantBundle and the independent Grant for the requested Connector.
  • Application principal: the request may use only eligible active vaulted or none attachments on the Application’s own gateway.

The Application-principal path cannot load a User Connection. The User-principal path cannot silently substitute a different Connection or credential generation.

4. Reload live authority

Section titled “4. Reload live authority”

The gateway bearer identifies the authority to evaluate. Axec reloads the current account, principal, client profile, exact Application Credential, gateway, Grant or attachment, Connector contract, and credential source. Status, expiry, replacement identities, and authorization digests are checked before policy runs.

This makes the database-backed authority graph the current source of truth. The signed bearer provides integrity and routing; it does not freeze permission until token expiry.

5. Evaluate narrowing policy

Section titled “5. Evaluate narrowing policy”

Policy receives typed, server-resolved identity and authorization facts. It can deny the operation or require step-up, but it cannot create a missing Grant, attach a Connector, select an unrelated credential, or widen a capability ceiling.

6. Resolve credentials only after admission

Section titled “6. Resolve credentials only after admission”

Axec does not decrypt or inject an upstream credential until identity, base authority, policy, and any required approval have succeeded. For MCP and mediated proxy calls, the credential stays inside Axec and is applied only to the admitted upstream request.

7. Dispatch, protect, and record

Section titled “7. Dispatch, protect, and record”

Axec records a durable dispatch boundary before upstream execution. Supported bounded MCP and proxy results then pass through active Data Protection policy before retention or delivery. Decision, approval, dispatch, transformation, and outcome evidence share the same correlation context.

The trust chain

Section titled “The trust chain”
flowchart LR
  Credential[Application Credential]
  Client[Application OAuth client]
  Grant[User GrantBundle and Grant]
  Attachment[Gateway Connector attachment]
  Source[Connection or Vaulted Credential]
  Capability[Upstream capability]

  Credential --> Client --> Grant --> Attachment --> Source --> Capability

Each link has its own owner and lifecycle. A valid token alone does not preserve authority after a Grant, Connection, attachment, credential, or tenant is restricted.

Why exact identities and digests matter

Section titled “Why exact identities and digests matter”

Axec does not bind consent to a broad Connector name alone. A delegated Grant pins the exact attachment, Connector, credential provenance, capability and scope ceiling, and relevant contract digests. This prevents several silent authority changes:

  • reconnecting an upstream account does not transfer old consent to the new Connection,
  • replacing a workspace credential does not silently update a Grant to broader authority,
  • changing a Connector capability contract does not reinterpret earlier consent, and
  • rotating an Application Credential can invalidate authority tied to the prior generation.

Replacement creates new authority identities while historical records remain available for explanation and evidence.

Standards at the boundary

Section titled “Standards at the boundary”

Axec uses open protocol building blocks so standard MCP and OAuth clients can participate:

These standards establish client authentication and token routing. Axec adds the live Connector, Connection, Grant, policy, approval, Data Protection, and evidence checks that decide whether a particular agent action can proceed now.

The agent-auth Internet-Draft provides useful context for this composition. In particular, it separates agent identity from delegated authority, recommends keeping credentials outside language-model context, and treats observability and remediation as part of the authorization system. It does not define an Axec protocol, and its requirements are not used here as a claim of IETF compliance.

Delegated User authority

Section titled “Delegated User authority”

Use delegated authority when an Application acts for a signed-in User. This is the right model for a support copilot, research assistant, or custom MCP server that must use the User’s own upstream account without receiving its refresh token.

sequenceDiagram
  participant Client
  participant Axec
  participant User
  participant Upstream

  Client->>Axec: Start Authorization Code with PKCE
  Axec->>User: Authenticate and show authority
  User->>Upstream: Complete missing Connection
  User->>Axec: Accept consent
  Axec-->>Client: Redeem code for Resource-bound gateway token
  Client->>Axec: Invoke a governed operation
  Axec->>Axec: Reload live authority

The User owns each Connection. A Grant pins the exact Connection or workspace credential provenance and the capability/scoping ceiling accepted at consent time. Reconnecting creates new authority rather than silently mutating old Grants.

The downstream bearer does not contain the User’s provider token. It represents permission to invoke the named Axec gateway under the current GrantBundle. At execution time, Axec resolves the exact admitted Connection, decrypts its provider credential within the server boundary, and invokes only the allowed capability.

Autonomous Application authority

Section titled “Autonomous Application authority”

Use autonomous authority when a confidential Application calls its own gateway without a User GrantBundle. This is the right model for a scheduled reconciliation agent or service workflow using workspace-owned automation access, not for background use of a User’s account.

sequenceDiagram
  participant Application
  participant Axec
  participant Gateway

  Application->>Axec: Client Credentials for own gateway Resource
  Axec-->>Application: Application-principal gateway token
  Application->>Gateway: Invoke admitted capability
  Gateway->>Gateway: Load active vaulted or no-auth attachments

An autonomous Application cannot borrow a User Connection or convert itself into delegated authority.

The workload URI configured for an autonomous Application identifies the expected runtime context carried with its Application authority. In the current documented flow, the confidential Application Credential authenticates the client to Axec. Axec does not claim that this URI alone is SPIFFE attestation or proof of possession of a WIMSE credential.

Governance order

Section titled “Governance order”

Governance never creates missing base authority. It begins only after the request has passed current identity, audience, scope, Grant or attachment, Connector, credential-source, and capability checks.

live base authority
  -> authorization policy (deny, step_up, or default allow)
  -> approval and authenticated identical retry when required
  -> upstream execution
  -> Data Protection on bounded MCP/proxy results
  -> sanitized delivery/retention and correlated evidence

Authorization policy

Section titled “Authorization policy”

Policy targets one surface—MCP, mediated proxy, or credential release—and can further restrict admitted authority. A matching deny wins. A matching step-up rule pauses the operation. If no restrictive rule matches, the already-authorized request is allowed.

Human approval

Section titled “Human approval”

Step-up creates a durable ActionRequest without retaining unrestricted arguments or request bodies for approvers. Polling only reads status. After approval, the authenticated client retries the identical request; Axec reloads live authority and policy before execution.

Data Protection

Section titled “Data Protection”

Data Protection runs after a mediated MCP or proxy call returns and before the result is retained or delivered. It masks bounded supported content using server-owned profiles. It does not inspect the upstream request, and it cannot govern later provider calls made directly with a released credential.

Evidence

Section titled “Evidence”

Axec correlates the policy decision, approval lifecycle, dispatch marker, sanitization outcome, and upstream outcome without storing credentials or unrestricted payloads in evidence.

Credential handling by execution surface

Section titled “Credential handling by execution surface”

The security boundary changes according to how the Application reaches the provider:

Surface What the Application receives What Axec can govern
MCP gateway Governed MCP result Admission, exact capability dispatch, policy, approval, supported result protection, and evidence
Mediated proxy Governed HTTP response Admission, exact method/path contract, policy, approval, supported result protection, and evidence
Credential release One eligible bounded provider OAuth access token The release decision and delivery evidence only

Credential release is intentionally narrower. Once a provider access token is released, Axec cannot observe later direct provider calls, sanitize their results, or retract the token before provider expiry. Refresh tokens, User-entered static credentials, and workspace Vaulted Credentials are not released.

Security properties and boundaries

Section titled “Security properties and boundaries”

Credentials stay outside model context

Section titled “Credentials stay outside model context”

In mediated paths, upstream credentials remain inside Axec. The Application sends intent and operation arguments; Axec injects credential material only into the admitted provider request. This reduces the opportunity for credentials to enter model prompts, generated code, logs, or tool output.

Transport security and request identity are separate

Section titled “Transport security and request identity are separate”

TLS protects the connection to Axec. OAuth client authentication and the gateway bearer establish application-layer identity and resource authority across reverse proxies and routing infrastructure. Deployments should not infer User delegation or Connector authority from network location alone.

Approval does not bypass current policy

Section titled “Approval does not bypass current policy”

An ActionRequest captures safe action identity and a policy snapshot, but approval is not execution authority in isolation. Completion requires the same authenticated principal, client, optional workload actor, Resource, operation scope, authority bindings, and canonical input. Axec then reloads current policy and base authority before dispatch.

Evidence is intentionally secret-free

Section titled “Evidence is intentionally secret-free”

Evidence supports reconstruction without becoming a second sensitive-data store. It records stable identifiers, decision reasons, correlation, and bounded outcomes. It excludes complete tokens, authorization headers, unrestricted request bodies, raw provider results, and detected sensitive values.

Standards and current implementation

Section titled “Standards and current implementation”

Axec composes published OAuth standards at its public protocol boundary and keeps emerging agent identity mechanisms as separate deployment concerns.

Mechanism Current Axec role
OAuth Authorization Code and Client Credentials Implemented for delegated and autonomous Application authorization
PKCE Required for public authorization-code clients
OAuth Resource Indicators Binds authorization and tokens to one gateway Resource
Protected Resource and Authorization Server Metadata Supports MCP authorization discovery
Dynamic Client Registration Supports eligible public MCP clients
Configured workload URI Optional actor context bound to Application authority
WIMSE credentials and Workload Proof Tokens Not claimed by the documented Axec flows
SPIFFE SVID issuance or attestation Not provided by Axec
HTTP Message Signatures for workload authentication Not claimed by the documented Axec flows
OAuth Transaction Tokens Not implemented as Axec’s internal call-chain mechanism

This separation allows an organization to use its preferred workload identity system while Axec remains responsible for the business authorization path from authenticated Application to governed upstream action.

Implement a path

Section titled “Implement a path”

Govern and explain results

Section titled “Govern and explain results”