Trust model

An agent that can act on your systems is a different kind of risk from a chatbot that can't. The three guarantees below are the ones we designed for, and they hold regardless of what the model decides in any given run.

That last clause is the whole point. A guarantee that depends on the model behaving well isn't a guarantee.

1. Gini reads a channel only after a human invites it

No workspace-wide ingestion, ever. Installing the app grants nothing; /invite @Gini in a channel grants that channel.

Remove it and its access ends with the membership.

There's no admin toggle that widens this, and no onboarding step that asks to index everything. If you're comparing tools, this is the property most worth checking: "connect your Slack" usually means something quite different.

2. Irreversible actions stop for a person

Sending, replying, submitting, purchasing, spending: Gini asks before the action, and the task parks on the server until someone decides. Waiting is enforced by the runtime, not by the model choosing to be patient, and every action writes an audit row whether a person approved it or policy did.

Approval policy is not a customer-facing setting. There is no per-tool exemption and no switch to leave off.

Two things pause unconditionally: entering a credential, which Gini only ever takes through a secure field, and any step one of your skills declares as needing review.

Be precise about the rest, because it's the difference between a control and a habit: for other irreversible actions, Gini is what recognises the moment and asks. That is what we build and test for. If you need a boundary that holds without depending on that recognition, use guarantee 3. A connection scoped read-only cannot write, whatever a run decides.

See Approvals.

3. Your access, not a master key

Integrations are scoped to the person who connected them. Gini can act with your Stripe access on your say-so; your teammates' asks use theirs.

There's no shared admin account that everything runs through, which means:

• Nobody gains access by asking Gini instead of asking the tool
• Someone leaving revokes what they connected
• Your tools' own audit logs name the actual person

See How connections work.

Underneath

Each workspace runs isolated. Nothing (memory, files, learnt formats) crosses between customers.

Runs are sandboxed. Each job gets a machine holding only the tools that job needs, torn down when it finishes.

Credentials are separated from execution. Integration credentials live in a vault with per-tenant keys. A run gets the ability to call a tool, not the token.

Encryption. TLS 1.3 in transit, AES-256 at rest.

Where Gini can still be wrong

Being honest about the boundary: none of the above stops Gini producing a wrong answer. It stops a wrong answer becoming an irreversible action without a person, and it stops Gini reaching data nobody gave it.

For wrong answers, the tools are source chips you can check, a plan you can stop, and a run record you can read. See Results and sources.

For a security review

The packet (trust model, sub-processors, retention, encryption, SOC 2 status) is at ginicomputer.com/security. For anything not covered there, security@ginicomputer.com.

To report a vulnerability, see our disclosure policy.