simse Acceptable Use Policy

Effective date: 20 September 2026

Revised 28 September 2026 — Section 3: the function-invocation quota now counts the invocations of the current calendar month and starts again from zero on the first day of each month (UTC). It had counted every invocation over the life of an account without resetting.

Revised 27 September 2026 — generation has been served since 15 September 2026, so Section 1.3 now states that every generation request is sent to Anthropic, in place of the statement that generation was not yet served. Section 3 now states that the included allowance and the spending cap are weekly; that the quota checks run when you save a memory, when you create a schedule and each time a schedule runs, and that no plan sets either quota today; and that scribe's approval prompt can be switched off. Section 5.1 no longer lists reducing your rate limits as a remedy: rate limits are the same for every account. Section 3 also names the function-invocation quota each plan sets, which counts over the life of an account, and says that the quota checks refuse, where the billing check does not, when our usage service cannot answer.

This policy is what you may not do with simse. It applies to the app at simse.dev, the developer portal at platform.simse.dev, the API at api.simse.dev, and the scribe command-line tool.

It is part of the Terms of Service. Breaking it is a breach of that agreement, and Section 5 below says what we do about it.

Schedule A — Entity particulars

These are the only blanks in this document. Everything else is decided. Fill them in at publication and delete the bracket markers.

Wherever this policy says "we", "us", "our" or "simse", it means the entity named at A-1. simse is a product of Telor.

1. Who this applies to

1.1 It applies to you, to anyone using your account or your API keys, and to the users of any application you build on simse. You are responsible for their compliance as if it were your own.

1.2 It applies to what you send us and to what you do with what we send back.

1.3 The model provider's rules apply too. Generation has been served since 15 September 2026, and every generation request you make is transmitted to a third-party model provider, Anthropic. Their published usage policies apply to your use of simse, on top of this one. Where their rules are stricter, theirs govern.

2. Do not do these things

2.1 Illegal activity and harm to people

You may not use simse to:

• do anything illegal where you are, where we are, or where the affected person is;
• create, request, refine or distribute child sexual abuse material, or sexualised content involving minors of any kind;
• create or distribute non-consensual intimate imagery, or sexual content depicting a real person without their consent;
• plan, promote, facilitate or provide operational assistance for violence, terrorism, or violent extremism;
• design, acquire or deploy weapons, including chemical, biological, radiological, nuclear or high-yield explosive capability;
• harass, stalk, threaten, defame or incite hatred against a person or a group;
• encourage or provide instructions for suicide, self-harm or disordered eating;
• traffic in people, drugs, weapons, endangered species, stolen data or stolen goods; or
• generate content that sexualises, exploits or endangers a child in any way.

2.2 Attacks on simse and on other systems

You may not:

• probe, scan or test the security of simse except as the testing rules in Section 4 of this policy permit, and never against an account that is not yours;
• attempt to access another user's account, data, session, workspace, memories, files or conversations;
• attempt to extract system prompts, internal instructions, credentials or configuration, or to reverse-engineer how the platform routes and serves requests;
• inject instructions into content — a web page, a repository, a document, a tool result, a connector response — intended to make another user's agent act against that user;
• use simse to generate, refine, host or distribute malware, ransomware, exploits, credential stealers, botnets, phishing kits or fraudulent websites;
• use an agent, sandbox or connector as a relay, proxy, scanner or staging point for an attack on a third party, or to reach a network you are not authorised to reach;
• run any tool against a system you do not own or have written permission to test; or
• interfere with the operation of simse, degrade it for others, or attempt to circumvent a security control, sandbox boundary or network restriction.

2.3 Abuse of capacity and of billing

You may not:

• share your account, sign-in link or API keys, or let anyone else use your allowance;
• create accounts automatically, create multiple accounts to obtain more free allowance, or re-register after we close your account;
• circumvent, or attempt to circumvent, a rate limit, concurrency limit, quota, spending cap or plan restriction;
• resell, sublicense, proxy or otherwise make raw model access available to third parties as a substitute for them buying it — building a product that uses simse is fine, standing up a passthrough to the model is not;
• use the service to generate output for the purpose of training, fine-tuning, distilling or benchmarking a competing model or a competing service;
• scrape or bulk-extract the service, its documentation, or its API surface by any means other than the published API; or
• use simse to send bulk unsolicited messages, or to generate content for a spam, scam or engagement-farming operation.

2.4 Other people's data and other people's rights

You may not:

• upload or prompt with someone else's personal data unless you have a lawful basis to do so and are entitled to have it processed as the Privacy Policy describes — including transmission to the model provider in the United States;
• upload special-category data — health, biometric, genetic, racial or ethnic origin, political opinions, religious belief, sex life or sexual orientation, trade-union membership — or government identifiers, or children's data. We do not ask for it and have no use for it. Our automated redaction is pattern-matching, not judgement, and will not reliably catch it;
• upload payment card numbers, banking credentials or health records;
• upload content you do not have the rights to, or use simse to infringe a copyright, trade mark, patent, trade secret or right of publicity;
• use simse to build a facial-recognition database by untargeted scraping, or to infer a person's emotions in a workplace or educational setting; or
• use simse for biometric categorisation of people by race, political opinion, trade-union membership, religion, sex life or sexual orientation.

Do not paste secrets. If you paste an API key, a private key or a password into a prompt, treat it as disclosed and rotate it. Our redaction runs after the content has already been sent to the model provider.

2.5 What you may not do with the output

You may not:

• present AI-generated content as written by a human where that would deceive someone, and where the law requires disclosure of AI-generated text — including text published to inform the public on matters of public interest — you must make that disclosure yourself;
• impersonate a real person or organisation, generate a fake endorsement, testimonial, review or official statement, or produce a synthetic likeness or voice of a real person without their consent;
• remove, alter, obscure or defeat the markings that identify a response as machine-generated — the role field, which the generation endpoints set on every response carrying generated content, and the turn labelling in the interface. The group-room surface is the exception: it streams generated content as its own event frames, which carry the speaker rather than a role field. role is the marking; the model field is not one, and we do not ask you to treat it as one — it repeats back the model name your request sent, unchanged, so it says nothing about what produced the content. It is also absent in places: a turn stored before we recorded it carries none, and the group-room surface carries no model field at all, live or replayed. A missing model means unknown, never human-written;
• generate election disinformation, fabricated news, or content designed to suppress or manipulate voting;
• use output as the operative basis for a decision that produces a legal or similarly significant effect on a person — employment, credit, insurance, housing, education, healthcare, benefits, immigration, or law enforcement — without a competent human reviewing and taking responsibility for that decision;
• present output as professional advice, or hold simse out as a lawyer, doctor, accountant, therapist or financial adviser; or
• deploy simse into a use classified as high-risk or prohibited under the EU AI Act, or into a regulated context — medical devices, safety components, critical infrastructure — without doing the compliance work that falls on you as the deployer. simse is supplied as a general-purpose tool and carries no conformity assessment for any such use.

2.6 Agents, tools and connectors

Agent runs execute real commands and reach real networks. Where simse runs an agent for you on our servers, tool calls are not gated by an approval prompt — they run, and you see the result afterwards.

You may not:

• point an agent at a system, repository, account or network you are not authorised to act on;
• give an agent a credential you are not entitled to use;
• install, author or distribute a plugin, connector, agent or workflow that does anything this policy forbids, that exfiltrates data, or that misrepresents what it does;
• use a scheduled or automated run to defeat a rate limit or to sustain load we have asked you to reduce; or
• use the sandbox to mine cryptocurrency, to run a public service, or for any workload unrelated to your use of simse.

2.7 What simse is for, and when building on it makes you the provider

This section is not a list of prohibitions. It states what simse is intended for, and what follows under the EU AI Act if you build something else out of it. Read it before you ship anything that makes decisions about people.

