Pharoah Technology Ltd
The governance layer for surveillance you already run.
Pharoah Security Core is an access-controlled HTTP API and operator console that holds a camera estate to a named jurisdiction's rules — retention, signage, masking, subject access, and tamper-evident export — over the cameras and video management system you already own.
There is no self-serve signup. Deployments are provisioned individually — see how access actually works.
What it is
A compliance and evidence spine, not a camera vendor and not a video management system. You keep your cameras, your recorder and your network. The Core holds the inventory, decides what each camera is lawfully allowed to do in its jurisdiction, enforces retention by actually deleting footage, and produces the evidence a regulator or a court asks for afterwards.
It is built to be answerable. Controls fail closed rather than open: an export that cannot be masked lawfully is refused, an unsigned device is rejected, an unresolvable retention rule deletes rather than hoards, and a surveillance lookup that fails says so instead of reporting an all-clear.
What the deployed build does
Each item below is implemented in the running service. Endpoints are named so you can check them against the API reference.
Camera registry bound to a legal profile
Every camera carries a jurisdiction profile, a zone classification (private interior, private exterior, communal, public-facing) and a retention period validated against that profile's ceiling. Placements the profile forbids are rejected at write time, not flagged in a report later.
GET/POST /cameras · PUT /cameras/{id}Retention enforced by deletion
A daily sweep deletes footage past its camera's ceiling and removes the backing file. Cameras you have marked as recorded by your own VMS are never touched by it — we did not write those bytes, so we do not delete them.
scheduled job · main.py:34Privacy masking that fails closed
Configured mask rectangles are painted into every export. A camera whose profile requires default masking but has no rectangles configured refuses to export at all, returning 409, rather than emitting unmasked footage.
POST /recordings/{id}/exportExport attestation
Every export and wearable capture is hashed with SHA-256 over exactly the bytes handed over, and recorded in an attestation ledger with the recipient and the masking outcome. The attestation record outlives the footage it describes.
GET /attestationsStatutory signage generation
Generates the video-surveillance notice a camera's jurisdiction requires, carrying the data controller identity, purpose and rights contact configured for the deployment.
GET /cameras/{id}/signageDPIA and compliance matrix
Builds a GDPR Article 35(7) Data Protection Impact Assessment from the live camera inventory and runtime configuration, plus a per-jurisdiction requirement-to-control crosswalk. Both render as JSON or markdown for a tender annex.
GET /compliance/dpia · /compliance/matrixSubject access requests
A worked DSAR path: record the request, track it, and fulfil it with disclosure that carries the same masking the export pipeline applies.
POST/GET /subject-rightsAudit log
Logins, camera writes, exports with their recipient, refused exports and their reason, DPIA generation and consent-gated lookups are all written to a queryable audit log.
GET /auditEvents and alert dispatch
Events run through a rule engine on arrival and raise acknowledgeable alerts. The deployed core dispatches to a configured HMAC-signed webhook channel.
POST /events · GET /alerts · POST /alerts/{id}/ackSigned edge ingestion
Edge nodes and wearable devices post over HMAC-SHA256 signatures rather than bearer tokens. Unsigned traffic is refused, and a node that stops sending heartbeats is swept to offline and alerted once per outage.
POST /events/ingest · /nodes/heartbeat · /wearables/captureTSCM sweep records
Technical surveillance counter-measures sweeps as first-class records: baseline, RF and probe ingest, findings, and a generated report.
POST /tscm/sweeps · GET /tscm/sweeps/{id}/reportNearby surveillance, consent first
Looks up cameras mapped in OpenStreetMap around a point. It shows you the exact payload that would leave the device before anything leaves it, and it distinguishes “nothing is mapped here” from “we could not check” with different status codes — an anti-surveillance tool must never report a failed lookup as an all-clear.
GET /nearby/privacy-notice · /nearby/surveillanceJurisdiction profiles
Four profiles ship with the build. A camera is bound to one, and the profile's ceiling is enforced on write and again by the retention sweep. Each profile records the instrument it derives from, so an auditor can check our reading of the law rather than take it on trust.
| Key | Jurisdiction | Default retention | Basis |
|---|---|---|---|
spain | Spain — EU GDPR + LOPDGDD | 30 days | AEPD video-surveillance guidance / Instrucción 1/2006 |
uk | United Kingdom — DPA 2018 / UK GDPR | 31 days | Surveillance Camera Code of Practice (PoFA 2012) |
ecowas | ECOWAS member states | 30 days | Supplementary Act A/SA.1/01/10 on Personal Data Protection |
sierra_leone | Sierra Leone | 30 days | ECOWAS-aligned; conservative pending local regulator ruling |
These profiles are our documented interpretation of the instruments named, not legal advice. Your data protection officer should review them against your own processing.
Access model
Authentication is a signed bearer token obtained from POST /auth/login. Every
other route requires it. Roles are coarse, auditable permission scopes rather than per-object
access lists:
| Role | Holds |
|---|---|
owner | Everything (break-glass; cannot be locked out by design) |
admin | Every scope, no wildcard |
operator | Read/write cameras and events, view streams and recordings, acknowledge alerts |
auditor | Read cameras, events, alerts and the audit log; export recordings |
viewer | Read cameras, events and alerts; view streams |
Roles are re-read from the database on every request, so revoking a role takes effect immediately rather than when a token expires.
Deliberate limits
Stated plainly, because you are buying a control and a control you have been misled about is worse than none. These are true of the hosted core as configured today:
- Single tenant per deployment. The hosted core stores to a single embedded database on one volume. There is no shared multi-tenant estate — each customer is a separate deployment, provisioned individually.
- No detection engine attached. The build can consume detections from an external inference service, and the module is enabled, but no such service is attached to the hosted core. Nothing on this site should be read as us doing AI video analytics for you today.
- No live-view gateway attached. The token-gated HLS playback proxy is implemented and enabled, but the hosted core has no stream gateway configured, so stream descriptors report live view as unavailable rather than returning a URL.
- Attestation is local. Export hashes are computed and stored, and the hand-off to an external evidence ledger is implemented — but no external ledger is configured on the hosted core, so attestations remain unanchored outside it.
- Government production is on-premise. The hosted core is for evaluation, integration and non-classified estates. Regulated production deployments run inside your own perimeter.
- Nothing is publicly readable. There is no anonymous endpoint other than the liveness check, and the interactive schema browser is switched off in production so the attack surface is not publicly enumerable.
How access actually works
Listed at £299 per month, per deployment. There is no checkout button on this site, and that is on purpose: provisioning a tenant today means standing up an instance, binding your jurisdiction profile and issuing operator credentials by hand. We are not going to take a card for something that is delivered manually until that path is automated end to end.
So the honest sequence is: you send an access request, we talk about your estate and its jurisdiction, and we provision and hand over credentials. If your requirement is on-premise or classified, say so in the request — that is a different deployment shape.