This policy describes how Monop Content identifies, analyses, mitigates, tests and monitors risk across the lifecycle of the AILeash platform — the decision engine, the tamper-evident audit chain, the delegation layer (authority, KYC sealing, jurisdiction tagging), the public notaries, Brain, and the hosted infrastructure they run on.
It applies to all platform components, all releases, and all environments (the hosted cloud service and the sovereign on-premise engine). It is written to align with the risk-management system expectations of Article 9 of the EU AI Act, and it is published because a governance vendor's own risk posture should be inspectable.
Monop Content is at present a single-operator company. Accountability is therefore simple and total: the Founder is the risk owner for every item in this policy — identification, mitigation, testing, monitoring, incident response and review. There is no diffusion of responsibility. As the company grows, this section will be revised to assign named owners per risk area, and that revision will be sealed (see §8).
Risks are identified continuously through four channels: design review before any change ships; automated verification of the chain after every deployment; monitoring of live traffic, error rates and blocked-event patterns; and external input (customer reports, security disclosures to justin@monopcontent.com, and the public verifiability of the chain itself — anyone can attempt to falsify our records at any time).
The principal risk register:
| Risk | Potential impact | Mitigation (see §4) |
|---|---|---|
| Chain integrity failure | Evidence loses probative value | Single-lock sealed writes; WAL journaling; anchored tip; public verification endpoint; daily backups |
| Incorrect verdicts (false ALLOW / false BLOCK) | Customer harm; missed threats or blocked legitimate activity | Deterministic scoring; plain-English reasons on every verdict; CHALLENGE band for borderline cases; human-oversight flow |
| Availability loss | Customers cannot govern events | Stateless integration pattern; automatic restart; daily database backups; customer-side fail-safe guidance in developer docs |
| Unauthorised access / key compromise | Records written under a stolen key | Bearer-key auth; per-key rate limits; HMAC-signed tokens; no key material in the chain; secrets held in environment, never in code |
| Data protection failure | Personal data exposure | Data-minimising design throughout — fingerprints not content, hashes not references; see the Data Protection Statement (MC-POL-002) |
| Overclaim / misdescription of capability | Customers rely on protections that do not exist | Honest-limits statements on every product page, in the whitepaper, and sealed into our own chain; deliberate refusal to claim correctness-proving or compliance-conferring capability |
| Single-operator continuity | Maintenance interruption | Self-contained stdlib architecture; sovereign engine option gives customers independence; documented codebase; daily backups; see §7 |
The platform's primary risk controls are architectural rather than procedural — chosen so that safety does not depend on anyone remembering to follow a process:
Every release passes, in order: compilation and unit checks on changed components (including, for the delegation layer, explicit negative tests — expired, tampered, wrong-user and over-limit tokens must all escalate correctly); deployment to the production environment via version-controlled GitHub-to-Railway pipeline, so every deployed state is attributable to a commit; and post-deployment verification, including chain-integrity confirmation via the public endpoint and a live governed event to confirm end-to-end behaviour. A release is not considered complete until the chain verifies green after it.
Live monitoring includes platform-level request/error metrics (hosting dashboard), per-customer visibility via the authenticated pulse and coverage endpoints, and automatic e-mail alerts to account holders when the engine blocks on their traffic. The public verification endpoint acts as a standing, continuous integrity test that anyone may run.
On any suspected integrity, security or availability incident: the affected component is isolated or the platform paused; the chain is verified to establish the exact boundary of any impact (tampering localises to a block index by design); affected customers are informed with the sealed evidence of what occurred; the fix is deployed through the standard release path; and the incident and remedy are recorded. The chain itself makes honest incident disclosure enforceable — we could not quietly rewrite an incident out of history even if we wished to.
The platform is deliberately built as a self-contained, dependency-light system (Python standard library, single-file server) to minimise supply-chain and bus-factor risk. Databases are backed up daily. Customers requiring full independence from Monop Content's continuity can deploy the sovereign engine inside their own network with offline licence validation — their governance does not stop if we do.
This policy is reviewed quarterly, and immediately upon any material change to the platform's architecture, data handling or product claims. Each revision is fingerprinted and sealed into the AILeash chain, making the policy's own history tamper-evident — the same standard the platform applies to everything else. The current version is always published at this address.