2.7.1 The intended purpose. simse is a general-purpose AI assistant and developer platform. It is intended for conversational assistance, drafting and editing text and code, summarising and answering questions over material you supply, retrieval over your own documents, and running agentic tool workflows that you direct. That is the whole of it.

simse is not intended for, designed for, validated for, or supplied for any use listed in Annex III of the EU AI Act — among them employment and worker management, education and vocational training, access to essential private or public services, creditworthiness and credit scoring, risk assessment and pricing in life and health insurance, biometric identification or categorisation, emotion inference, law enforcement, migration, asylum and border control, and the administration of justice and democratic processes. We have carried out no conformity assessment for any of them, and we supply no technical documentation, no registration and no post-market monitoring that such a use would need.

2.7.2 If you repurpose simse into a high-risk use, you become its provider. Article 25 of the EU AI Act is explicit about this. Where you put your own name or trade mark on a high-risk system built on simse, make a substantial modification to one, or modify the intended purpose of a general-purpose AI system that we have not classified as high-risk so that it becomes high-risk, you are considered the provider of that high-risk system for the purposes of the Regulation. We are not.

Being the provider is not a label. It carries the provider's obligations in full — a risk management system, data governance, technical documentation, logging, transparency to deployers, human oversight, accuracy, robustness and cybersecurity, a quality management system, conformity assessment, the CE marking, registration in the EU database, and post-market monitoring and incident reporting. Those obligations land on you, and they land on you whether or not you realised the repurposing crossed the line.

The test in Art. 25 is measured against the intended purpose we have stated, which is why §2.7.1 states it plainly. If you go outside it into an Annex III use, that is your decision and your role change, not a shared one.

2.7.3 What we ask of you. If you intend to build an Annex III use on simse, do not treat this policy as permission and do not treat our general-purpose framing as cover. Do the provider's work before you deploy, or do not deploy. Tell us at legal@telor.dev if you need to understand what simse does and does not do in order to complete your own documentation — we will answer factually about the platform, and answering does not make us a provider of your system or transfer any part of your obligations to us.

2.7.4 This is separate from the deployer bullet in §2.5. That bullet is about deploying into a high-risk or regulated context and the compliance work that falls on a deployer. This section is about becoming the provider by changing what the system is for. They are different roles under the Regulation with different duties, and you can be caught by both at once.

3. What we monitor, and what we do not

We say this plainly because the answer matters to you.

We do not read your conversations to police them. There is no classifier scanning your prompts or the model's replies for policy violations, and no human reviews your content as a matter of routine.

What actually exists is a small set of controls that run for safety and billing, not for surveillance:

