Trust · Security

Defended by design. Documented so it can be audited.

Security is a discipline, not a claim. This page states the threats we design against, the controls that mitigate them, how we respond when something goes wrong, and how to report a suspected issue.

Threat model

What we design against.

A short, honest threat model. The categories of risk that shape our control choices. Detailed control mappings are provided in the security pack under NDA.

Credential compromise

Mitigated by mandatory MFA for staff, SSO/SAML for customer sign in, short lived session tokens, and continuous review of privileged access.

Data exfiltration

Mitigated by access based on the principle of least privilege, isolation per tenant, egress controls at the VPC boundary, and access to production data logged for audit.

Supply chain compromise

Mitigated by locked dependency manifests, signed build artifacts, automated scanning of dependencies for vulnerabilities, and infrastructure as code review before merge.

Infrastructure compromise

Mitigated by hardening native to AWS, private network defaults, restricted management planes, and immutable deployment pipelines with signed artifacts.

Insider misuse

Mitigated by scoped access, session logging on production, mandatory code review, background checks on engineering roles that touch customer environments, and separation of duties for release.

Vulnerability at the application layer

Mitigated by static analysis in CI, dependency scanning, secure development practices, and a responsible disclosure program with a defined intake channel.

Controls

How the platform is defended in practice.

Encryption in transit

TLS 1.3 across all customer endpoints. HSTS enforced. Modern cipher suites only.

Encryption at rest

AES-256 for databases and object storage. Keys managed in AWS KMS with separation per tenant. Automatic key rotation.

Customer authentication

SSO/SAML 2.0 supported (Okta, Azure AD, Google Workspace). MFA policy inherited from the identity provider. SCIM provisioning available.

Staff access

MFA required. Standing access to production is scoped to a named on call group. Just in time access for support tickets, revoked automatically on ticket closure.

Backups

Automated daily backups with point in time recovery for production databases. Encrypted at rest. Restore drills performed on a documented schedule.

Isolation

Logical isolation per tenant at the application layer, enforced by row level and object scope checks. No shared build hosts. Segmented VPCs by environment.

Incident response

What happens when something goes wrong.

A defined process, a named on call rotation, and a written commitment on customer notification. Not improvised.

STEP 01

Detect

Continuous monitoring on production, application error tracking, and structured audit logs. Alerts route to a named on call rotation with defined acknowledgment windows.

STEP 02

Contain

An incident commander is assigned. Contain first. Rotate credentials, isolate affected components, halt inbound traffic to affected surfaces if required.

STEP 03

Notify

Material incidents affecting customer data trigger notification within the window defined in the master services agreement. Named security contacts on file are the recipients.

STEP 04

Remediate and review

Root cause is documented. Remediation is tracked to completion. Each material incident produces a written post incident review, shared with affected customers on request.

Responsible disclosure

Report it. We will respond.

We rely on the security community. If you believe you have found a vulnerability in Knowledge Foundry, please report it to security@knowledge-foundry.com. Reports are triaged by a named engineer, not a shared inbox.

Please act in good faith: do not access data beyond what is required to demonstrate the issue, do not exfiltrate customer content, and allow us reasonable time to remediate before public disclosure. In return, we commit to acknowledge receipt promptly, keep you informed through triage and fix, and not pursue legal action against research conducted in good faith under these terms.

Common questions

Reporting and disclosure. Practical questions.

Email security@knowledge-foundry.com. Please include a description of the issue, the affected surface, reproduction steps, and any impact assessment you have made. If the finding is sensitive, request our PGP key in your first email.
We aim to acknowledge receipt within two business days. Substantive triage response follows within five business days for reports with sufficient detail to reproduce.
We do not currently operate a paid bounty program. We do maintain a public acknowledgments list, with your permission, for researchers who disclose responsibly.
Denial of service, social engineering against staff, physical access, and issues that require access to another customer's tenant to reproduce. Report those only if you have observed real world impact, not hypothetically.
No, provided you act in good faith, do not access data beyond what is necessary to demonstrate the issue, do not exfiltrate data, and give us reasonable time to remediate before public disclosure.
For enterprise procurement

The security pack.

A more detailed control mapping, summary of penetration testing, business continuity plan, and incident response run book is available to prospective enterprise customers under mutual non-disclosure. Request it via a demonstration or by emailing security@knowledge-foundry.com.