Security policy (review draft)

A proposed coordinated-disclosure policy; there is no supported-version table yet, and the machine-readable security.txt on this site has not been updated to match it.

Download the plain-text source.

KALEIDOSCOPE SECURITY POLICY
REVIEWED DRAFT - NOT YET IN FORCE

Draft of 23 August 2026


STATUS OF THIS DOCUMENT

This is a complete draft. It is not yet in force.

It has been reviewed by legal counsel for Kleos Research Private Limited, which
has not yet adopted it. Nothing in it is an offer, a contract, or a description
of terms that govern anything today.

One part of this document is different, and deliberately so: the authorisation
in section 6. We give it now, as a standing permission rather than as a
promise about the future, because a safe harbour nobody can act on is worth
nothing. If you have already researched, or already reported, in reliance on
it, it covers you. See section 13.

One thing this document cannot fix on its own. The machine-readable
security.txt file on our website still says that no production security intake
is published, and its contact line points at a page rather than at an address.
That file has not been updated to match this policy. If you are reading this,
the address in section 1 is the one to use.


1. WHO WE ARE

Kleos Research Private Limited ("Kleos Research", "we", "us") is a private
limited company incorporated in India and registered in Delhi.

    Kleos Research Private Limited
    Email: contact@kleosresearch.xyz

That address is monitored. It is the address for vulnerability reports and for
everything else in this policy.

Our full entity particulars, including our registered office address and our
Corporate Identity Number, are available on request at that address. If you
ask us for them, we will give them to you. That undertaking is given to
anyone, not only to customers, and we do not ask for a reason.


2. THERE IS ALMOST NOTHING DEPLOYED FOR YOU TO TEST

Read this section before you start.

Kaleidoscope is publicly released and available. The engine is published to the
npm package registry, and it requires a key to run. It is not signed or
notarised for production distribution. There are no user accounts, no sign-in,
and no hosted product. We publish and support four platforms: macOS on Apple
Silicon, macOS on x86_64, Linux on arm64, and Linux on x86_64. Windows is not
supported, and creating a vault there is refused until that work is done.

We do run two things. There is a static documentation website, and there is
the validation service that answers the licence-key check. The website you may
inspect. The validation service you may not test — see 2.2 — and it is named
here rather than left for you to find, because a target you discover after
probing it is exactly the situation this section exists to avoid.

So the honest description of the attack surface is this. The memory engine is
a program that runs on your own machine and has no network client in it at
all. The one outbound call the product makes is a licence-key check, made by a
separate small helper program. Everything else interesting is local: files on
disk, file permissions, the contents of the local memory store, and the
boundary between the engine and that single outbound call.

2.1 What you may test

  - Your own installation of an alpha build, on a machine you own or control,
    including its files, its file permissions, and its behaviour.

  - The alpha build itself as an artifact you were given: reading it,
    disassembling it, instrumenting it, observing what it does. Section 6
    explains how this sits with the reverse-engineering restriction in the
    engine licence.

  - The entitlement helper program on your own machine, on the same terms.

  - The public documentation website, by passively browsing it and inspecting
    what it serves to your browser.

  - Anything we have told you in writing that you may test.

2.2 What you may not test

  - Any service we operate, including the endpoint the licence-key check
    contacts. Do not fuzz it, do not scan it, do not attempt to authenticate
    to it with a key that is not yours, and do not attempt to enumerate keys
    or accounts. If you believe you have found a problem in it, describe the
    problem and let us reproduce it ourselves.

  - Infrastructure belonging to other people that we happen to sit on top of:
    our hosting provider, our code-repository provider, our email provider,
    the network in between. It is not ours to authorise.

  - Anyone else's installation, machine, vault, or data.

  - Availability: no denial of service, no load or stress testing, no
    resource-exhaustion-by-volume against anything we run.

  - Our people or our premises: no social engineering, no phishing, no
    pretexting, no physical intrusion.

If you are unsure which side of that line something falls on, ask first at
contact@kleosresearch.xyz. Asking costs you nothing and we would far rather
answer the question than argue about it afterwards. Section 6.3 says what
happens if you cross the line by accident.


3. HOW TO REPORT A VULNERABILITY

Email contact@kleosresearch.xyz with "Security" in the subject line.

Do not open a public issue for a security problem, and do not post details
publicly before we have had a chance to look at it. Our public issue tracker
is for support and bug reports, and it is the wrong place for this. Sections 6
and 7 set out what we offer you and what we ask in return.

