Security

Autonomy signs in to your product, receives its emails and texts, and records what it sees. This page explains what is kept, who can see it, and what can leave Autonomy.

Secrets

Passwords, tokens, keys, authenticator secrets and saved browser sessions are secrets. You store them as secret environment values, in sign-ins, or as hidden values on a step.

• Write-only. Nobody can view a secret again after you save it, not even you. To change one, type a new value.
• Filled by reference. The agent never sees a secret's value. It asks for the secret by name, and Autonomy fills it into the field. Authenticator codes are generated at the moment they're typed.
• Never in evidence. A saved secret is masked wherever it would appear: Step Actions, screenshots, video, network details, logs and emails, also when it's URL-encoded or escaped. It shows as a lock: "Filled by reference. The agent never sees this value."
• Only runs receive them. Secrets are read when a runner picks up a run, and only for that run.
• Only owners and admins can replace a sign-in's saved secret or change its environments.

Don't put real passwords in step text, descriptions or pull request comments. When you describe a test case, Autonomy refuses a description that holds a password and asks you to pick a saved sign-in instead.

What a run makes or receives

Everything a run makes or receives is shown in clear to the people who can open the run: received codes and links, generated passwords, test inboxes, tokens in URLs, request and response bodies, cookies and console output. Only values you saved as secrets are masked. Treat run evidence like the test environment it came from.

While you record a test case in a hosted browser, you see the codes your session receives. Other members only see that a code arrived, and codes are never stored in the recording or the test case.

A run's inbox closes when the run ends. Its address stays reserved for your organization, so nobody else can receive its mail.

Project access

Your organization's owners and admins can open every project. Members can open only the projects an admin gives them, in Organization → Members. Everything inside a project, its test cases, runs, evidence, sign-ins and issues, is visible only to people who can open the project.

Removing a member removes their access to the organization and every project in it.

API keys

Owners and admins create API keys in Organization → API keys, for CI and scripts. A key:

• Reaches every project in the organization, and can do everything the API offers: read results, start runs, and create and edit test cases, test plans, environments and issues.
• Is shown once when you create it. Copy it then, and store it as a secret in your CI.
• Is limited to 1,000 requests an hour.
• Stops working immediately when you revoke it.

Give each system its own key, so you can revoke one without breaking the others. See Authentication.

AI assistants (MCP)

AI assistants connect to Autonomy with OAuth. You sign in, pick an organization, and approve what the assistant can do, such as "Start runs" or "Create and edit test cases".

• One organization per connection. To reach another organization, connect again.
• It acts as you. A member's assistant reaches only the projects that member can open.
• API keys don't work over MCP. Assistants always connect as a person.

Only connect tools you trust. See AI assistants.

What leaves Autonomy

Run evidence leaves Autonomy through the API, MCP and exports such as observability tools. They all use the same limited set of evidence for each step:

• The step's outcome, its result and the explanation.
• The failure category, if any, and the Final check: whether it agreed, and why.
• The platform and how long the step took.
• Links to screenshots, frames and the video. Each link expires after 15 minutes.

Step Actions are available too, with saved secrets masked. What never leaves Autonomy:

• Which AI model or model provider worked on a run.
• What a run cost in model use.
• Prompts given to the agent.
• Internal tool names.
• Raw UI trees, such as page source or accessibility trees.
• Values you saved as secrets.

Dashboard sessions

A dashboard sign-in lasts 30 days and renews while you keep using it. A brief network or server problem doesn't sign you out: the dashboard keeps retrying, and after a minute it shows "Still connecting… Sign in again". If signing out fails, you see "Couldn't sign out. Try again." and stay signed in, so a failed sign-out never looks like a successful one.

Chrome extension

The Autonomy Chrome extension uses your dashboard session; there's nothing to pair. It can't read any site until you allow it, one site at a time:

• Saving a login. When you click Save login, Chrome asks permission to read that one site. You see What we keep, the cookies and values it will save, before anything is sent. Sign-in provider sites, such as your SSO, are left out unless you tick them. The login is stored as a secret, and the extension keeps nothing on your computer.
• Recording a test case. The extension records only on the site you allowed when you started, and only until you finish.

Only you can renew a login you saved. See Chrome extension.

Where runs execute

Runs execute on Autonomy's runners, each with a fresh browser, app install or HTTP client, and every run starts signed out. A runner needs to reach your environment's URL or build. On Enterprise, runs can also execute on your own machines, inside your network. See Runners.

When a run targets an environment named Production, the agent behaves like a careful user: it won't spend real money or delete existing data unless a step asks for it.