How Jarvis keeps work safe

Jarvis lets AI agents work on real code for real clients, so it makes a few promises about how that work is kept safe. This page explains those promises and what you will see in the workspace because of them.

#Nothing ships until a person approves it

Every piece of agent work stops at the approval gate. It does not matter how small the change is or how sure the agent sounds. A person reads the change, checks it against the acceptance criteria, and decides. Jarvis will not deploy anything that has not been approved, however the request reaches it.

What you see: runs waiting at Awaiting approval, with the changes, a screenshot, the agent's report and the criteria side by side, and three buttons: Approve, Request changes, Reject.

#Agents work on their own branch

Each ticket has a branch of its own. An agent makes its changes there and nowhere else. Your main line of code is only touched after approval, through an ordinary pull request your team can review like any other.

What you see: the branch name on the ticket and the run, and a pull request on the ticket once work is approved.

#An administrator decides what agents may do

By default an agent reads and changes files in the ticket's repository, and that is all. Your administrator decides what agents are allowed to do beyond that. Within those limits, anything more, such as running commands to install packages or run tests, is a choice made each time an agent is assigned. It is off unless the person assigning the ticket ticks Allow shell commands, and voice requests never turn it on.

What you see: the option on the assign dialog, and a marker on any run that had it.

#An agent asks instead of guessing

When an agent needs something it was not given, it stops and asks. The run waits at Awaiting permission with the request in one line. Nothing is lost while it waits: grant the request and the agent picks up where it left off, or continue without it and the agent finishes what it can and says what is left. Either way, it still stops at the gate.

#Every decision is on the record

Approvals, rejections and requests for changes are recorded with a name and a time. So is a decision that is later reversed, together with the reason given. Everything an agent was given for a run is kept on the run screen, so "what was it told?" always has an answer.

#Keys and passwords stay with administrators

Integrations such as GitHub, Jira or an AI model are connected by an administrator. Once saved, their keys are never shown again, not even to the administrator, and they are never handed to an agent or written into a run's output. See Connectors.

#Access follows your group

What you can see and do depends on your group, which your administrator manages. A screen or button you are not allowed to use is not shown to you. Some groups can approve agent work and some cannot. People see the clients and projects they are members of, unless their group covers the whole workspace.

Some records belong to one person. Your task logs are visible to you and to administrators only, and so are the proposals you write.

#Your sign-in

• Two-factor sign-in is available to everyone. Turn it on from your security page.
• Trusted browsers. You can let a browser skip the code for a while. Every trusted browser is listed on your security page, and you can remove one or all of them at any time.
• Lost your authenticator? An administrator can send you a one-time sign-in link so you can get back in and set it up again.

Approvals are always made in the approver's own name. An administrator who is viewing the workspace as someone else, to help them, cannot approve anything while doing so.

#Voice cannot approve

Jarvis voice can only do things from a short, fixed list, and only the things your group could do on the screens. Approving and deploying are not on the list. Say "approve it" and Jarvis tells you to open the run instead.

#Files

Some file types are not accepted, and uploads have a size limit your administrator sets. Attached files are not public: they are opened through the workspace, by people signed in to it.

#If something looks wrong

If a run did something you did not expect, open its run screen and read what it was given and what it reported. If you think an access setting is wrong, tell your administrator. And if you have a concern about the product itself, write to us through the contact page.