If you want to encrypt your report and we have not published a key, ask us for
one first and we will arrange a way to receive it safely.

We will not ask you to sign a non-disclosure agreement as a condition of
making a report, and we will not treat a report as confidential information
you owe us duties about merely because you sent it to us. We owe you a duty in
the other direction: what you send us is kept confidential and used to
investigate and fix the problem, as the engine licence agreement's
confidentiality clause provides.

One thing worth knowing, because it is the sort of term researchers care about
and it is usually buried. The engine licence agreement takes a broad licence
in "feedback" sent to us. A vulnerability report is not feedback for that
purpose: that clause expressly does not apply to what you send us under this
policy, and we do not take a licence in your report under it.


4. WHAT TO PUT IN A REPORT

The more of this you can give us, the faster we can act:

  - which component, and the exact version;
  - your operating system and architecture;
  - what an attacker gets out of it, and what they need in order to do it;
  - steps to reproduce, or a minimal proof of concept;
  - whether you accessed anyone else's data or any sensitive data, and what
    you did with it afterwards;
  - anything you already tried as a mitigation; and
  - how we can reach you, and whether you want to be credited.

Please do not send us raw memory stores, memory content, searches, prompts,
tokens, alpha keys, or unredacted local file paths. If demonstrating the issue
needs any of that, tell us and we will agree a safe way to hand it over. Send
the minimum that proves the point.

There is a reason we ask. A local memory store holds memory text in plain
markdown files, and every search a user runs by query text is recorded locally
alongside the answer that was served. A sample pulled from a real store is
likely to contain someone's personal data, and once you have sent it to us, we
have it.


5. WHAT TO EXPECT FROM US — BEST EFFORT, AND NO TIMELINE

We will not give you a response-time commitment, because we would not be able
to keep it and a number we cannot keep is worse than no number.

What we will do, on a best-effort basis:

  - acknowledge that we have your report;
  - tell you whether we think it is a real issue, and what we think the impact
    is;
  - keep you informed while we work on it, and answer you if you chase us;
  - tell you when it is fixed, or tell you that we have decided not to fix it
    and why; and
  - credit you if you want credit (section 7).

We are stating this plainly rather than vaguely on purpose. A policy that says
we will "aim to" respond "promptly" is read as a promise, and this is not one.
Kaleidoscope is an alpha run by a very small team. There is no rota, no
on-call, and no queue behind the address in section 1. If you have not heard
from us and you think you should have, chase us — that is not rude, it is
useful, and it is better than assuming we are ignoring you.

Because we give you no response time, section 7 gives you a date instead: if
we go silent, you are free to publish after 90 days and that is inside this
policy. A best-effort promise with no fallback would be a way of keeping you
quiet indefinitely, and it is not meant to be one.

Two clocks do exist, and neither of them is a response time owed to you. They
are reporting duties we owe to Indian authorities, and section 12 explains
them. If anything, they mean an urgent report is likely to move faster inside
our organisation than this section promises.

We do not run a bug bounty and we do not pay for reports. We say so here so
that nobody spends a weekend on the assumption that we do.


6. SAFE HARBOUR FOR GOOD-FAITH RESEARCH

We want to hear about security problems, and we do not want the fear of a
legal threat to be the reason you stay quiet.

6.1 The authorisation

If you research in good faith and within section 2.1 and section 6.2, then
your access to and use of our software for that research is authorised by us.
That is the operative sentence in this section, and it is a permission we are
giving you now rather than an assurance about how we will behave later. It
matters which of those it is: sections 43 and 66 of the Information Technology
Act, 2000 turn on whether access was made without the permission of the owner,
so our permission is a fact about your research at the time you did it, and it
does not depend on our goodwill afterwards.

On the strength of that authorisation:

  - we will not bring civil proceedings against you in connection with that
    research, and we will not make a complaint or file a first information
    report about it, or support or encourage anyone else in doing so;

  - if someone else reports you for it, we will state on the record, to them
    and to any authority that asks, that your access was authorised by us;

  - we will not treat it as a breach of the engine licence agreement, and in
    particular we will not treat it as a breach of the restriction on reverse
    engineering, to the extent the research was necessary to find, understand,
    or demonstrate the problem; and

  - if a third party brings a claim against you arising from research that
    followed this policy, we will make it publicly clear that the research was
    authorised.

6.2 What "good faith" means here

