Kanbrio Acceptable Use Policy

Version 1.0 · Effective 29 September 2026

Published at: https://kanbrio.com/aupOperator: [to be confirmed] (ABN [to be confirmed]) trading as Kanbrio, [to be confirmed]

Summary in plain English

This policy is part of the Kanbrio Terms of Service. It sets out what you, your team and your AI agents may and may not do with Kanbrio. If this summary and the full text disagree, the full text applies.

You are responsible for your agents. An AI agent in your workspace acts under your account. Its actions count as yours. Keep its API key secret and give each agent its own key.
Don't try to break in. Don't probe other customers' data, try to get around our tenant isolation, or attack our servers. Honest security research is welcome if you follow section 13.
Don't abuse the API or MCP endpoints. Stay within the rate limits. Slow down when we answer with 429 Too Many Requests. Don't open extra accounts or keys to get around a limit.
Don't use Kanbrio to harm anyone. That means no malware, spam, fraud, harassment, unlawful content, or attacks on third parties through webhooks, automations, the outbound MCP client or the coding executor.
The coding executor is for your own code. Only point it at repositories you are allowed to change. Don't run malware or crypto mining in it, and don't try to escape its sandbox. A person reviews its output before anything is merged.
Don't store highly sensitive data such as health records, payment card numbers or government IDs unless we have agreed to it in writing.
If you break these rules, we may warn you, remove content, switch off an agent, key, webhook or automation, or suspend or close the account. How far we go depends on how serious the breach is. Where it is safe to do so, we will tell you first and give you a chance to respond.
Report abuse or a security problem to [email protected].

1. Who this policy applies to

1.1 This Acceptable Use Policy ("Policy") forms part of the Kanbrio Terms of Service ("Terms"). Words defined in the Terms have the same meaning here. If this Policy and the Terms conflict, the Terms apply. Where this Policy is stricter, both apply.

1.2 This Policy applies to:

(a) the customer organisation that holds the Kanbrio account ("Customer", "you");
(b) every person the Customer lets use Kanbrio, whatever their role: owner, admin, member or guest ("Users");
(c) every AI agent or other automated program that connects to Kanbrio under the Customer's account ("Agents"); and
(d) anyone else using the Customer's credentials, API keys or integrations.

1.3 The Customer is responsible for making sure its Users and Agents follow this Policy. Anything an Agent does, or a person does with the Customer's credentials, is treated as done by the Customer. That applies whether or not the Customer authorised or knew about it, unless it happened because Kanbrio itself failed to protect the credential.

1.4 "Kanbrio", "we" and "us" mean [to be confirmed] trading as Kanbrio.

2. Key terms

Term	Meaning in this Policy
Service	The Kanbrio web app at app.kanbrio.com, the REST API at api.kanbrio.com, the MCP server at api.kanbrio.com/mcp, the GraphQL API, realtime connections, sign-in at auth.kanbrio.com, and every related feature
Customer Content	Anything a User or Agent puts into or creates in the Service. Examples: cards, comments, documents, attachments, labels, automations, imported data, and code or diffs produced for you
Agent API key	A secret key Kanbrio issues to one Agent so that it can act in your workspace
Automation	A rule you set up in the Service that runs actions or sends webhooks when an event happens
Webhook	An HTTP request the Service sends to an address you configure
Outbound MCP client	The feature that lets the Service call Model Context Protocol servers you register
Coding executor	The feature that takes a coding task, gets a proposed change from an AI model, checks it in an isolated sandbox, and returns a proposed change (a "diff") for a person to review
Tenant isolation	The controls that keep each Customer's data separate from every other Customer's data

3. Prohibited content

You must not use the Service to create, store, share or distribute content that:

