Governance document · Publicly binding · Effective 2025

The OMMAU Charter

OMMAU — One Man, Many Agents, Unicorn — is Cloak's model for responsible AI-augmented operations. This charter defines what Cloak commits to as it uses AI agents to build and operate its products, and what that means for customer trust.

Core principle: Humans authorize. Agents execute. Receipts prove it.
Article I

Preamble — What OMMAU means

Cloak Pte. Ltd. is a small team building data protection infrastructure for professionals, developers, and enterprises. We operate with a lean human team augmented by AI agents that handle research, code review, customer operations, and parts of product delivery.

OMMAU — One Man, Many Agents, Unicorn — captures this reality honestly. We believe a small, disciplined team using AI agents can build and operate a product at a scale that previously required a much larger organisation. We do not pretend otherwise, and we do not hide this from customers.

This charter exists because we sell security products. Our customers trust us with encryption keys, signing certificates, and access policy for their most sensitive files. That trust requires us to be explicit about how AI agents participate in our operations — and what limits we place on that participation.

Article II

Scope of agent use at Cloak

Cloak uses AI agents in the following areas:

  • Engineering: Code generation, code review, test writing, documentation, and refactoring — supervised by a human engineer who reviews and merges all changes.
  • Customer operations: Drafting responses to support queries, summarising issues, and routing escalations — a human reviews all outbound communications before they are sent.
  • Research and intelligence: Market research, competitor analysis, pricing analysis, and lead qualification — agents surface findings; humans make decisions.
  • Content and marketing: Website copy, blog posts, email drafts, and social content — all reviewed and approved by a human before publication.
  • Internal analytics: Summarising operational metrics, generating weekly review reports, and flagging anomalies — for human review, never automated action.

Cloak does not use AI agents to:

  • Make autonomous financial commitments or payments above defined thresholds without human approval.
  • Access, read, or process customer files, keys, or encrypted data — ever. Customer cryptographic material is handled only by Cloak's production infrastructure, not by any AI agent tool or context window.
  • Make changes to production infrastructure or customer-facing configuration without a human reviewing and approving the change.
  • Contact customers directly without a human reviewing the message first.
Article III

Human control principles

Every significant agent action at Cloak is governed by one of three control modes:

  • Supervised execution: The agent performs a task and a human reviews the output before it takes effect. This applies to all code changes, customer communications, and content publication.
  • Bounded autonomy: The agent operates within a pre-approved policy — defined scope, defined limits, defined time window. The agent cannot modify its own policy. A human reviews the audit log periodically. This applies to research agents, analytics summarisation, and automated scheduling.
  • Blocked categories: Some actions agents are never permitted to take, regardless of instruction — accessing customer cryptographic material, making production changes without human review, or contacting customers without approval. These are not configurable.

When Cloak's own products are used by customer agents, the same three-mode model applies: the human customer sets the policy, the agent executes within it, and every operation is receipted. This is not an aspiration — it is the technical implementation of every MCP tool and API endpoint Cloak exposes.

Article IV

Receipt and audit commitments

Cloak's core product commitment is the signed audit receipt. Every file encryption, key operation, signing operation, and access revocation returns a JSON receipt containing:

  • The operation type and timestamp
  • The acting principal (human or agent session ID)
  • The policy applied
  • A hash of the affected data or key reference
  • A cryptographic signature verifiable against Cloak's published public key

Receipts are verifiable in any browser without requiring a Cloak account or network call to Cloak's servers. The verifier fetches Cloak's published JWKS (ECDSA P-256, ES256) once and runs the signature check locally. The signing key is HSM-held, never extracted, and rotated annually with old kids retained in the JWKS so historical receipts remain verifiable indefinitely.

Cloak commits that: No receipt will be issued for an operation that did not occur. No operation will occur without a receipt being issued. Receipt signatures cannot be forged without access to Cloak's private signing key, which is stored in hardware (HSM) and never extracted. If Cloak ever cannot sustain this commitment due to a security incident, we will notify all affected customers within 72 hours.