Research is in good faith and within this policy when you:

  - keep inside section 2.1 and out of section 2.2;

  - stop as soon as you have confirmed the problem, and go no further into a
    system than you need to in order to show that it is real;

  - access only the minimum data necessary to demonstrate the issue, do not
    keep or share anyone else's data, and securely delete anything you did
    come across;

  - avoid degrading, disrupting, or denying service to anyone;

  - do not extort us, and do not make disclosure conditional on payment,
    employment, or any other benefit;

  - report promptly and privately to contact@kleosresearch.xyz, and give us a
    reasonable chance to fix the problem before publishing (section 7); and

  - comply with the law.

6.3 If you cross the line by accident

Section 2.2 draws a hard boundary and real research sometimes crosses one
before the researcher realises. If you overstep it inadvertently, stop as soon
as you notice, do not go back, tell us promptly what you did and what you saw,
and delete anything you came away with — and we will treat the research as
inside section 6.1 anyway. We would rather hear about it from you than find it
in a log.

6.4 Two limits we cannot write around

We would rather say these now than have you discover them later.

We can only speak for ourselves. This authorisation covers our software and
our own systems. It cannot authorise you to test infrastructure belonging to
our hosting, repository, or email providers, or to anyone else, and it cannot
waive rights that belong to other people. That is why section 2.2 is drawn
where it is.

It cannot displace a criminal law that does not turn on our authorisation. In
India a private party does not prosecute; it complains, and the State decides.
We can decline to complain, we can state that your access was authorised, and
we can refuse to assist a prosecution. We cannot stop the State. Where an
offence requires that access was unauthorised, our authorisation goes directly
to an element of it and we will say so loudly; where an offence does not, no
promise from us can make it go away, and any policy that told you otherwise
would be lying to you.


7. COORDINATED DISCLOSURE

Give us a reasonable chance to fix a problem before you publish it. We suggest
90 days from your report as a default, and we will agree something shorter or
longer where the severity, the difficulty of the fix, or an active exploit
makes that sensible. Tell us what you intend to do and when.

If we have not given you a substantive response within 90 days of your report,
you may publish, and doing so is inside this policy and inside section 6.
Silence from us is not an instruction to keep waiting.

We will not ask you to keep quiet indefinitely about an unresolved risk to
users. If we cannot or will not fix something, we will tell you that, and we
will not treat publication after an agreed period — or after the 90 days above
— as a breach of this policy or as falling outside section 6.

If you would like credit, say so and we will name you when we publish the fix.
If you would rather not be named, we will not name you.


8. SUPPORTED VERSIONS

There is no release line yet, so there is no supported-version table yet.

We will fix security problems in the current alpha build. There is nothing
older to back-port to. Fixes reach alpha testers as a new build; there is no
automatic update channel, and nothing on your machine downloads a build on its
own.

When there is a release line, a supported-version table will be published here
and it will say how long each release is supported for.


9. THE BOUNDARIES WE CLAIM

