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 folder of the same user. 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.

Files in the Sandbox

Of our storage, code in the Sandbox reaches only the Personal Drive of the user who runs it. 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, and nothing else: not the files of another user or another Tenant, not any other storage. 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.

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.

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.

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.