Security posture: what is implemented, and what is not

Controls implemented in the running system

The controls below are enforced by the application code and the edge proxy on every request to the production origin. Each one can be verified from outside without access to our infrastructure.

• Nonce-based Content Security Policy

  Every HTML response carries a per-request CSP nonce. Production uses 'strict-dynamic' so only scripts loaded by an already-trusted script execute. 'unsafe-eval' is development-only.

• Transport and framing hardening

  Strict-Transport-Security with a two-year max-age, includeSubDomains and preload; X-Content-Type-Options nosniff; X-Frame-Options DENY plus frame-ancestors 'none'; Cross-Origin-Opener-Policy and Cross-Origin-Resource-Policy set.

• Explicit permissions policy

  Camera, geolocation, USB, Bluetooth, serial, MIDI, motion sensors and display capture are disabled. Microphone access is limited to the Pak-LLM origins because voice input requires it.

• Administrative authentication is signature-verified

  Admin requests are accepted only with a Firebase ID token whose RS256 signature is verified against Google's published JWKS, or with an operator-configured secret compared in constant time. There is no built-in master key and unverified JWT payloads are never trusted.

• API key storage

  Developer API keys are stored as one-way SHA-256 hashes with a visible prefix for identification. The plaintext key is shown once at creation and is not recoverable afterwards.

• Webhook integrity

  Inbound webhooks are verified with HMAC-SHA256 signatures using timing-safe comparison. CORS preflights are handled explicitly and state-changing API requests are origin-checked.

• Single canonical origin

  www and .org host variants permanently redirect to https://pak-llm.com, and HTTP is upgraded, so credentials and cookies are not accepted on alternate hostnames.

• Responsible disclosure channel

  RFC 9116 security.txt is published at /.well-known/security.txt with a security contact, an encryption key, a safe-harbour statement, and an expiry date that is reviewed before it lapses.

• Training-crawler opt-out

  AI training crawlers are disallowed in robots.txt while search and answer-engine crawlers remain allowed. This is a documented policy decision, not an accident of configuration.

Standards used as design references

A design reference means the standard informed how a control was built. It does not mean an accredited body audited Pak-LLM against that standard. These are listed separately so the distinction is unambiguous.

• OWASP ASVS and the OWASP LLM Top 10 — used as a control checklist during review.
• NIST AI Risk Management Framework 1.0 — used to structure AI risk discussion.
• AES-256-GCM — the authenticated symmetric cipher used for the credential vault. Post-quantum ML-KEM migration is on the roadmap, not implemented.
• ISO/IEC 27001 and ISO/IEC 42001 — used as reference models for information-security and AI-management practice.
• Pakistan Draft Personal Data Protection Bill — used to shape consent, retention, and deletion behaviour.
• State Bank of Pakistan cloud-outsourcing expectations — used when scoping on-premise deployments for financial clients.

Known limitations

These are the gaps we are aware of. Publishing them is more useful to a security reviewer than a page of unqualified assurances.

• Pak-LLM does not publish a SOC 2 Type II report, an ISO certification certificate, or an independent penetration-test report on this site. If a page elsewhere on this site implies a certification we have not evidenced, treat this statement as authoritative and ask us for documentation.
• Default inference is hybrid: the control plane and stored data are domestic, while inference may execute on third-party accelerators under zero-retention terms. Fully air-gapped operation requires the on-premise deployment.
• Uptime figures and latency targets are engineering goals, not contractual SLAs, unless a signed enterprise agreement states otherwise.
• Email authentication (SPF, DKIM, DMARC) is being tightened; enforcement status depends on DNS records maintained outside this codebase and should be checked with a DNS lookup rather than assumed.
• Security headers are verified on the production origin. A staging or preview deployment may serve different headers.

How to verify these claims

Every statement above can be checked from a terminal against the production origin. If a result disagrees with this page, the live response is the truth and we want to know about it.