These are the security properties we assert about the product. A demonstration
that any one of them is false is exactly the report we want, and it is a valid
report even if there is no obvious "exploit" in the traditional sense. Treat
this section as the specification you are testing against.

  - The memory engine makes no network connections. Your memory store, your
    memory content, your searches, and your results stay on your machine. The
    engine contains no network client, and a build check refuses to accept
    one: it rejects network socket types and known HTTP client libraries
    appearing anywhere in first-party source, and that rule has no exception
    mechanism. A second check independently bans those libraries as
    dependencies.

  - There is no telemetry, no analytics, and no crash reporting anywhere in
    the product. Not disabled by default — absent.

  - The only outbound call the product makes is the alpha licence-key check,
    and it is made by a separate helper program that lives outside the engine.
    The request goes to a fixed HTTPS endpoint — the helper checks that for
    itself rather than leaving it to the transport — redirects are not
    followed, and the request body contains exactly two fields: the operating
    system family and the version of the program making the call. The key
    travels in an authorisation header, not in the body. There is no code path
    that can put a third field in that body.

  - The engine starts that helper with no shell, a fixed argument list, all of
    its streams discarded, and the environment cleared and then set back to
    exactly three values: the address of our validation service, which the
    engine overwrites rather than inherits so an inherited variable cannot
    redirect the call; the verdict-cache directory the engine itself resolved;
    and the alpha key, which the helper needs in order to authenticate and
    which is passed only if the engine had it in its own environment. Nothing
    else travels — no model-provider token, no cloud credential, no path from
    the calling shell.

  - The build check above covers the engine's own source closure. The
    entitlement helper is a separate program outside that closure, so the
    check does not cover it. We are saying so rather than letting the
    unqualified claim stand: the helper is the one component that opens a
    socket, and it is therefore the component to look at if you want to test
    the network boundary. Ask us at contact@kleosresearch.xyz for its source.

  - Our validation service should reject a request that carries memory
    content, a file path, a search, a prompt, or a workspace identifier. We
    say "should" rather than "does" deliberately: that enforcement runs on our
    side and you cannot see it from the client, and section 2.2 asks you not
    to go and find out by probing it. Tell us if you have reason to think it
    does not hold.

  - The alpha key gates the service and never the data. Exactly four commands
    are gated: `serve`, `mcp`, `context`, and `call`. Inspecting, verifying,
    and migrating your own memory store are not gated, and a refusal by the
    gate does not read, write, or delete any part of your store. Note the
    shape of this honestly: because `call` carries both search and write,
    losing the key stops writing as well as retrieval. There is one ungated
    command with "export" in its name, `vault-export-device`, and it exports
    the key material for opening an encrypted vault on a second device, not
    memory content. No ungated command returns the content of your memories.

  - The alpha key file and the cached entitlement verdict must each be
    readable only by their owner on macOS and Linux. A file with looser
    permissions is refused rather than used.

  - The cached verdict stores a one-way SHA-256 digest of your key, never the
    key itself, and it is stored outside your memory store, in the operating
    system's per-user application-support location. It also carries the
    identifier we assigned to your key and that key's expiry.

  - A cached verdict that our service did not sign may deny access. It may
    never grant it.

  - Revocation is not instant, by design. Our service supplies the
    revalidation interval and the offline grace period; the engine clamps them
    when it reads the file, at 24 hours and 7 days, so an edited cache file
    cannot buy a longer window. The worst case between a key being revoked and
    the engine refusing is therefore 8 days. That is the number to quote; if
    you can make it longer, that is a finding.

  - The documentation website loads typefaces from two well-known font hosts
    and makes no other external request. It sets no cookies, runs no
    analytics, embeds no third-party script, and the only browser storage it
    uses is first-party and functional: your light/dark theme choice in local
    storage, and the navigation sidebar's open groups, scroll position, and a
    short check value in session storage.


10. OUT OF SCOPE

Unless you can show a concrete security impact:

  - unvalidated output from an automated scanner;

  - denial of service, or resource exhaustion by volume;

  - social engineering, phishing, spam, or physical attacks;

  - missing security headers, missing best practices, or configuration
    opinions with no demonstrated consequence;

  - anything that requires an attacker who already has administrator rights on
    the machine, or physical possession of it — that is outside the trust
    boundary the product claims;

  - issues in third-party software we merely depend on, which belong with that
    project; though we do want to know if we ship a vulnerable version of it;
    and

  - the observation that object code can be reverse engineered. We agree, we
    have never claimed otherwise, and section 6 says what we do about it.

Five things are known, documented, and deliberate. They are not
vulnerabilities and we do not need them reported — but a way around the stated
protection is:

  - A memory store is unencrypted by default. Memory text sits in plain
    markdown files under a directory you chose, protected by the file
    permissions of that directory. Encryption at rest exists on macOS as an
    explicit opt-in — an AES-256 encrypted disk image whose password is held
    in your login keychain, with a recovery key shown to you once. A way to
    read a store that the file permissions or the encryption should have
    prevented is very much in scope.

  - An encrypted vault's contents are readable while it is mounted, by
    anything running as your user. That is what "at rest" means and it is not
    a defect; we are listing it because section 9 invites you to falsify our
    claims and this is the obvious place to think you have.

  - Searches are recorded. Every ranked search — every search by query text —
    writes a local record containing the query, the text that was served, and
    which memories were selected. This cannot be turned off; a request to
    disable it is refused rather than quietly ignored. A read addressed to a
    single memory by its identifier is not a ranked search and writes no such
    record. All of this is disclosed in our privacy notice. If you can read
    that record without being able to read the rest of the store, tell us.

  - The engine is not signed or notarised for production distribution, and it
    is not published to any package registry. Neither is a supply-chain
    guarantee and we do not present them as one. Names have been reserved for
    us on public registries; a reserved name holds no product.

  - The build check described in section 9 reads source text, and its authors
    say plainly that it is not a syscall tracer and cannot prove that a future
    feature will have no network behaviour. Its runtime observation component
    runs only on Linux, while the only platform we have run the product on is
    macOS on Apple Silicon. It also does not cover the entitlement helper, as
    section 9 says. Evidence that the engine makes a network connection anyway
    is a very high-priority report, and the limits of the check are the reason
    we are asking you to look.


