The rule
Tawa Guard returns a decision for each scan, allow or block, with a needs_review flag on the ones the engine was unsure about. Your code acts on it. The rule we hold to is that the same input gets the same verdict on every plan, from every available engine. A plan never switches an engine off.
Some engines are listed as coming soon, and they are unavailable on every plan alike. That is why this article says every available engine.
Why it works this way
Two reasons led us to this rule, and both start from the person using the product.
The first is that detection should not depend on a team's budget. A small team without a security function has an agent that reads the same hidden instructions in a web page or a tool result as any other agent does. We charge for volume, support and platform controls, and leave the verdict alone.
The second is evaluation. A free account is where many engineers form a view of a product. If a paid plan changed the verdict, an evaluation on the free plan would measure something other than what you later buy, and a sceptical reader would be right to discount it. With one rule, a result on the Developer plan is a result on the product.
What the Developer plan includes
The free plan is a working way to evaluate Tawa Guard, and its terms are short.
- 5 million Tawa Units a month, which recurs. It is not a trial and it needs no card.
- A hard cap. A free workspace has no usage budget and no on-demand spend, so it cannot run up a bill.
- Every available engine, the full decision on every scan, the HTTP API and the Python and TypeScript SDKs.
- A dashboard and request logs.
- A 24-hour retention ceiling for stored scan text.
A Tawa Unit is one character scanned on the default engine. Other engines weight each character differently, and each scan counts as at least 100 characters, so a 20-character message counts as 100. The allowance is shared across all the workspaces one account holder owns, so creating more workspaces does not multiply it.
For scale, a 2,000-character document draws 2,000 Tawa Units on the default engine, and the allowance covers 2,500 of them a month. A message of 100 characters or fewer draws 100, and the allowance covers 50,000 of those.
What plans do differ on
Paid plans add reach, volume and platform controls. They also show more of the working behind each decision. None of these changes the verdict.
- Protected apps. Each plan sets how many apps a workspace can protect.
- Included volume. Each paid plan includes its own monthly allowance of Tawa Units. Beyond that, a paid workspace can draw on a usage budget, a spend cap you set, so nothing reaches an invoice that you did not choose.
- Platform controls. Detection runs on every plan, and so does the redaction Tawa applies to text it stores itself. Paid plans add the choice of what happens to each source: off, flag, redact or block. PII handling for knowledge buckets starts on the first paid plan, and custom rules with version history are on paid plans too. The Team plan adds the audit log, and the Business and Enterprise plans add SIEM export, the Analytics API and backtesting a rule against recorded traffic.
- Retention ceilings. The ceiling on how long a workspace can keep scan text is 24 hours on Developer and longer on each step up, with a negotiated figure on the largest plan. An app can choose any shorter period than its ceiling.
- Scan detail. The next section covers this one.
Scan detail: how much of the analysis you can see
Scan detail comes in three bands. The bands control what you can read after a scan. The scan and its result stay the same.
| Band | What you see | Developer | Paid plans |
|---|---|---|---|
| Decision | The risk score, the certainty and the decision with its review flag | Yes | Yes |
| Evidence | The detector signals behind the decision, the rule or profile that acted and what it matched, and the flagged spans highlighted in your own input | No | From Starter |
| Forensics | The analysis path, the phrasing analysis and the raw engine result | No | From Team |
A Developer workspace receives the same decision as a paid workspace and reads the answer without the working. The limit is on visibility, and your code receives the same decision either way.
A rule you can test
A commitment is worth more when you can check it, and this one is easy to check.
- Create a free workspace. There is no card to enter.
- Send a sample of your own traffic through the API in the shape your app sends it: user input, tool output, retrieved documents.
- Record the decision for each input and compare it with your own labels or with whatever you use today.
- If you later try a paid workspace, send the same inputs on the same engine and the same settings. The decisions should match, and the paid workspace adds the evidence.
Compare workspaces on the same settings. A workspace that has written its own rules or set per-source actions has asked for different behaviour, and those choices act on top of the detection result. If the same input returns different decisions on the same engine and settings, tell us.
What the rule covers
The rule covers consistency between plans. No detector catches every injection, and our Terms say so. Tawa Guard returns a decision, and your code decides what to do with it. The free plan lets you measure how often that decision is right for your traffic before you spend anything, and the same inputs return the same decisions on a paid plan.