Trust

Trust Policy

Effective date: 19 September 2026 · Venture Group AI

Trust is earned by what we publish, label, and prove — not by what we promise. These are the commitments we hold ourselves to on every page of this site and every feature of the platform.

Honesty over hype

GuardBotAI is a human-made product that uses AI. We say clearly what is live, what is in demonstration, and what is planned. Features that are not yet in production are labeled as demonstrations — never presented as active protection.

We do not claim certifications, customer results, or detection rates we cannot evidence. If we cannot prove it, we do not publish it.

How we build

The platform is engineered with tenant isolation between customer organizations, server-side verification of payments and identity, rate limiting and bot protection on public endpoints, and tamper-evident records of security decisions.

Security work follows recognized public frameworks — the OWASP guidance for LLM and agentic applications among them — and we run recurring internal security and trust reviews of our own site and systems.

What we will tell you

If something goes wrong that affects your data or your service, we will tell you promptly and plainly, and tell you what we are doing about it.

Our assistant, GuardBot (GB), answers questions from approved product documentation and links to its sources. It does not make security decisions about your systems, and it never asks for passwords, API keys, or card details.

What we expect in return

Use GuardBotAI only on systems you own or are authorized to test. Report vulnerabilities to us responsibly via the contact page — we will acknowledge and investigate genuine reports.

Security practices in place today

Each practice below exists in the running product and has been exercised against the live gateway. We list nothing here that we cannot demonstrate on request.

Every request through the gateway is checked before anything is forwarded

Each call is evaluated server-side against the account's own policy — prompt-injection and jailbreak patterns, owner-defined blocked phrases, permitted tool list, and size limits. In enforce mode a blocking decision refuses the request outright; nothing reaches a model. New GuardBots start in sandbox, where requests are checked and recorded but never forwarded at all.

Security records are tamper-evident and append-only

Every gateway decision is written to a chained record: each entry carries a hash of the decision plus the hash of the entry before it, so removing or altering a record breaks the chain. Key creation and revocation, enforcement changes, containment, sandbox graduation, and sensor registration are written to an audit trail that cannot be edited or deleted from the application.

Customer data is isolated account by account

Every table enforces row-level access scoped to organisation membership, and the gateway derives the owning account from the presented key rather than from anything the caller sends. A key from one account cannot read, change, or route another account's projects, policies, events, or usage.

Secrets are stripped, not stored

Credentials and API keys detected in a prompt are removed before the request is forwarded, and event records hold only a hash of the request plus, where a policy requires it, a redacted excerpt. Raw prompts and secrets are never written to the event trail.

The gateway fails closed

If identity, policy evaluation, quota, or the record write cannot be completed, the request is refused rather than forwarded. Emergency containment refuses all traffic for a project instantly, and a burst of blocked requests or a sudden traffic spike automatically returns a project to sandbox.

Public endpoints are rate-limited and bot-protected

Contact and enterprise quote forms verify a Cloudflare Turnstile token server-side, apply per-IP and per-email rate limits, and carry a honeypot field. The gateway throttles per IP before any database work and again per project.

Certification roadmap

GuardBotAI holds no external security certification today and claims none. A SOC 2 Type II audit is planned after launch, beginning with a readiness assessment against the Security and Availability criteria; the observation window and the report date will be published on this page once the audit engagement starts. Until a report exists, treat the practices above — not a badge — as the evidence.

Where the proof lives

These commitments are checkable, not decorative. Our public security status page carries every security incident we publish, with its severity, timeline, impact, and resolution, alongside the controls that exist in the running product today and a plain list of what we do not yet claim. Inside a customer account, every security-affecting action — key creation and revocation, enforcement changes, emergency containment, sensor registration and revocation — is written to a permanent record that cannot be edited or deleted from the application.