Why Axec

Axec is an authorization and credential-governance layer between an Application and the business systems it needs to use. It gives agents a controlled path from intent to action without transferring broad upstream authority into the agent runtime.

Axec answers four questions independently:

1. Which software identity is calling? Axec resolves a specific Application and exact Application Credential generation.
2. Which upstream capability may it reach? Gateway Connector attachments define an administrator-owned authority ceiling.
3. Whose upstream identity may it use? A User Connection or workspace Vaulted Credential supplies the bounded credential source.
4. What is allowed now? Grants, live lifecycle state, authorization policy, approvals, and Data Protection are evaluated at their defined enforcement points.

The agent access problem

An agent is software that repeatedly chooses and invokes tools while working toward a goal. That changes the access problem in three important ways:

• A natural-language instruction can lead to multiple concrete actions with different risk.
• The next action can change as the model receives new context or tool results.
• The agent may act for a User, for a system, or under its own Application authority.

The emerging IETF model for AI agent authentication and authorization describes agents as workloads and separates workload identity, delegated authority, credential provisioning, policy, and observability. Axec applies the same separation at the action boundary: the agent plans, but Axec decides whether one exact capability may execute with one exact authority path.

The referenced document is an active individual Internet-Draft and work in progress, not an IETF standard. Axec uses it as architectural context rather than making a claim of conformance.

A mission is not authority

An agent may receive a broad mission such as “resolve this support case” or “reconcile these accounts.” The mission explains the desired outcome, but it does not prove:

• which Application is running,
• which User or system delegated authority,
• which account may be used,
• which capability and parameters are permitted, or
• whether that authority remains active.

Axec does not treat model output or a tool selection as an authorization decision. It converts the selected operation into server-resolved facts and evaluates those facts against current authority before credential resolution or upstream contact.

Why identity is not enough

Workload identity can establish which process is calling. It does not establish which User approved access to a particular upstream account or whether the requested operation falls within that approval.

Axec therefore keeps these identities separate:

Identity or resource	What it establishes
Application	The software principal requesting access
Optional workload actor	The configured runtime associated with that Application authority
User	The human principal for delegated access
Gateway Resource	The exact Axec protected resource named by the token request
Connector	The upstream system and capability contract
Connection or Vaulted Credential	The exact upstream credential provenance

A valid Application identity is required, but it cannot substitute for a User Grant, select a different upstream account, or widen an administrator-owned capability ceiling.

Why credential isolation matters

Credentials exposed to an agent runtime can enter prompts, logs, traces, crash reports, generated code, or tool arguments. They can also be targeted by prompt injection. Section 8 of the Internet-Draft explicitly recommends keeping agent and downstream credentials out of the language model context.

Axec’s common MCP and proxy paths keep upstream credentials inside the governance boundary. Axec resolves the admitted credential source, invokes the selected capability, and returns the result. The Application receives neither the User’s refresh token nor a workspace API key.

This also allows Axec to support business systems that still require OAuth tokens, bearer tokens, API keys, or basic authentication without using those credentials as the agent’s identity.

Why a secret vault is not enough

A vault protects stored material. It does not automatically answer whether a credential may be used for this Application, this User, this capability, and this action now.

Axec combines encrypted credential custody with:

• immutable credential provenance,
• administrator-owned capability ceilings,
• User consent and independent Connector Grants,
• current lifecycle and revocation checks,
• narrowing-only policy and approval,
• bounded result protection, and
• correlated security evidence.

Why a generic OAuth proxy is not enough

OAuth provides the protocol foundation for delegated and autonomous access, but the two OAuth relationships in Axec have different principals and credentials:

sequenceDiagram
  participant Application
  participant Axec
  participant Upstream as Upstream provider

  Application->>Axec: Authenticate as an Application
  Axec-->>Application: Resource-bound gateway token
  Axec->>Upstream: Use selected Connection credential
  Upstream-->>Axec: Capability result
  Axec-->>Application: Governed result

A Grant is the governed link between them. It records exactly which Connector authority a User approved for an Application without transferring refresh authority to that Application.

The Axec gateway bearer is a signed reference to authority, not a self-contained replacement for current server state. Every protected operation reloads the relevant Application, gateway, Grant or autonomous attachment, Connector contract, and credential source. Revocation and configuration changes therefore take effect without waiting for every issued bearer to expire.

Why approval must be bound to execution

A confirmation rendered by an agent interface is useful context, but it is not sufficient authorization by itself. This follows the distinction in the draft’s human-in-the-loop model: approval must be tied to the authenticated requester, current authority, exact operation, and eventual execution.

When policy requires step-up, Axec creates a durable ActionRequest before resolving an upstream credential. Approval does not execute the action. The original authenticated client must retry the identical operation, and Axec re-evaluates live authority and policy before dispatch.

Why evidence is part of the control

Monitoring and observability are part of the authorization model, not only an operational concern. Axec correlates:

• the admitted principal and optional workload actor,
• the gateway, Connector, and capability,
• the policy decision and matched rule,
• the approval lifecycle when required,
• the dispatch and upstream outcome, and
• the Data Protection outcome for supported mediated results.

Evidence contains stable identifiers, decisions, and bounded outcomes rather than credentials or unrestricted payloads.

What Axec adds

• Explicit software identity through Applications and exact credential generations.
• Delegated and autonomous authority without conflating User and Application principals.
• Credential mediation through MCP and bounded proxy execution.
• Narrowing-only governance through deny and step-up policy decisions.
• Human approval through durable ActionRequests and authenticated retry.
• Data Protection that masks supported mediated results before delivery or retention.
• Correlated evidence for decisions, approvals, dispatch, sanitization, and upstream outcomes.

Axec is not a workload credential issuer or a complete Agent Identity Management System. It can carry configured workload context, but the documented flows do not claim WIMSE credential issuance, SPIFFE attestation, WIMSE Proof Tokens, HTTP Message Signatures, or transaction-token support. Axec focuses on the authorization and credential-governance boundary where an authenticated Application attempts a business action.

Standards context

• AI Agent Authentication and Authorization, draft-03 describes the broader workload identity, delegation, credential isolation, authorization, and observability model. It is an Internet-Draft and work in progress.
• OAuth 2.0 Authorization Framework (RFC 6749) provides the delegated and client authorization framework used at Axec’s downstream boundary.
• OAuth 2.0 Security Best Current Practice (RFC 9700) provides current IETF security guidance for OAuth deployments.

Where to go next

• Complete the Quickstart for the shortest path to a governed tool call.
• Read How Axec works for the end-to-end trust sequence.
• Explore Concepts when you need exact ownership and lifecycle semantics.
• Review Security Architecture before choosing mediated execution or credential release.