Security

Every organisation’s data lives in the same database, separated by row-level security enforced by Postgres itself: every request you, your teammates or your API keys make runs inside a transaction pinned to your organisation, and the database refuses to return another organisation’s rows to it even if our application code forgot to filter them. The background work that serves every organisation (running jobs, schedules, billing events) takes the organisation from the stored record it is working on, never from the request that started it.

• Your model provider keys and the credentials for your connected tools are encrypted at rest (AES-256-GCM), each bound to your organisation so it can’t be decrypted under another. They are never shown back in full, never sent to a model, and never included in an export.
• Sign-in sessions are stored only as a one-way hash.
• Everything in transit uses HTTPS.

We hold no AI model keys of our own: your teams run on your key with the provider you choose, under that provider’s API terms. We do not train any model on your data, and we do not sell or share it.

Each team has an approval setting. By default an agent reads and edits on its own, but must ask you before anything hard to undo or that reaches other people — sending email or messages, inviting people, deleting, or changing who can see a file. You can make a team more careful (ask before any change) or fully autonomous, and override that for any single connection — up to full access on one tool while the rest still ask. Approvals, and every tool call an agent makes, are recorded in the team’s activity log.

Every team has a budget and every job can have its own cap. The cap is checked before each model call, not after the bill arrives; a team that reaches its budget stops. A kill switch stops a team at its next step: nothing new starts, and its pending approvals are closed.

Tools your agents write for themselves run in an isolated sandbox, a fresh one for every run, with no file system and no access to our servers. They may only reach the web addresses the tool declares, and a new tool needs your approval first — unless you have set that team to fully autonomous, in which case it approves its own. Even then, a tool that can reach the web or your connected tools is first checked against the job it was built for, and waits for you if it doesn’t fit.

Calls to your connected tools go only to that tool’s own host, with the credential added on our side. Requests to private or internal network addresses are refused. Content agents read from email, web pages or documents is treated as data, never as instructions.

• When an email, web page or document tries to instruct an agent, the agent doesn’t follow it: it flags it to you under Needs you and carries on with the rest. From then on that job asks you before every change and approves nothing for itself.
• On a team you’ve given full access, anything that sends, deletes or shares is first checked against what the job is for. Anything that doesn’t fit waits for you, with the reason, and so does a message that promises what nobody authorised: a refund, a discount, a deadline, a legal or security assurance. If the check can’t run, it waits too.
• Teams read the web only at addresses that came from a search, a page they already opened or the job itself, or on sites you named, so an agent can’t send your data out by building a web address. GitHub asks before any change unless you give it full access.

The application and its database run in London (United Kingdom) on Vercel and Neon. Error monitoring (Sentry) uses its EU region. The full list of the providers that process data for us is in the Privacy Policy.

An owner or admin can export the organisation’s data, and an owner can delete the organisation and everything in it, at any time from Settings → Your data. Owners and admins can delete individual memories from a team’s Hive.

We are a small, new company: we do not hold SOC 2, ISO 27001 or similar certifications yet, and we won’t imply otherwise. If your organisation needs a security questionnaire answered, ask — we’ll answer it honestly.

Please email security@jugg.ai with what you found and how to reproduce it. We’ll acknowledge it within a few working days, keep you updated, and credit you if you’d like. Please don’t access other customers’ data or degrade the service while testing. Our security.txt has the same details.