Governance API
20 October 2026 · John Stroh, Director, My Digital Sovereignty Ltd
What it is
The Governance API lets a customer's software submit an action an AI agent wants to take and get back a decision: allow, gate (a person decides) or deny. Each decision comes with a signed receipt the customer can check themselves, without asking us. A record of the discussion behind the decision is kept in the customer's own separate space, in New Zealand or the EU, and can be exported. Sandbox access is on a one-time token issued by John Stroh tied to a single address.
Who it is for
Software vendors and AI builders whose product lets agents do things: send, pay, publish, delete. Their customers ask, "Who decided that agent should act, and what proof is there?" The vendor needs an answer that does not depend on the customer trusting the vendor's own logs.
What a customer gets today
Running now (sandbox, available on request): the interface, signed receipts, records of the deliberation, and an offline checking tool for receipts. Each receipt carries a timestamp from an outside authority (Certum, Poland, which is not a qualified service) or says that none arrived. Signing keys are held by MDSL. In the sandbox the decision comes from a simple rule table, and its receipts are labelled not authoritative. It is for building and testing an integration.
Built: the full decision engine. Switching it on is MDSL's decision. Also built: a qualified timestamp from Aruba PEC (Italy), available on request as an opt-in and priced per stamp; it has not been used on a live customer engagement.
Production keys follow published terms, a data processing agreement and a security review. No production key is issued yet.
The API does not block an agent itself. It returns a decision; the customer's system acts on it.
Published pricing
Prices on request; write to John Stroh.
- Offered only as an add-on to a Village™ subscription. There is no API-only plan.
- Governance Standard, Governance Plus and Assurance: prices on request.
- Sandbox: on a one-time token issued by John Stroh, tied to a single address.
MDSL quotes no figure for this product. The share would be one standard schedule, the same for every distributor; it is drafted, has not been sent to anyone, and would be shown after the NDA.
How to introduce it
- "When your agent does something on a customer's behalf, what can you show them afterwards about who decided it should?"
- "If a customer's auditor asked you to prove a decision record hadn't been changed, could they check it without your help?"
- "Do your customers need their records held in New Zealand or the EU, away from US-owned providers?"
What to say and what never to say
A distributor works to the same wording. MDSL describes it this way: it returns a decision and a signed receipt; the customer can check it offline; the record belongs to the customer and can be exported; it is available on request as a sandbox today; production follows published terms.
MDSL does not use these words about any product: tamper-proof, court-defensible, legally admissible, compliant, certified, immutable, safe. MDSL does not say it prevents an agent doing harm, does not say a production key is available, and quotes no price. Any absolute term needs approved wording from MDSL first.
What we provide you
The interface specification, user guide, versioning policy and client checking tool are written. Introductions to John Stroh for an invitation. The share is one standard schedule, the same for every distributor, sent after the NDA.
Next step
The next step is for the distributor to send the prospect's name, what they intend to build, and their contact; John Stroh then decides whether to issue a sandbox invitation. The subscription itself is between the customer and MDSL.
Nothing in this note is an offer, and no exclusivity, territory or margin is agreed or implied by it. Any arrangement today is with MDSL. If MIO is formed, it may later be assigned to MIO, and the terms would say so. Prices are those on the published pricing page; quote no other.