Security

Your data stays apart

Everything you and your colleagues do in the Strategy Agent belongs to your Tenant, your company’s own space on the platform. Every request is checked against the Tenant it belongs to, so no one can read or change another company’s data.

Inside your Tenant, Roles decide who may do what. Your Tenant’s admins give them to users and Groups.

Signing in

Users sign in through Amazon Cognito, in the EU, with a password or through their company’s own identity provider (SAML or OIDC). Everyone who signs in with a password can add two-step verification with an authenticator app, and your Tenant’s admins can require it of all of them.

Your admins can verify your company’s email domains, so that its users find the right Tenant and sign-in. To check a domain, we look up a TXT record in its public DNS. The lookup holds only the domain’s name.

Access by our staff

Authorised staff of Scavenger AI access your data only as far as support, operation and security of the platform need it, and to meet legal obligations. They are bound to confidentiality.

Our Super-admins are members of every Tenant, so that support never depends on an invitation. Your admins see them on the Users page, marked Scavenger AI staff. They always sign in with a password and two-step verification, and everything they do in your Tenant is in its Audit Log.

Credentials in the Sandbox

When the agent runs code, it does so in a Sandbox Session. If the platform puts a credential into a Sandbox Session, the agent writes it there itself, never through code the model writes, and never into your files. The agent replaces the credential with the placeholder “hidden credential” everywhere that you, your colleagues or the model could see it: in the output of the code, in the code the model wrote, in the Conversation as you see it, and in what the model remembers of it.

This masking is a mitigation, not a boundary. The agent recognises a credential as it is and in common encodings (URL-encoded, base64, base64url). But code that has a credential can change it in ways no list covers, for example by splitting, reversing or encrypting it, or by sending it away. So treat masking as a safeguard against accidental leaks, such as a print, and not as protection against code that is written to get at a credential. The agent keeps the list of values to mask in memory only, never in a database, in files or in logs.

Stopping a Sandbox Session doesn’t withdraw its credentials. Code that has the drive credentials can copy them out of the session. When a session is stopped, for example because a Right was taken away or a user was removed, a copy keeps working until the credentials expire, at most one hour after the agent issued them, and only for the same folders of the same user: their Personal Drive and the Shared Drives they reached when the session started. A removed user’s folder is deleted again after their session is stopped, but a copy of the credentials could still write there until it expires. When a share or an owner of a Shared Drive is added, changed or removed, the platform checks every Sandbox Session of your Tenant and stops those whose user no longer reaches exactly the drives, at exactly the levels, they started with. The agent makes the same check before every run and never reuses such a session. A copied credential never reaches a drive its user didn’t reach when it was issued, and it ends within the hour in any case.

Files in the Sandbox

Of our storage, code in the Sandbox reaches only the Personal Drive of the user who runs it and the Shared Drives that user reaches. To do that, the agent gives the Sandbox Session short-lived credentials, valid for one hour at most and renewed before a run would outlive them. They allow reading, writing, listing and deleting files in that user’s own folder, and reading earlier File Versions there. In a Shared Drive the user may write to they allow the same, and in one they may only read, they allow reading and listing and refuse every write. Which drives that is comes from the user’s shares at the start of the session, one named place per drive, from the same role for every user and Tenant. Nothing else is allowed: not the files of another user or another Tenant, not a Shared Drive nobody shared with the user, not any other storage. A user who reaches many Shared Drives gets several sets of credentials, each reaching only its own drives. Deleting a file only hides it behind a delete marker, because the credentials can’t delete earlier File Versions or change how the storage is set up. The Sandbox’s network has no route to any other storage of ours either. Files that outlive a Sandbox Session live only in our encrypted storage in Frankfurt: the Sandbox’s own disk disappears with the session.

When a user downloads a file a run wrote, the Web App asks the platform for a link that works for one minute. The platform builds the file’s location from the user’s verified sign-in and the path asked for, so the link can only point to a file in that user’s own Personal Drive: the files of another user or another Tenant, a folder, and a file that isn’t there all get the same answer as a missing file. The platform itself, not the code in the Sandbox, lists and reads files on the Personal Drive for the agent’s own tools and for these links, always for the user whose request it is serving.

When a user uploads a file in Drives, the browser sends it straight to our encrypted storage in Frankfurt, not through the platform’s servers, to a link the platform signed for that one file. The link works for three hours, names the file’s exact size, so the storage refuses any other, and is built the same way from the user’s verified sign-in, so it can only point into that user’s own Personal Drive. A file can weigh at most 4 GB. Every drive has a limit, 100 GB per Personal Drive, 500 GB per Shared Drive and 10 TB per Tenant by default, and an upload that doesn’t fit is refused before it starts. The storage accepts these uploads from the Web App’s own address only, and a multipart upload that was never finished is thrown away after a day. Your users’ browsers therefore contact the storage’s address in Frankfurt, an Amazon S3 address of ours, in addition to the platform’s.

Because the credentials are limited by the platform and not by the code, a prompt that tricks the agent into writing malicious code can’t reach more than the user could reach anyway.