Article V

Customer data and agent access

Cloak's architecture is designed so that customer data is encrypted before it leaves the customer's environment. Cloak's servers see ciphertext, not plaintext. This is not a policy position — it is the technical design.

AI agents used internally at Cloak do not have access to:

  • Customer encryption keys or key material
  • Customer plaintext files or document content
  • Customer identity information beyond what is necessary for support (name, email, account tier)
  • Production Cassandra data stores containing customer operation records

Internal agents that handle customer support summaries operate only on sanitised, anonymised data — never on raw Cassandra records, raw logs, or anything that could reveal PII or cryptographic material.

Cloak does not use customer data to train AI models, improve third-party AI services, or share with any AI vendor — including the vendors whose models power Cloak's internal agent stack.

Article VI

The three governance filters

Every significant decision at Cloak — product, operational, or strategic — is evaluated against three filters before being acted on. These filters apply equally to decisions made by humans and recommendations made by agents.

1

Does it protect the customer?

Any change to a product feature, API behaviour, receipt format, or key management policy must be evaluated for its effect on the customer's security posture. If the change weakens a security guarantee — even marginally — it requires explicit customer communication and opt-in, not a silent deployment.

2

Does it generate revenue or reduce cost toward $1M ARR?

Cloak operates at a scale where every engineering hour counts. Features, integrations, and infrastructure investments are evaluated against their contribution to reaching $1M ARR with the current team and agent stack. Work that does not contribute to revenue or does not reduce a critical cost is deferred, regardless of how interesting it is technically.

3

Can a small team operate this sustainably?

Any feature that requires ongoing human attention proportional to customer count is a scaling problem. Cloak's architecture favours automation, receipts, and self-service over manual processes. If a product capability requires a human to be in the loop for every customer instance, it is a candidate for automation before launch — not after scale.

Article VII

Cloak's public commitments

By publishing this charter, Cloak makes the following commitments to its customers, publicly and in writing:

Receipts for every operation. Every cryptographic operation on Cloak's platform returns a signed, verifiable receipt. No exceptions. No silent operations.

Keys in hardware. On HSM plans, customer keys are generated and stored inside HSM hardware and never extracted as plaintext — not for debugging, not for migration, not for any operational purpose.

No AI access to customer cryptographic material. AI agents used internally at Cloak do not have access to customer keys, key material, or plaintext data. This is a hard architectural constraint, not a policy.

Human review before customer impact. Any product change that affects a security guarantee, pricing, or customer data handling will be reviewed and approved by a human before deployment.

72-hour incident notification. If a security incident affects the integrity of receipts, the confidentiality of customer keys, or the availability of customer data, affected customers will be notified within 72 hours.

No training on customer data. Cloak does not use customer data — files, keys, receipts, usage patterns, or identifiers — to train AI models or improve any AI service.

Charter updates are versioned and announced. Any material change to this charter will be announced publicly and versioned. Previous versions will remain accessible. Customers on Enterprise plans will be notified directly.

Article VIII

Amendments and versioning

This charter is versioned. The current version is 1.0, effective 1 January 2025. All versions are maintained in Cloak's public git repository and referenced by SHA hash for immutability.

Amendments are proposed internally, reviewed by at least one human team member and one external advisor, and published with a version increment and changelog entry. No amendment may reduce the commitments made in Article VII without a 90-day customer notice period.

Questions about this charter may be directed to governance@cloakapps.com. Cloak commits to responding to governance questions within 5 business days.

Version
1.0
Effective date
1 January 2025
Entity
Cloak Pte. Ltd.
Jurisdiction
Singapore
Cloak
"Humans authorize. Agents execute. Receipts prove it."

This is the operating principle at the heart of every Cloak product and every Cloak agent deployment. We publish this charter because our customers deserve to know — not because we are required to.