Security Architecture

Axec is an authorization and credential-governance boundary. It authenticates the calling Application, resolves current delegated or autonomous authority, mediates an exact upstream capability, and records secret-free evidence.

Trust boundaries

flowchart LR
  Application[Client Application]
  Axec[Axec authorization and governance boundary]
  Upstream[Upstream system]

  Application -->|Application identity and gateway bearer| Axec
  Axec -->|Connection or Vaulted Credential after admission| Upstream

An Application Credential authenticates software to Axec. A Connection or Vaulted Credential authenticates Axec to an upstream system. They are different credentials with different owners and must not be substituted for one another.

Principal separation

• User-delegated Application: a User approves independent Connector Grants under a GrantBundle.
• Autonomous Application: the Application uses its own eligible administrator-attached Connector authority.
• Workload actor: optional authenticated runtime identity associated with an Application; it does not replace the OAuth client or gateway.
• Service Account: tenant management automation only; it does not inherit Application, gateway, User, Connection, Grant, or group authority.

Credential custody

Application secrets are stored as password-resistant hashes. Upstream OAuth tokens, personal credentials, and Vaulted Credentials are envelope-encrypted. Inventory and evidence projections expose only safe identifiers, fingerprints, modes, and lifecycle metadata.

Credential exchange is a deliberately narrower boundary: Axec can authorize and evidence the release of a bounded provider access token, but it cannot observe, govern, or sanitize the caller’s later direct provider requests. Use mediated MCP or proxy execution when request-level enforcement is required.

Live authority enforcement

Every protected operation reloads the current tenant, principal, OAuth client, optional workload actor, gateway, operation scope, exact Grant or attachment, Connector contract, credential source, expiry, and revocation state. Token validity alone does not preserve removed authority.

Policy runs only after base authority succeeds and can only narrow it:

flowchart LR
  Authority[Live base authority]
  Policy[Authorization policy]
  Approval[Approval and identical retry when required]
  Dispatch[Durable dispatch marker]
  Upstream[Upstream execution]
  Protection[Data Protection on bounded results]
  Evidence[Sanitized delivery, retention, and evidence]

  Authority --> Policy --> Approval --> Dispatch --> Upstream --> Protection --> Evidence

Approval and mutation safety

A step-up decision freezes safe action identity in an ActionRequest. Approvers never receive unrestricted MCP arguments, proxy headers, query values, bodies, or credentials. Polling does not execute the action. Approval permits the client to retry the identical authenticated request; Axec revalidates live authority and policy first.

Mutating governed actions require idempotency. After upstream dispatch, an ambiguous or sanitization failure cannot automatically redispatch a mutation.

Data Protection boundary

Data Protection runs after successful mediated MCP or proxy execution and before result retention or client delivery. Matching policies compose their server-owned detection profiles and mask supported bounded JSON or text deterministically.

If the policy snapshot, decoder, detector, or transformation is unavailable, Axec withholds the result and returns data_protection_unavailable. It never falls back to the unsanitized body.

Data Protection does not inspect upstream requests, credentials, arbitrary caller claims, direct provider calls, MCP initialization, tool-list responses, or credential-release responses.

Evidence boundary

Evidence can include stable principal and resource identifiers, decision and reason codes, matched rule keys, policy snapshot digests, ActionRequest correlation, dispatch and outcome states, matched profile categories, and bounded redaction counts.

Evidence must not include plaintext secrets, hashes, complete tokens, authorization headers, unrestricted request bodies, raw upstream results, or detected sensitive values.

Control-profile limitations

Personal data, health data, payment-card data, credential/secret data, and OWASP sensitive-data-exposure profiles are operational detection and masking controls. References to HIPAA, GDPR, CCPA, PCI DSS, or OWASP do not certify compliance, guarantee detection, establish legal compliance, or replace an organization’s own risk assessment.

Failure posture

• Missing or stale base authority: deny before policy or credential resolution.
• Incomplete policy context or evaluation error: deny before upstream contact.
• Expired or denied approval: do not execute.
• Evidence or dispatch-intent failure before execution: fail closed.
• Sanitization failure after dispatch: withhold the result and do not automatically redispatch.