(a) is unlawful where you are, where the people it concerns are, or in Australia;
(b) sexually exploits or endangers children, in any form;
(c) infringes someone else's intellectual property, privacy, publicity or confidentiality rights;
(d) harasses, threatens, defames or intimidates a person, or promotes violence or hatred against people because of a protected attribute;
(e) promotes or gives real-world help with terrorism, violent extremism, or making weapons capable of mass casualties (biological, chemical, nuclear or radiological);
(f) is malware, ransomware, spyware or any other code designed to damage, disrupt or gain unauthorised access to a system, unless it is inert and stored for legitimate defensive security work under section 13 or your own lawful security programme;
(g) is deceptive in a way meant to cause harm, such as phishing pages, fake invoices or impersonation of a real person or organisation; or
(h) personal information you have no lawful basis to hold or process.

4. Prohibited conduct

You must not use the Service to:

(a) break any law, regulation or court order, including laws on privacy, consumer protection, anti-spam, export control and sanctions;
(b) commit or help with fraud, money laundering, terrorism financing or sanctions evasion;
(c) send unsolicited commercial messages (spam), whether directly, through invitations, or through Automations, Webhooks or Agents;
(d) impersonate Kanbrio, another Customer or any other person, or misrepresent who is behind an account, an Agent or a message;
(e) collect personal information about other Users or Customers without their knowledge, or harvest email addresses from the Service;
(f) resell, sublicense or rent access to the Service, or run a competing hosted service on it, unless we have agreed in writing; or
(g) help, encourage or let anyone else do any of the things this Policy prohibits.

5. Security and platform integrity

5.1 Tenant isolation. Each Customer's data is kept separate from every other Customer's data. You must not try to access, read, change, infer or enumerate another Customer's data, users, identifiers or activity. This includes trying to:

(a) get around authentication, authorisation, role checks or tenant isolation;
(b) use another organisation's identifiers in requests, headers, tokens or MCP calls;
(c) exploit a bug, misconfiguration or timing gap to reach data you are not entitled to; or
(d) chain features together (for example an Automation, a Webhook and the outbound MCP client) to move data across the tenant boundary.

If you come across another Customer's data by accident, stop, don't keep or share it, and tell us straight away at [email protected].

5.2 No attacks on the Service. You must not:

(a) probe, scan or test the vulnerability of the Service except as section 13 allows;
(b) interfere with or disrupt the Service, its servers or its networks, including through denial-of-service attacks, flooding or deliberately resource-heavy requests;
(c) load-test or stress-test the Service without our written permission;
(d) introduce malware into the Service;
(e) decompile or reverse-engineer the hosted Service to find its source code or a way around its security, except where the law does not allow this to be restricted, or as a licence for published source code allows;
(f) get around or disable any security feature, rate limit, usage cap, size limit, human-approval step or audit record; or
(g) tamper with, forge or try to delete audit log entries.

5.3 Credentials. You must keep passwords, session tokens, Agent API keys, webhook signing secrets and similar credentials confidential. You must not share an account between people. Each person needs their own login and each Agent its own Agent API key. If you think a credential has leaked, revoke or rotate it in the Service straight away and tell us if other Customers could be affected.

6. API, MCP and rate limits

6.1 The REST API, GraphQL API and MCP server are part of the Service. Everything in this Policy applies to them in the same way as to the web app.

6.2 Rate limits. We limit how much traffic the Service accepts. Limits apply per organisation, per User or Agent, and per MCP tool. They also cover request size and how deeply data can be nested. When you go over a limit, the Service answers with HTTP 429 Too Many Requests (or a size error) and usually says when to retry. You must:

(a) respect 429 responses and any Retry-After value, and back off rather than retrying at once;
(b) use pagination and filters as documented instead of pulling everything over and over;
(c) not spread traffic across extra accounts, organisations, Users or Agent API keys to get around a limit; and
(d) design Agents and integrations so a loop, retry storm or runaway Agent cannot flood the Service.

6.3 Limits can change. We set rate limits to keep the Service fair and stable for everyone, and we may change them. They are not a promise of a minimum level of capacity. If you need more, contact us and we may agree higher limits for your account.

6.4 Usage caps and credits. Some Agent features use Agent Credits and may have hard caps per Agent and per workspace. You must not try to get around a cap, a credit balance or a billing control. For example, you must not open multiple free accounts to get more free usage, or change how a request is tagged so that it is not metered.

