Every change to our security posture, our subprocessor register, and these documents, with the date it happened. Subprocessor changes are notified here, so this page is the mechanism behind the notice term in your data processing agreement, not a marketing blog.
How this register works
Entries are appended, never rewritten. If something we published turns out to be wrong, the correction is a new entry that says so rather than a quiet edit, the same way removals are logged on our receipts page. Every entry says what changed and what, if anything, you need to do.
General
The agent register is now published by stage, not by agent
The models and agents page used to list every agent by name with the model it runs. It no longer does. The list mirrored a file in the platform repository that changes roughly weekly, so keeping it true depended on someone editing a different repository remembering this page existed, and a trust page that silently falls behind its source is worth less than one that never claimed the detail. What replaces it is durable and answers the same question better: each stage of a run, whether it reads free-form content you supplied, and the guardrail profile that classification selects. Nothing about how the agents work has changed, and nothing that was true is now unsaid.
General
The trust center is now public
Security questions, the subprocessor register, and the vulnerability disclosure policy are published and ungated. Previously the only route to this detail was requesting the system description. That document still exists and still answers more, but you should not need it to answer a questionnaire.
Security
Correction: Bedrock Guardrails are not enforcing
This site previously stated that Amazon Bedrock Guardrails ran on agent traffic with PII blocking and prompt-injection detection. That was wrong. The guardrails are built and versioned but switched off in every environment, production included, while support cases with AWS are open. The claim has been corrected wherever it appeared. Carrying that surface meanwhile: retrieval is scoped to your tenant, agents run least-privilege and are invoked only by the API, and agent output is validated at the API layer. Re-enabling them will be posted here.
Security
Vulnerability disclosure policy published, with safe harbor
Good-faith security research that follows the policy is authorized, and we will not bring or support a civil claim over it. The policy sets out what is in and out of scope, notably that customer tenants and applications deployed into a customer's own cloud account are not ours to authorize, and what we commit to in return: acknowledgement within 3 business days, an assessment within 10, updates every 14. security.txt now points at it.
Subprocessor
Subprocessor register published, and Microsoft added
The current subprocessor list is now public rather than only an annex to the data processing agreement. Microsoft appears on it for the first time, covering the optional Microsoft Entra ID single sign-on a customer can enable: sign-in claims transit the federation broker and are not stored in Taiga's own Entra tenant. If your organization does not use Entra single sign-on, nothing changed for you. Objections follow the notice terms in your agreement.
General
Terms, platform terms, and the acceptable use policy published
The website terms of use, platform terms, platform privacy statement, and acceptable use policy are now published. The platform documents are subordinate to your signed agreement and apply only where it is silent; they do not amend anything you have signed.
Customers are notified through the contact named in their agreement; the feed is in addition to that, not instead of it. To add a recipient, write to hello@tai.ga
This register is the source. Entries are appended and dated; nothing here is edited after publication.