Security Overview

OakHive runs one interview engine, reached through a browser session. The customer portal and the administrative plane are separate applications with separate authentication.

Everything runs on Microsoft Azure in Microsoft Azure, West Europe (Netherlands): managed container applications for the services, a managed document database for interview records, a managed search index for retrieval, and a managed key vault for secrets.

• Every stored record carries a tenant identifier, and that identifier is the database partition key. There is no record without one.
• Every query is scoped to a tenant. Reaching another tenant’s data is not a matter of a filter being remembered — the partition is the boundary.
• The tenant is resolved from a validated access token, never from a value in the request body. A single resolution path serves all channels, and it fails closed: an identity that maps to no tenant, or to more than one, is rejected before any endpoint runs.
• Cross-tenant access is covered by dedicated isolation tests that write a document into one tenant’s partition and assert it cannot be read through another’s. They assert against a real database rather than a mock, which means they run against a provisioned environment rather than on an ordinary build.

• Users authenticate against their own Microsoft Entra ID tenant. OakHive issues no passwords and stores none, so there is no credential database to lose.
• Multi-factor authentication, conditional access and session policy are inherited from the customer’s own Entra configuration — which is the right place for them, because that is where the customer already manages them.
• A browser interview link is inert on its own. Joining requires a token whose subject matches the participant recorded on that interview; forwarding the link to a colleague achieves nothing.
• Each browser session carries a signed marker bound to a nonce that is re-minted on every join, so a captured marker cannot be replayed into a live session.
• The cross-tenant administrative plane is separate, and every endpoint on it is protected by an authorisation filter applied by the framework rather than by a check written into each method. A test enforces that the filter is present on any future controller added there.

Access to an interview is deny-by-default. What a role may see is decided on the server, and the response is shaped to it.

• Material a role may not see is absent from the response, not hidden by the interface. There is no client-side gate to bypass, because there is nothing behind it.
• The successor payload is built by enumerating the permitted fields rather than by removing the forbidden ones, so a field added later cannot leak by being forgotten.
• Knowledge search follows interview access. Being able to retrieve something through search is the same grant as being able to read it in the portal — one grant, one place to manage it.
• Write access in the portal is limited to license administrators and to managers.

• Material marked sensitive during an interview is routed mechanically to a restricted section. It is excluded from the search index, stripped from the viewer payload, and left out of the handover guide.
• Manager notes are a private briefing. They never appear in a generated artefact, in an invitation, or in anything shown to the participant. A source-level check enforces that the invitation builder cannot even receive them.
• Transcript disclosure outside the administrative plane always passes through a single sanitiser. Stored records keep their annotations; what is shown and what is indexed do not.

• TLS on every connection, including to every subprocessor.
• Platform-managed encryption at rest on the database, the search index and storage.
• Secrets live in a managed key vault and are delivered to the applications as environment configuration at deployment. They are not in source control.
• A check runs on every deployment asserting that the running application has every configuration value its code reads. It was built after a missing value silently disabled a feature rather than failing loudly.

• Exceptions pass through one sanitising chokepoint before they are stored, so a stack trace cannot carry interview text into the error store.
• Error records expire automatically after 90 days.
• Audit records cover every write and every sensitive read. IP address and user agent are no longer retained in them — the record is who did what, to what, and when.
• Every request carries a correlation identifier, returned in the response header, so an incident can be reconstructed without trawling.
• Unhandled failures return a generic error and a correlation identifier. Stack traces are never returned to a client.

• Input validation on every externally supplied value: format, length and range.
• Directory search inputs are matched against a strict character whitelist before they reach the query, closing off query injection into the directory API.
• Rendered HTML is sanitised in the browser before it is inserted into the page.
• Prompt injection is addressed in layers: a pattern filter on input, hardening in the system prompt, and sanitisation of generated content before anything is indexed.
• Spoken output passes through a filter that strips the internal control tags, so an annotation can never be read aloud to a participant.
• Rate limits: 60 requests per minute on the portal, 120 per minute on the administrative plane, and 30 knowledge queries per hour per user in chat.
• Inbound platform webhooks are signature-validated against the publisher’s key set, and handling is serialised per call so two events for the same call cannot race.
• Security headers — content security policy, framing, referrer and content-type options — are set on every response.

• All customer data is stored in Microsoft Azure, West Europe (Netherlands).
• No participant audio is stored. No participant video is ever captured — the camera is never requested.
• Interviews are deleted on the customer’s retention schedule, default 730 days, with destruction of the remaining record 30 days later. Search entries go when the interview goes.
• Backups are platform-managed and age out on their normal cycle; after termination they are gone within 90 days.

• All changes go through version control and an automated pipeline.
• The automated test suite runs on every push, and includes tests written specifically to protect security invariants: tenant resolution, the administrative authorisation filter, and the role-shaped response payloads.
• Two guards run in the deployment pipeline alongside the tests, and fail it: one asserting that no log statement can carry interview content or personal data, and one asserting that no transcript has been committed to the repository.
• Checks run on deployment confirming that the running application has the configuration and the data stores its code expects.
• Platform components are managed services, patched by the provider. Application dependencies are reviewed and updated as part of ordinary development; there is no automated dependency-scanning gate today.

Report anything you find to security@oakhive.ai. We will acknowledge within one business day.

Good-faith security research is welcome. We will not pursue a researcher who reports a finding responsibly, stays within the minimum access needed to demonstrate it, does not access or retain another customer’s data, and gives us reasonable time to fix it. We do not currently run a paid bounty programme.

Where a personal data breach affects customer data, we notify the customer without undue delay and within 72 hours of becoming aware, as clause 10 of the DPA sets out. The decision to notify a regulator or the affected individuals belongs to the customer as controller, and we support it rather than pre-empt it.

• Access to production systems is limited to the personnel who need it, granted on a least-privilege basis, and logged.
• Everyone with access is bound by confidentiality obligations that survive the end of their engagement.
• OakHive is a small team. That is a security fact worth stating rather than hiding: the number of people who could reach customer data is small and known, and access is not spread across a large organisation.

Stated so you do not have to ask, and so nothing above is read as implying more than it says.

No third-party certification

There is no ISO 27001 certificate and no SOC 2 report. The measures described here are implemented and can be evidenced, but they have not been attested by an external auditor. If certification is a condition of purchase, raise it before signature rather than after.

No independent penetration test

Security testing to date has been internal — code review, automated tests written against specific attack paths, and adversarial exercises against the product’s own guard rails. No external firm has tested the system.

No published uptime commitment

The service is in private beta and offers no service level agreement or service credits. The infrastructure is deliberately pinned to a single instance per service because in-progress interview state is held in memory; that is a correctness decision. A browser interview rebuilds from the stored transcript and continues across a deployment.

Known limitations recorded in the DPA

Annex IV of the Data Processing Agreement lists the specific points where the current implementation falls short of what we would want a mature version to promise — including the storage region being a contractual rather than a technical control, and the browser channel’s speech provider retaining for one day rather than zero.