7. AI agents

7.1 You are responsible for your Agents. You choose which Agents to connect, what they can do, and what you tell them to do. You are responsible for everything your Agents do in the Service and for the content they produce, as if a User had done it.

7.2 Agents are labelled. The Service shows Agents as Agents: they carry an agent role and label, and the audit log records their actions as agent actions. You must not:

(a) make an Agent appear to be a human, or a human appear to be an Agent;
(b) hide or remove the labels that show content or an action came from an Agent; or
(c) use an Agent to deal with people outside your organisation without telling them they are dealing with an automated system, where the law requires that.

7.3 Human approval must stay in place. Some Agent actions, such as destructive ones, are held for a person to approve before they take effect. Agents cannot approve their own suggestions or those of other Agents, and cannot request erasure of personal information. You must not try to get around these controls. That includes giving an Agent a human User's session, writing an Agent that clicks "approve" through the web app, or approving in bulk without reading what you approve.

7.4 Agent API keys. Each Agent API key belongs to one Agent in one organisation. You must:

(a) keep it secret and store it securely, never in card text, comments, public repositories, logs or prompts;
(b) not share a key between Agents, organisations or people, and not sell or transfer it;
(c) revoke keys you no longer use, and revoke a key at once if you think it has been exposed; and
(d) give each Agent the narrowest permissions it needs.

7.5 No unlawful or harmful output. You must not use Agents, or any AI feature of the Service, to generate, request or publish content that section 3 prohibits, or to carry out conduct that section 4 prohibits. This covers attempts to get around the safety measures of an AI model or its provider (sometimes called "jailbreaking").

7.6 Prompt injection and manipulation. You must not plant instructions in content, attachments, repositories, webhook payloads or MCP responses in order to make another Customer's Agents, or Kanbrio's own systems, do something their operator did not intend.

7.7 Decisions about people. You must not use Agents to make decisions with legal or similarly significant effects on a person, such as hiring, firing, credit, housing or access to essential services, based only on automated processing, unless the law allows it and you provide any human review, notice and right to challenge that the law requires. Kanbrio does not make such decisions about the people in your workspace.

7.8 AI model providers' policies. When a Kanbrio feature sends content to a third-party AI model, you must also follow that provider's usage policy. For the coding executor this is Anthropic's usage policy, unless you have set your own AI provider key. In that case your agreement with your provider applies as well.

7.9 Review AI output. AI output can be wrong, incomplete, insecure or infringing. You are responsible for reviewing it before you rely on it, publish it or merge it.

7.10 Pausing and cancelling. We may pause or cancel an Agent session to enforce this Policy or to protect the Service. You can do the same. A paused or cancelled Agent stops at its next safe point, not instantly, so an action already under way may finish.

8. The coding executor

8.1 Your repositories only. You may point the coding executor only at repositories you own or are authorised to read and change. You are responsible for the repository credentials you give the Service and for any licence terms on the code in the repository.

8.2 What leaves the Service. To plan a change, the executor sends your task title and instructions and excerpts of your repository's files to our AI model provider (Anthropic, in the United States, unless you have set your own AI provider key). You must not use the executor on a repository that contains information you are not allowed to send to that provider, such as secrets, credentials, or personal or regulated data. Remove or exclude such files first.

8.3 The sandbox. Proposed changes are checked inside an isolated sandbox with no network access and with limits on memory, processes, CPU and time. You must not:

(a) run, or ask the executor to create or run, malware, crypto mining, password cracking, botnet code, or anything designed to attack another system;
(b) try to escape, break or fingerprint the sandbox or the host it runs on;
(c) try to get network access from inside the sandbox, or use the executor to reach any other system;
(d) try to use up the sandbox's resources on purpose, or run long jobs unrelated to the coding task; or
(e) try to read other Customers' tasks, repositories or results.

