Trust & security

Your systems stay yours.
You approve every action.

This page describes how the platform behind your AI staff actually works: where your credentials sit, who can read what, what gets written down, and why nothing reaches a customer without a person saying yes.

Book a free discovery callSee how it works
Approvals · Brisbane Realty GroupNothing sent yet
  • Reply to Tom · drafted, not sentNeeds you
  • Booking · Thursday 10:30 · heldNeeds you
  • Approved by Sarah, then sentDone
  • Sent without a person approvingNone
On the record
  • Who approved it
  • What the draft said
  • When it happened

Most security pages are a list of badges. This one is a list of things that are true about the software, written so you can ask us to show you each one.

So, plainly: there are no badges, logos or third-party seals anywhere on this page. We have not earned any, and printing one we had not earned would be the least trustworthy thing on the site. What we can do instead is describe exactly how the platform is built and how your access is handled, in language you can hold us to, and answer any question about it directly.

Everything below is a description of behaviour that is in the product today. If something changes, this page changes with it.

How your work is actually handled

Six areas, and what is true in each. No adjectives doing a fact’s job.

A human in the loop

The approval gate, and the one setting that could move it.

  • Propose first, act second

    Every agent we build is created in draft-for-approval mode. It writes the email, holds the slot, prepares the record change, then stops and waits.

  • Anything that leaves the platform raises an approval

    When an agent’s work would change something outside the platform, its run is parked as “needs approval” and the draft appears in an approvals inbox for a person on your side.

  • Approve or reject, with a note

    Each decision is written against the person who made it and the exact item they decided. Reject, and the draft simply sits there: nothing is sent, booked or changed.

  • Autonomy is a per-agent setting, never a default

    The only way an action skips the queue is an agent deliberately marked autonomous. Our build crew is instructed never to create one, and we do not switch it on for anything that reaches your customers.

  • Silence is not a yes

    An approval nobody decides stays pending. Nothing times out into being sent, and nothing is sent because the queue got long.

Your accounts and your credentials

Connected per client, held as a reference, revocable by you.

  • Connected per client, through the provider

    A Google connection is made for one organisation at a time, through Google’s own consent screen. The account stays in your name; we are granted access to it, we do not hold it.

  • The platform stores a reference, not the secret

    The token from the provider goes into the database’s encrypted secret store. The application’s own table keeps only a pointer to it, and that pointer is readable only by server-side code.

  • Never sent to a browser

    No page in the operator dashboard or the client portal renders a stored credential, and nothing in the browser can request one; reading it is a server-side operation with a key that only the server holds.

  • Not part of what an agent is given

    An agent run is handed its instructions, its input and the list of tools it may describe using. Credentials are not in that payload.

  • You can revoke without asking us

    Remove our access from your own Google or CRM account at any time and the connection stops working immediately. Disconnecting from our side deletes the stored secret and marks the connection revoked.

Separation between clients

One organisation per record, enforced by the database.

  • Every record belongs to one organisation

    Intakes, plans, solutions, runs, approvals, connections and audit entries all carry the organisation they belong to, so every record has exactly one owner. Client work is never pooled into a shared table.

  • Row-level security does the scoping, not the screen

    Reads and writes are limited to your own organisation’s rows by the database itself, so a mistake in a page cannot show you another client’s data.

  • Roles decide what an operator sees

    There are four roles: super admin, operator, client admin and client member. Staff pages require a staff role, portal pages require a client account attached to an organisation, and anyone in the wrong place is redirected rather than shown the page.

  • The few privileged writes are checked twice

    Where a write has to run with elevated rights (deciding an approval, for instance), the code re-checks that the person is entitled to that record, and pins every follow-on write to the same organisation.

  • Signing in is a one-time email link

    There is no password to guess, reuse or leak: you enter your email address and follow the link we send.

An audit trail

Written once, readable afterwards, redacted on the way in.

  • Material actions are written down

    Approvals decided, connections made and revoked, versions deployed and rolled back, agent runs started and finished: each becomes an entry naming the actor, the action, the record it acted on and the time.

  • The log is insert-only

    The platform has no code path that edits or deletes an audit entry. Entries can be read and filtered; they cannot be rewritten from anywhere in the product.

  • Every agent run is its own record

    Each run stores what went in, what came out, whether it succeeded, how many tokens it used and what it cost, for sandbox runs and live runs alike.

  • Secrets are stripped before anything is stored

    Audit metadata passes through the same redaction helper as our logs, so a value that looks like a token or a key is replaced before it is written.

Testing before anything is real

Sandbox, verdict, then your go-live decision.

  • Sandbox runs are marked as sandbox

    A test run is flagged in the database, told in its own instructions that nothing it proposes will be executed, and never raises a real approval. It works on test data, not on your customers.

  • A QA reviewer writes a verdict

    Before anything moves on, a reviewer reads the build, the plan you approved and the most recent sandbox runs, then records a pass-or-fail verdict as a run of its own, so it sits in the same history you can read back.

  • Go-live needs your approval of that exact version

    Deployment refuses to proceed unless the client has approved go-live for the version being deployed. An approval of an earlier version does not carry forward to a new one.

  • Live is reversible

    A previous version can be made live again, and a solution can be paused so its agents stop running. Both are recorded like any other material action.

Secrets hygiene

Out of the codebase, out of the logs.

  • Platform secrets live in environment variables

    API keys and signing secrets are read from the environment at run time. The file committed to the repository lists the names, with every secret value blank.

  • The privileged database key is server-only

    The key that can bypass row-level security is imported in a module that cannot be pulled into a browser bundle. Everyday reads and writes use the ordinary key, under row-level security.

  • A redaction helper keeps values out of the logs

    Before a payload is logged, keys that look like a token, password, credential or API key have their values replaced with “[redacted]”, all the way down through nested objects.

  • Per-client webhook secrets are derived, not stored

    Each organisation’s inbound webhook signing secret is derived from a single platform secret when it is needed, so no per-client secret sits in the database waiting to leak.

What we ask of you

Three habits on your side do more for the safety of this arrangement than anything we can build on ours.

  • Grant the narrowest access that does the job

    If the work only needs a calendar, connect the calendar. We would rather ask you for one more permission later than hold access nobody is using.

  • Keep one owner who reads the approvals inbox

    Approvals are quick, but they are not optional: the gate only protects you if a person on your side is actually standing at it. One named owner works better than a shared responsibility.

  • Tell us when someone leaves

    Send us a note when a person with an account or an approver role moves on, so their access can be revoked the same day rather than at the next review.

Questions about security?

Ask us anything on this page and we will answer it as specifically as it was asked, including the parts where the answer is “not yet”. If your business needs something written down before it can work with us, tell us what it is and we will tell you honestly whether we can provide it.

Talk to us about securityEmail dayeightcontact@gmail.com

Ready for your eighth day?

A free 30-minute discovery call. We’ll find the automation with the biggest payoff for your business. No obligation, no jargon.

Book a free discovery callSee how it works

A note on what this page is. It is a plain-language description of how the platform is built and operated today, written for people deciding whether to work with us. It is not a contract, a warranty or a legal commitment, and no part of it creates one. The platform is still being built, so specifics will change. When they do, we update this page rather than leave it standing.

The documents that do carry legal weight are our privacy policy and our terms. If anything here appears to conflict with them, they are the ones that govern.