generated: '2026-08-05'
method: searched
source: openapi/1fort-openapi-original.yml
docs:
  - https://api.1fort.com/api-docs
  - https://1fort.ai/security
  - https://security.1fort.com/

standards:
  - id: openapi-3
    conforms: false
    evidence: >-
      The published contract is Swagger 2.0 ("swagger": "2.0"), generated by drf-yasg. No OpenAPI 3.x
      document is served. Probed /openapi.json, /openapi.yaml, /v1/openapi.json, /swagger.json on
      api.1fort.com — all 404; the real document is at /api-docs/?format=openapi.
  - id: swagger-2.0
    conforms: true
    evidence: openapi/1fort-openapi-original.yml — swagger 2.0, 451 paths, 574 operations, 198 definitions.
  - id: oauth2
    conforms: false
    evidence: >-
      No oauth2 securityDefinition on the 1Fort API. Both declared schemes are `apiKey` in the
      Authorization header (Bearer JWT, and Api-Key). The OAuth 2.0 / OIDC discovery documents found
      at security.1fort.com/.well-known/* belong to SafeBase's trust-center MCP service
      (issuer https://app.safebase.io/api/mcp), not to the 1Fort API.
  - id: oidc
    conforms: false
    evidence: >-
      No /.well-known/openid-configuration on api.1fort.com or 1fort.ai. 1Fort consumes Google and
      Microsoft identity for sign-in but does not act as an OIDC provider on its public API.
  - id: jwt-rfc7519
    conforms: true
    evidence: >-
      "Almost every endpoint requires a JWT access token. Send it in the Authorization header as
      either `Bearer <token>` or `JWT <token>`." (openapi info.description); refresh via
      auth_token_refresh_create.
  - id: rfc9457-problem-details
    conforms: false
    evidence: >-
      No application/problem+json anywhere in the spec; produces is application/json only. Errors use
      vendor envelopes (GenericError/APIException {detail}, ValidationError field maps, and a v2
      ErrorResponse {error:{code,message}, request_id}).
  - id: rfc9116-security-txt
    conforms: partial
    evidence: >-
      /.well-known/security.txt is served (200) on api.1fort.com, app.1fort.com and auth.1fort.com
      with `Contact: mailto:security@1fort.com`. It carries an `Expires` field of 2026-01-31T12:00:00Z,
      which has passed — RFC 9116 says an expired file should not be relied upon. No Policy,
      Encryption, Preferred-Languages or Canonical fields.
  - id: rfc8594-sunset-header
    conforms: false
    evidence: >-
      17 operations are flagged `deprecated: true` in the spec, but no Sunset or Deprecation response
      header is documented and no removal dates are published.
  - id: rfc8615-well-known
    conforms: partial
    evidence: >-
      security.txt is served at the well-known path. No api-catalog (RFC 9727), no ai-plugin.json,
      no agent-card.json on any 1Fort host.
  - id: llmstxt
    conforms: true
    evidence: https://1fort.ai/llms.txt returns 200 with a well-formed llms.txt (H1, blockquote summary,
      "## Core pages" and "## Optional" link sections). Saved verbatim to llms/1fort-llms.txt.
  - id: a2a
    conforms: false
    evidence: >-
      /.well-known/agent-card.json and /.well-known/agent.json probed on 1fort.ai, api.1fort.com,
      app.1fort.com, auth.1fort.com and security.1fort.com — all 404 (control 404 confirmed on
      1fort.ai, so no SPA catch-all false positive).
  - id: mcp
    conforms: false
    evidence: >-
      No 1Fort-operated MCP server. api.1fort.com/mcp 404, 1fort.ai/mcp 405, security.1fort.com/mcp
      404. The MCP OAuth discovery documents on security.1fort.com point at SafeBase's own service.
  - id: json-api
    conforms: false
    evidence: Plain JSON serializers (Django REST Framework), no application/vnd.api+json.
  - id: odata
    conforms: false
  - id: scim2
    conforms: false
    evidence: User/broker-user management is a bespoke surface (/broker/users, /v2/broker/team-users);
      no /scim/v2 paths.
  - id: acord
    conforms: partial
    evidence: >-
      ACORD forms are handled but not published as a conformance claim. Two operations expose them —
      v2_broker_coverages_accord-forms_accord_form_acroform_pdf (streams the blank AcroForm PDF of an
      ACORD form linked to a coverage) and v2_broker_coverages_accord-forms_accord_form_mapping_file
      (the field mapping file). No ACORD form numbers, versions or data-standard identifiers appear
      in the 198 definitions, and carrier connectivity itself is brokered through the Herald
      integration rather than a published ACORD data mapping.
  - id: herald
    conforms: true
    evidence: >-
      Dedicated `herald (v2)` tag with 11 operations — coverage types, industry classifications
      (including lookup by herald_id), proposal content/PDF, and the /v2/herald/webhook receiver.
      Herald is the carrier-connectivity layer 1Fort submits through.
  - id: pagination
    conforms: true
    evidence: Uniform limit/offset with count/next/previous/results (DRF LimitOffsetPagination).
  - id: idempotency
    conforms: false
    evidence: >-
      No client-supplied idempotency key on any of the 574 operations. See
      conventions/1fort-conventions.yml#idempotency.

compliance_program:
  published: true
  trust_center: https://security.1fort.com/
  trust_center_platform: SafeBase (Drata)
  public_security_page: https://1fort.ai/security
  certifications:
    - name: SOC 2 Type II
      status: attested
      report_access: request-gated on the trust center
      source: https://security.1fort.com/
    - name: HIPAA
      status: claimed
      source: https://security.1fort.com/
    - name: CCPA
      status: claimed
      source: https://1fort.ai/security
  documents_listed_behind_request:
    - SOC 2 Report
    - Pentest Report
    - Network Diagram
    - Cyber Insurance documentation
  controls_published:
    - Audit logging
    - Multi-factor authentication (WebAuthn, phishing-resistant hardware)
    - Encryption at rest and in transit
    - Access monitoring and data backups
    - Secure SDLC and secure development training
    - Data loss prevention, firewall, DNSSEC (corporate network)
    - Disk encryption on endpoints
    - Business continuity / disaster recovery
    - Red-team testing, internal and third-party
  infrastructure: Amazon Web Services
  third_party_rating: SecurityScorecard grade A (as displayed on the trust center)
  note: >-
    The trust center advertises DNSSEC as a network control, but the live probe found DNSSEC NOT
    enabled on either 1fort.ai or 1fort.com (see security/1fort-domain-security.yml). Neither domain
    publishes a CAA record. DMARC is present on both at p=quarantine.

x-evidence:
  - url: https://api.1fort.com/api-docs/?format=openapi
    status: 200
  - url: https://security.1fort.com/
    status: 200
  - url: https://1fort.ai/security
    status: 200
  - url: https://1fort.ai/llms.txt
    status: 200
  - url: https://api.1fort.com/.well-known/security.txt
    status: 200
  - url: https://1fort.ai/.well-known/agent-card.json
    status: 404
  - url: https://api.1fort.com/mcp
    status: 404