• Rate limits are enforced on every request, and so is your billing position: before a generation runs we ask whether the week's included usage is spent with extra usage switched off, whether the week's spending cap has been reached, or whether there is no credit to charge, and the request is refused up front where it is. A quota is a different thing — a cap on a kind of resource. Three are checked: a saved memory when you save it, a schedule when you create it and each time it runs, and a function each time it is invoked, by an agent or by a schedule. No plan sets a memory or schedule quota today. Each plan does set a function-invocation quota — 50 on Free, 2,500 on Plus, 10,000 on Pro and 100,000 on Max — and it counts the invocations made in the current calendar month, starting again from zero at 00:00 UTC on the first day of each month; an invocation past it is refused until then. Unlike the billing check, these checks refuse when our usage service cannot answer: saving the memory or creating the schedule fails, and a scheduled run that falls in that window is skipped and not run later. Two limits on the billing check are worth stating plainly: where our usage service cannot answer in time the request is served rather than refused, and usage for served work is still metered after the response, so a cap is not an exact ceiling and a small amount of work can be served past it — Section 4.2 of the Terms says the same thing. One narrow kind of request is checked more heavily than the rest. A request that declares local execution — where the agent loop runs against a runner on your own machine through our tunnel — reserves a bounded amount of credit before that loop starts and is refused outright if the reservation is declined, because the loop can spend many turns without returning to you first. That reservation is released rather than recorded when the loop ends, so unlike the metering above there is no durable entry for it. Where the refusal is a metering one we record it against your account, along with the work that was served and not charged for.
• Agent execution is sandboxed. Tool commands run in an isolated virtual machine, and where that machine cannot be provisioned the command is refused at that point rather than run outside it — there is no path that falls back to running a tool command on an ordinary host. No customer session has yet run through that boundary, so it is a control that is in place rather than one with an operating record behind it, and we would rather say so than let you read an operating record into it. Its network egress is default-deny, and the policy is enforced on the host, outside the virtual machine, so code running inside it cannot switch the policy off. What that policy allows is coarse: DNS, and outbound HTTP and HTTPS to the public internet. There is no per-host allow or deny list on it, and nothing inspects the hostname inside an encrypted connection. Separately, and before the request leaves our servers, the agent's own web-fetch tool resolves the destination and refuses the request if any resolved address is internal, loopback, link-local or a cloud-metadata address. That check sits on the tool, not on the sandbox's network. A command the agent runs is therefore a way your content can leave us, and it is enumerated as such: Section 5.5 of the Privacy Policy and Section 3.4 of the AI Transparency Notice list it beside the model provider, the web tools and connectors, and Annex III section B of the Data Processing Agreement records why the host it reaches is not a sub-processor of ours.
• A deny-list refuses destructive shell commands before they run — where we run the agent. On our servers, a shell command the agent proposes is matched against a pre-execution deny-list (rm -rf /, fork bombs, writing over a raw disk and the like) and refused before it reaches the sandbox. That list does not sit under every path, and we would rather say so. On your own machine the control is the approval prompt instead — by default scribe asks before it runs a shell command, unless you have set it not to ask (Section 2.4 of the Terms of Service), and an unattended invocation refuses rather than proceeding without an answer — and a command sent to the remote daemon over the dashboard channel runs as issued, with neither the prompt nor the deny-list. Git has no gate of its own. A git command is an ordinary shell command and gets whatever the path it runs on gives it — the deny-list on our servers, the approval prompt on yours — and that deny-list contains no git rule. The git sandbox settings in your account, including blocked remotes and protected refs, are stored and shown back to you; nothing enforces them today.
• Automated redaction replaces detected credentials and detected personal-data patterns with [REDACTED] in the records we store — the analytics warehouse rows, the retrieval index and the full record of each AI exchange. It does not run on what is streamed back to you, and it does not run on what we send to the model provider: neither of those is scanned or rewritten. It is pattern-matching. It is not a guarantee.
• An append-only security and authentication log records sign-ins, account actions and the originating IP address.
• Feature flags let us disable a surface for everyone.

We act on what those controls surface, on what a report tells us, and on what a law-enforcement or regulatory demand requires. If we need to investigate a specific account for a specific reason — an abuse report, a security incident, a legal obligation — we may access the content necessary to do it. We keep no log of that access, and we would rather say so than let you assume one exists. There is no admin or support console that exposes your content: reaching it takes direct operator access to the store the content sits in — the production database for your conversations and records, the file store on our own servers for the files you upload, and the analytics warehouse, which holds the full record of each AI exchange described above. The trails we do keep record actions taken on an account — sign-ins, key and device changes, an administrative suspension — and the Kubernetes API server keeps a 30-day record of infrastructure calls. Neither records an operator reading a specific account's stored content, so we cannot show you an entry for it.

4. Reporting a violation

Abuse reports. Tell us what you saw, where you saw it, and when. We acknowledge within 5 business days.

Security reports. Send them to security@telor.dev. We acknowledge within 2 business days and triage within 5. Our default coordinated-disclosure window is 90 days from that acknowledgement, or until a fix is deployed, whichever comes first. We do not run a paid bug bounty. We credit researchers who want it.

Rules of engagement. These are the rules, in full, so that you do not have to go and find them somewhere else:

1. Test only against simse.dev, platform.simse.dev, api.simse.dev and the scribe client, and only as far as you need to go to demonstrate the issue.
2. Use only your own account. Do not access, alter or keep anyone else's data. If you find a bug that crosses between accounts, prove it with two accounts you control and stop at proof.
3. Stop at proof of concept. Do not pivot, escalate, persist, or take more than the minimum needed to show impact.
4. No denial-of-service, volumetric, brute-force or automated stress testing. Throttle your tools.
5. Do not exfiltrate, store or share personal data. If you come across someone else's data by accident, stop, do not keep it, and say so in your report.
6. Do not disclose publicly before the window closes, and not at all if disclosure would put users at risk.
7. Report it to us and to no one else. No extortion, no payment demanded as a condition of disclosure, no trading the finding.
8. Obey the law where you are. Nothing here authorises anything that is illegal there.

What you get for following them. Research conducted in good faith within those rules is authorised by us. We will not bring a civil claim against you over it, we will not report you to law enforcement over it, we will not treat it as a breach of this policy or of the Terms — we waive Section 2.2 to that extent — and if a third party comes after you for it, we will take reasonable steps to make it known that you were authorised. This covers your conduct towards us only. It does not bind our service providers or anyone else, so do not test them. If you are not sure whether something is in scope, ask at security@telor.dev before you do it. Testing outside these rules is outside the authorisation, and Section 2.2 applies to it in full.

Copyright complaints. Our designated agent to receive notices of claimed infringement under 17 U.S.C. §512(c)(2) is:

____________________ (A-1), Copyright Agent ____________________ (A-2) ____________________ (A-6) legal@telor.dev

Send the notice to that agent, identifying the copyrighted work, the material you say infringes it and where on simse it is, your contact details, a statement that you believe in good faith the use is not authorised by the owner, its agent or the law, a statement that the notice is accurate and that under penalty of perjury you are authorised to act for the owner, and your physical or electronic signature. We will act on a valid notice and will pass it to the account holder, who may send us a counter-notice containing the elements 17 U.S.C. §512(g)(3) requires; if they do, we will forward it to you and may restore the material after 10 business days unless you tell us you have filed suit.

Repeat infringers. We have adopted, and we enforce, a policy of terminating in appropriate circumstances the accounts of users who repeatedly infringe copyright. Section 5 is how that runs. A termination on that ground is a termination for breach, not for our convenience, so Section 5.4 applies to it.

Do not use these addresses to report a fault in generated content as an abuse matter — that is support@telor.dev.

5. What we do when the rules are broken

5.1 We respond in proportion to what happened, how much harm it caused or risked, and whether it has happened before. Depending on that we may:

• refuse extra usage;
• disable a specific feature, plugin, connector, agent, workflow or API key;
• remove or block access to specific content;
• suspend your account, in whole or in part;
• terminate your account and this agreement; and
• where the law requires it, or where there is a risk to someone's life or safety, report the matter to law enforcement and preserve or disclose the relevant records.

5.2 We act immediately, without prior notice, where the circumstances require it — content under Section 2.1, an active attack, a compromised account, or a legal demand. Otherwise we tell you what the problem is and give you a chance to fix it.

5.3 We aim to keep any suspension no broader and no longer than the problem requires, and to tell you what it was for.

5.4 Termination for breaking this policy is not a termination for our convenience, so the refund in Section 4.6 of the Terms of Service does not apply to it. Prepaid credits are forfeited.

5.5 Appeals. If you think we got it wrong, reply to the notice we sent or write to legal@telor.dev within 30 days. Tell us what you think we misread. A person will look at it, and we will answer within 30 days. Where a suspension was a mistake, we lift it and restore your access.

6. Changes to this policy

We may change this policy. The current version is always at simse.dev/legal/usage. For a change that is material and adverse to you, we give at least 30 days' notice by email or in-product before it takes effect, on the same terms as Section 17 of the Terms of Service.

simse is a product of Telor. Questions about this document: legal@telor.dev.