11. WHAT WE ASK YOU NOT TO PUBLISH

Nothing in section 7 stops you publishing your own research. We ask only that
you do not publish, in the window before a fix, anything that would let a
third party attack a user who cannot yet protect themselves — a working
exploit, or someone else's data you came across. After a fix, or after the
period in section 7, publish what you like.


12. IF THERE IS A BREACH

Two duties apply to us, on different clocks, and they are worth knowing about
before you report.

CERT-In. We are an Indian body corporate, and the directions of 28 April 2022
issued under section 70B(6) of the Information Technology Act, 2000 require us
to report the classes of cyber incident they list to the Indian Computer
Emergency Response Team within 6 hours of becoming aware of them. That duty is
in force today, it is owed to CERT-In and not to you, and it can be triggered
by an incident involving no personal data at all. The practical consequence
for you: if you report something to us under this policy, a report of it may
go to CERT-In within hours. We will not name you to CERT-In without your
agreement unless a direction lawfully requires us to identify the reporter,
and if that happens we will tell you that it has, unless we are forbidden to.
Those same directions also require us to keep ICT system logs for 180 days
within Indian jurisdiction, which is why some records exist for longer than we
would otherwise keep them.

Personal data. If an incident affects personal data we hold, we will notify
the affected people and the Data Protection Board of India as our privacy
notice describes, including the detailed report to the Board within 72 hours
contemplated by Rule 7 of the Digital Personal Data Protection Rules, 2025. On
the commencement notification, that duty does not begin until 13 May 2027. We
intend to follow it now rather than wait, and the obligation that binds us in
the meantime is the one under the Information Technology Act, 2000 and the
rules made under it.

For a product security incident we will publish the affected versions, the
impact, what to do about it, and which build fixes it. We will not publish
exploit detail that puts users at more risk while they are still exposed.


13. STATUS OF THIS POLICY

Apart from section 6, this policy is a description of how we handle security
reports and is not a contract: it does not create rights enforceable against
us, and it does not vary the engine licence agreement, the privacy notice, or
the support policy. Where it appears to conflict with the engine licence
agreement on a question that document governs, that document wins — except
that section 6 is intended to operate in your favour and we will not use the
licence to defeat it. The engine licence agreement says the same thing from
its side.

Section 6 is the exception. It is an authorisation, we publish it so that
researchers will act on it, we expect them to act on it, and it covers
research carried out in reliance on it while this document is a draft.

If any part of this policy is treated as having contractual effect despite the
paragraph above, that part is governed by the laws of India and the courts at
Delhi have exclusive jurisdiction over it — except that this does not oust a
forum available to a person as of statutory right. Nothing here prevents you
from bringing legal proceedings, shortens any limitation period available to
you, or purports to displace any right or remedy that Indian law does not
permit us to exclude.

We may change this policy. The version in force at the time you did your
research is the one that applies to it. If we change section 6 to your
disadvantage, that change will not apply to research already carried out.


CONTACT

    Kleos Research Private Limited
    Email: contact@kleosresearch.xyz

Full entity particulars, including our registered office address and our
Corporate Identity Number, are available on request at that address.


SOURCES RELIED ON

References for the reviewer. They are not terms of this policy.

  Information Technology Act, 2000, sections 43, 66, 70B(6) and 72A

  CERT-In directions under section 70B(6) of the Information Technology Act,
  2000, dated 28 April 2022
  https://www.cert-in.org.in/PDF/CERT-In_Directions_70B_28.04.2022.pdf

  Digital Personal Data Protection Act, 2023
  https://www.indiacode.nic.in/bitstream/123456789/20063/1/a2023-22.pdf

  Digital Personal Data Protection Rules, 2025, Rule 7 — breach intimation

  Commencement notification for the Act and Rules
  https://www.meity.gov.in/static/uploads/2025/11/c56ceae6c383460ca69577428d36828b.pdf

  Indian Contract Act, 1872, section 28 — restraint of legal proceedings
  https://www.indiacode.nic.in/bitstream/123456789/2187/2/A187209.pdf


END OF REVIEW DRAFT