generated: '2026-09-09'
method: searched
source: >-
  openapi/aembit-cloud-api-openapi.yml, openapi/aembit-edge-api-openapi.yml,
  https://docs.aembit.io/get-started/security-posture/security-compliance/, https://trust.aembit.io/
standards:
- id: openapi-3.1
  conforms: true
  evidence: 'Both published contracts declare openapi: 3.1.1 (Cloud API, Edge API).'
- id: oauth2
  conforms: false
  evidence: >-
    Aembit's OWN APIs use a bearer API token (http/bearer), not OAuth 2.0 — no oauth2
    securityScheme appears in either contract. Aembit SELLS an OAuth 2.1 MCP Authorization Server
    and an OAuth 2.0 Client Credentials Credential Provider, but those govern customer traffic;
    conforming a provider on a product it sells rather than an interface it exposes would be a
    misattribution.
- id: oidc
  conforms: false
  evidence: >-
    No /.well-known/openid-configuration is served by any Aembit-operated host. The one found at
    trust.aembit.io belongs to SafeBase (issuer https://app.safebase.io/api/mcp). Aembit does
    CONSUME OIDC extensively as a Trust Provider input (OIDC ID Token, GCP identity token,
    GitHub/GitLab ID tokens, Terraform Cloud identity tokens, AWS ALB JWT, GCP IAP JWT).
- id: rfc9457-problem-details
  conforms: false
  evidence: >-
    Errors use a bespoke GenericResponseDTO envelope ({success, message, id}) served as
    application/json. No application/problem+json media type appears anywhere in either contract.
- id: rfc9116-security-txt
  conforms: false
  evidence: No first-party /.well-known/security.txt on any Aembit-operated host (all 404).
- id: rfc8594-sunset-header
  conforms: false
  evidence: No Sunset or Deprecation header appears in either contract; deprecation is signalled by tag naming only.
- id: mcp
  conforms: true
  evidence: >-
    First-party hosted MCP server at https://{tenantId}.mcp.useast2.aembit.io/mcp exposing three
    read-only tools, plus an MCP Identity Gateway and an OAuth 2.1 MCP Authorization Server
    product line. See mcp/aembit-mcp.yml.
- id: a2a
  conforms: false
  evidence: No agent card at /.well-known/agent-card.json or /.well-known/agent.json on any of seven probed hosts.
- id: llms-txt
  conforms: true
  evidence: >-
    Two published llms.txt documents — https://docs.aembit.io/llms.txt (developer) and
    https://aembit.io/llms.txt (company) — plus six section-scoped variants including
    llms-api-cloud-endpoints.txt and llms-api-cloud-schemas.txt.
- id: pagination
  conforms: true
  evidence: 'Uniform offset pagination across the Cloud API: page / per-page query params (defaults 1 / 100) with recordsTotal in list envelopes.'
- id: idempotency
  conforms: false
  evidence: >-
    No Idempotency-Key header, parameter or documented replay-protection mechanism exists in
    either contract or in the docs. See conventions/aembit-conventions.yml.
- id: spiffe
  conforms: true
  evidence: >-
    SPIFFE is documented as a supported workload identity/authentication type on the platform
    overview and in Trust Provider configuration.
- id: scim
  conforms: false
  evidence: >-
    User and Role management is a bespoke REST surface (/api/v1/users, /api/v1/roles); no SCIM
    schema URNs (urn:ietf:params:scim:schemas:*) or /scim/v2 endpoints appear in the contract.
compliance_program:
  published: true
  url: https://docs.aembit.io/get-started/security-posture/security-compliance/
  trust_center: https://trust.aembit.io/
  certifications:
  - {name: SOC 2 Type II, scope: security, availability and confidentiality controls}
  - {name: ISO/IEC 27001:2022, scope: information security management system (ISMS) and risk management}
  supports_customer_regimes:
    note: >-
      Aembit states these as regimes its certifications HELP CUSTOMERS SATISFY, not as its own
      certifications. Recorded with that distinction intact.
    regimes: [HIPAA Security Rule §164.308-312, PCI-DSS Requirement 12, Sarbanes-Oxley IT Controls, FedRAMP (via ISO 27001 / NIST 800-53 alignment)]
  processes: [continuous monitoring, annual third-party SOC 2 Type II and ISO 27001 audits, routine independent penetration testing, RBAC over administrative actions]
  subprocessors: [Salesforce, HubSpot, Google Workspace, Atlassian, Amazon Web Services]
domain_standard:
  market: Workload identity / non-human identity access management
  declared_in_contract: false
  candidates_checked: [scim, spiffe-workload-api, oauth2-token-exchange-rfc8693, openid-federation]
  finding: >-
    REWARD-ONLY CHECK, HONESTLY UNMET. The workload-identity market's nearest standards are
    SPIFFE/SPIFFE Workload API and OAuth 2.0 Token Exchange (RFC 8693). Aembit supports SPIFFE as
    a documented identity type, but neither contract DECLARES a domain-standard signature — no
    SPIFFE ID scheme in a schema, no urn:ietf:params:* URN, no RFC 8693 grant_type in a token
    endpoint. The Edge API's POST /edge/v1/auth is a token-exchange-shaped operation with a
    bespoke AuthRequest/TokenDTO pair rather than the RFC 8693 shape. No domain-standard
    conformance is asserted, and none is invented to fill the slot.