8.4 A person decides what gets merged. The executor returns a proposed change for review. It does not push to your repository, open a pull request, merge, or write to your main branch. A person in your organisation must review each change and decide whether to accept it. The executor cannot make that decision itself. You are responsible for anything you merge.

9. Automations, webhooks and the outbound MCP client

9.1 These features let the Service send data to addresses you choose. Those addresses are chosen by you, not by Kanbrio, and are not Kanbrio sub-processors. You are responsible for what you send and where it goes.

9.2 You must only send Webhooks and outbound MCP calls to systems you own or are authorised to use. You must not use these features to:

(a) attack, scan, flood or overload a third-party system;
(b) reach private, internal or cloud-metadata network addresses that the Service blocks by default, or try to get around that block (for example through redirects, DNS tricks or alternative address formats);
(c) send spam or unsolicited messages; or
(d) send personal information to a place where you have no lawful basis to send it.

9.3 An organisation admin can allow specific internal addresses for the outbound MCP client. Each entry widens what the Service can reach from your organisation, and it is recorded in the audit log. Only add addresses you control and have a real need to reach.

9.4 You must not register an MCP server or webhook receiver that returns content designed to manipulate Agents (see section 7.6), exploit the Service, or deliver malware.

9.5 You must not build Automations that loop, run away, or trigger each other without limit. We may disable an Automation, Webhook or MCP server registration that is causing harm or putting load on the Service.

10. Email, invitations and notifications

10.1 The Service sends email for you, such as invitations and notification digests. You must:

(a) only invite people who have a real reason to join your workspace, for example colleagues, contractors or clients you work with;
(b) not use invitations, mentions or Automations to send marketing or unsolicited messages;
(c) not invite large numbers of addresses from a purchased, scraped or rented list; and
(d) comply with anti-spam laws, including Australia's Spam Act 2003, where they apply.

10.2 If invitations from your account cause high bounce or complaint rates, we may limit or pause invitations and email from your account while we look into it.

11. Sensitive and regulated data

11.1 Kanbrio is a general work-management service. It is not designed or certified for highly sensitive data. Unless we have agreed otherwise in writing, you must not store in the Service:

(a) health or medical records, or other sensitive information as defined in the Privacy Act 1988 (Cth), or special categories of personal data under the EU or UK GDPR;
(b) payment card data covered by the PCI DSS, bank account passwords, or similar financial credentials;
(c) government-issued identifiers such as tax file numbers, passport numbers or social security numbers;
(d) personal information about children under 16 beyond what is incidental to ordinary work;
(e) information controlled under export-control or defence-security laws, or classified government information; or
(f) passwords, private keys or API secrets, other than in fields the Service provides for that purpose.

11.2 If you store such data in breach of this section, you are responsible for the consequences. We may ask you to remove it.

12. Payments and accounts

12.1 You must not:

(a) create accounts with false or stolen details, or open multiple accounts to get repeated free trials, free plans or introductory offers;
(b) use a payment method you are not authorised to use, or make a chargeback or payment dispute you know to be unfounded; or
(c) use the Service in connection with the proceeds of crime.

12.2 Payments are made through PayPal and, where offered, cryptocurrency. You must also follow PayPal's own acceptable use policy, and the rules of any crypto payment provider we offer. We may refuse or reverse a payment that we reasonably believe breaks sanctions, anti-money-laundering or counter-terrorism-financing laws.

13. Security research and responsible disclosure

13.1 We welcome good-faith security research that helps keep Kanbrio and its Customers safe. If you follow this section, we will treat your research as authorised. We will not take legal action against you or report you to law enforcement for it, and we will not suspend your account because of it. We cannot give permission on behalf of third parties such as Cloudflare, PayPal, SendGrid, DigitalOcean or Anthropic.

13.2 What is in scope: the Service at kanbrio.com, app.kanbrio.com, api.kanbrio.com (including the MCP server) and auth.kanbrio.com, tested with your own account and organisation only.

13.3 Rules for researchers. You must:

(a) test only against accounts and organisations you own, or have the owner's written permission to test;
(b) not access, change, delete or keep other Customers' data. If you reach any, stop at once, take the minimum needed to show the problem, and report it;
(c) not run denial-of-service tests, high-volume automated scanning, or anything that damages the Service or makes it slower for others;
(d) not use social engineering, phishing or physical attacks against Kanbrio, its people or its Customers;
(e) not test third-party services that Kanbrio uses, except as their own policies allow;
(f) give us a reasonable time to fix the issue before you tell anyone else. We ask for 90 days from your report, or less once a fix is released, and we will agree a date with you; and
(g) not ask for payment in exchange for not disclosing. We do not currently run a paid bug bounty.

13.4 How to report. Email [email protected] with the subject line "Security report". Include what you found, how to reproduce it, the impact you expect, and how to contact you. The current security contact is also listed at https://kanbrio.com/.well-known/security.txt and on https://kanbrio.com/security.

13.5 What we will do. We aim to confirm we have received your report within 5 business days, keep you updated while we investigate and fix it, and credit you publicly if you want us to.

14. Reporting abuse

If you believe someone is using Kanbrio in breach of this Policy, email [email protected] with as much detail as you can. Useful details are the workspace or content involved, what happened and when, and how to contact you. For complaints about personal information, email [email protected]. We may not be able to tell you what action we took, because of our obligations to the Customer concerned.

15. How we enforce this Policy

15.1 We do not routinely read Customer Content. We rely on automated controls (such as rate limits, caps, the sandbox and network blocks), on reports, and on signals from our systems and providers. When we investigate a possible breach, authorised Kanbrio staff may look at the relevant account information, audit records and Customer Content, and only as far as the investigation needs. We treat anything we see as confidential under the Terms and our Privacy Policy.

15.2 What we may do. If we reasonably believe this Policy has been breached, we may take one or more of these steps. We will choose steps proportionate to the breach:

(a) contact you and ask you to fix the problem;
(b) remove or disable access to specific content;
(c) pause, cancel or disable an Agent session, an Agent, an Agent API key, an Automation, a Webhook, an outbound MCP server registration or the coding executor for your account;
(d) lower your rate limits or usage caps;
(e) suspend a User, or suspend the account; or
(f) terminate the account under the Terms.

15.3 Notice first, where possible. We will normally tell you what the problem is and give you a reasonable chance to fix it before we suspend or terminate. We may act first and tell you afterwards where waiting would put the Service, other Customers or anyone else at risk, where the law requires it, or where the breach is serious or deliberate. Examples are active attacks, malware, child sexual abuse material, fraud, and attempts to breach tenant isolation.

15.4 Keep it narrow. Where we can, we act on the specific Agent, key, integration or User involved rather than the whole account. We restore access once the problem is fixed and the risk has gone.

15.5 Disputing a decision. If you disagree with action we have taken, email [email protected]. Explain why and include anything you want us to consider. A person will review it and reply.

15.6 Records and the law. We keep records of enforcement actions. We may preserve information and report conduct to law enforcement or regulators where the law requires it, or where we reasonably believe it is needed to prevent harm.

15.7 Fees and your legal rights. Suspension or termination for breach of this Policy is handled under the Terms and the Refund and Cancellation Policy. Nothing in this Policy limits any right you have under the Australian Consumer Law or any other law that cannot be excluded.

15.8 No waiver. If we do not act on a breach straight away, we can still act on it later.

16. Your cooperation

You agree to cooperate with reasonable requests from us to investigate a possible breach of this Policy. That includes telling us which Agent, integration or User was involved and taking steps to stop the problem.

17. Changes to this Policy

We may update this Policy. For a material change, we will give Customers at least 30 days' notice by email and in the Service before it takes effect. We may make a change with less notice where it is needed to respond to a security threat, to protect people from harm, or to comply with the law. The version number, effective date and change log are shown on this page.

18. Contact

General, abuse and security reports: [email protected]
Privacy questions and requests: [email protected]
Postal: [to be confirmed], [to be confirmed]

Change log

Version	Effective date	Changes
1.0	29 September 2026	First published version