ZIP archives. When a user downloads a folder, a drive or a selection from Drives as a ZIP, the platform packs the files the user can read into one ZIP file in our encrypted storage in Frankfurt, in a place of its own that is separate from the drives’ files and carries the user’s and the Tenant’s identity in its address. The ZIP is kept for one day and then deleted by the storage itself. The download link the Web App gets works for 5 minutes, is made again only after the platform has checked that the user still reads the drive, and can only point to a ZIP that the same user asked for. Nobody else can open it. A ZIP is not part of a drive’s usage, and it triggers no notification. A ZIP holds at most 4 GB and 10,000 files.

Deleting for good from Recently deleted. The owner of a Shared Drive, or the user of their own My Drive, can delete a deleted file or folder for good, one entry at a time or everything in Recently deleted at once. This removes every version and delete marker of those files, and it can’t be undone. Users with write access who aren’t owners, admins who hold the Right to read and manage all Shared Drives, the agent and the code in the Sandbox can’t do it. Only this one path of the platform may delete File Versions, and only under the drives’ storage, never anywhere else. A file that has a current version again is never touched. The Audit Log records every such deletion, with the user, the drive and the file’s path, or how many files, before anything is deleted, without file contents.

Deleting a Shared Drive. An owner, or an admin who holds the Right to read and manage all Shared Drives, can delete a Shared Drive. It disappears at once for everyone, and the Sandbox Sessions of the users who reached it are stopped, so the agent and its code no longer reach it. For 20 days an admin can restore it, with its shares and owners. After 20 days a daily job deletes for good every version and every delete marker of every file in it, and its records. Apart from deleting for good from Recently deleted, this is the one place where earlier File Versions are removed. The Audit Log records the deletion, the restore and the final deletion, the last one as the platform’s, without any file names.

Internet access for code

Code the agent runs can reach the internet only if its user holds the Right Sandbox has internet access. Without it, code reaches nothing but the user’s own Personal Drive. Both preset Roles, Admin and Member, hold the Right by default. Your admins can remove it from them or give it to others, and the Admin App warns them wherever it is shown or granted.

What this risks. Code with internet access can send any data and credentials it holds out of the platform, for example after a prompt injection in an uploaded file. We accept this and make the risk explicit instead of blocking the combination: your company decides what it grants. Hiding credentials in what users and the model see doesn’t change this, because it doesn’t cover network traffic.

Database permissions. What the agent may read or write through a Data Source is decided by the database user behind your connection, which is your company’s responsibility. The platform adds no read-only guarantee of its own. Together with the statement above, this means: the permissions you give are the limits the agent works within.

How we trace egress. Code runs in a network of its own that holds nothing but the Sandbox. Code without internet access has no route out of it. Code with internet access leaves through one NAT gateway that only it uses. We record the network traffic of both in VPC Flow Logs, keep them for one year, and can trace afterwards which addresses were reached. A log entry shows the network address that sent traffic and where it went. It doesn’t name the user, so tracing an entry back to one user takes the times of their runs as well.

Data Sources

No read-only guarantee of our own. The agent queries a Data Source as the database user in its connection string, with the SQL it writes. Whatever that user may do in the database, the agent may do too: if the user may change or delete data, a query of the agent’s can. Choosing a database user with only the permissions the agent should have is your company’s responsibility; we recommend one that only reads. The platform adds no read-only check of its own on top. See Connect a Data Source.

Connection strings stay sealed. A connection string, and the CA certificate it trusts, is encrypted as soon as it arrives, with a key used for nothing else, and no screen or answer of the platform shows it again. Only the query service decrypts it, for one query at a time, and, for a Data Source set to Also in the Sandbox, the agent for the Sandbox Session of a user who has access to it. It never reaches the AI model, the Conversation or a log.

Who may query. Only users who hold the access Right on a Data Source, directly, through a Group or through “Access to all Data Sources”, can have the agent query it, and the query service checks it again at every query. Taking the Right away takes effect at the next query. The Data Sources, Cards and Dashboards of another Tenant answer as if they didn’t exist, and the agent never takes another Tenant’s Data Source into a Conversation.

Where queries come from. Queries to a Data Source on the public internet leave our network from fixed IP addresses, which your firewall can allow. We never connect such a Data Source to a private, loopback, link-local or cloud metadata address.

Tenant networks. For databases in your company’s private network, we can set up a Tenant network: a network of your Tenant’s own, joined to your private network by a site-to-site VPN. Only your Tenant’s queries, and its code in the Sandbox, use it, and nothing in it can reach the internet. We record its network traffic in VPC Flow Logs and keep them for one year. Our staff set it up and remove it together with your network administrators. See Reach databases in your private network.

The Query Log. Every query the agent runs on a Data Source is recorded in its Query Log: who asked, the question, the query, whether it worked and how long it took, never the rows it returned. Only users who may accept Context Change Requests on that Data Source can read it. Each entry is deleted a year after the query; deleting the Data Source deletes its Query Log at once.

No training on your data

We don’t use your data to train or fine-tune AI models, neither our own nor those of our sub-processors. AI models only answer requests.

Technical and organisational measures

Our measures for confidentiality, integrity, availability and how we check them regularly are listed in Annex 3 of the data processing agreement.

Security incidents

If we suspect a security incident or a breach of the protection of personal data, we inform your company without undue delay, take the measures needed to secure the data, and support your company in its own obligations. The details are in § 6 of the data processing agreement.