generated: '2026-08-26'
method: probed
source: 'live probes of https://api.poshdevelopment.com + https://app.poshdevelopment.com + https://security.posh.ai'
note: >-
  No OpenAPI securitySchemes exist to derive from — Posh publishes no contract — so this profile
  is built only from observed gateway behaviour and Posh's own security claims. The scheme name,
  header and token format are NOT recorded because they were not observable, and inventing them
  would be worse than an honest gap.
public_documentation: false
schemes: []
observed:
  - surface: https://api.poshdevelopment.com/api-docs
    http_status: 403
    body: 'RBAC: access denied'
    content_type: text/plain
    finding: >-
      The gateway enforces role-based access control at the edge, ahead of the application error
      handler. This is a positive signal that authorization is centrally enforced, and it is the
      wall that makes the API reference unreadable to the public.
  - surface: https://app.poshdevelopment.com/login
    http_status: 200
    finding: >-
      The Posh Portal is a browser SPA behind a login form. No OIDC discovery document is served
      (/.well-known/openid-configuration returns the SPA shell, not a document), so the identity
      provider could not be identified.
  - surface: https://api.poshdevelopment.com/.well-known/oauth-authorization-server
    http_status: 404
    finding: 'No RFC 8414 authorization-server metadata.'
  - surface: https://api.poshdevelopment.com/.well-known/openid-configuration
    http_status: 404
    finding: 'No OIDC discovery.'
provider_claims:
  - claim: multi-factor authentication
    source: https://security.posh.ai/
  - claim: role-based access control
    source: https://security.posh.ai/
  - claim: voice-based biometric authentication, opt-in consent only
    source: https://www.posh.ai/security-privacy-policy
  - claim: 'multi-factor authentication and core system integration in the Voice Assistant'
    source: https://www.posh.ai/llms.txt
embedded_surface_auth:
  component: Posh Answers web embed
  mechanism: 'Two opaque public identifiers passed as script-tag data attributes: data-org_id and data-user_key.'
  source: https://poshie-chat-api.poshdevelopment.com/entry-answers.js
  note: >-
    Read from the shipped loader, not from documentation. Both values are also accepted as URL
    query parameters (posh_org_id, posh_user_key), which means they are public, page-embedded
    identifiers rather than secrets. They scope the embed to a tenant; they are not API
    credentials and must not be treated as such.
gaps:
  - no public authentication documentation
  - no OIDC or OAuth discovery document on any host
  - token format, header name and credential lifecycle all unknown to the public