How we protect your credentials

You are about to give a web application the keys to your servers. You should know precisely what happens to them. This page is written to be checked, not to reassure.

Where secrets go

Encryption keys live in the server's environment, not in the database, so a copy of the database alone does not reveal anything.

What never happens

• They are never sent back to your browser. Once saved, a secret cannot be read out through the interface by anyone, at any role — including you. You can replace it; you cannot retrieve it.
• They are never given to the AI model. This is the core design decision. The model asks our server to run a command; our server decrypts the credential in memory, makes the connection, and hands the model the output. The credential itself never enters the model's context.
• They are never written to logs. Command logs and the chat run log redact anything that looks like a key or a token before it is stored.

What the AI model can see

Being precise about this matters more than the reassurance above.

The model sees the output of the commands it runs. If a command prints a secret, the model sees the secret. Examples:

• cat .env on your server prints your database password. In Execute mode it can do that if you approve it — and in Read mode, reading a file is a read.
• On AWS, secretsmanager get-secret-value and ssm get-parameter --with-decryption are classified as reads, so they can run in Read mode, and the result enters the chat history.

This is a real limitation and we would rather state it than let you discover it. Two mitigations:

1. Give the project a restricted AWS key. Add an explicit Deny for the secret-reading actions — the policy is in AWS permissions.
2. Viewers are refused secret reads by a deny list. It is a strong guardrail, not a proof. See Roles.

Connections

• Your browser talks to us over HTTPS.
• We talk to your servers over SSH, and to cloud and integration APIs over HTTPS.
• SSH sessions are held in memory only and closed after 30 idle minutes.
• A live session answers only the person who opened it.

Sessions and passwords

• Sign-in cookies last 30 days.
• Changing your password invalidates every existing session everywhere.
• Team members are forced to replace the one-time password they were given before anything else works. The person who created their login never knows their password. See Team members.

The audit trail

Every action taken through DevOps Agent is written to the per-server activity log — who, what, when, and whether it worked. It cannot be edited or deleted, by anyone, and it is kept for 365 days. Passwords and tokens appearing in commands are masked.

The log is honest about its boundaries: direct SSH that bypasses us, nested shells and full-screen programs are recorded as gaps rather than being silently missing.

How to reduce your exposure

Sensible regardless of how much you trust us:

1. Create a dedicated key for DevOps Agent rather than reusing your personal one. Then removing our access is one line in authorized_keys.
2. Use a restricted AWS key — read-only to start with.
3. Read-only tokens for Jenkins, Jira, Grafana and MySQL unless you need writes.
4. Give people the lowest role that works. Most engineers need Operator, not Admin.
5. Review the activity log occasionally, and the Outside logins section with it.
6. Rotate credentials periodically. Replacing them here is a two-minute job.

Current limitations we will not hide

• Read mode is protection, not a sandbox. It classifies commands by their text; something that looks read-only but has side effects would run. See The safety switch.
• MCP servers declare their own read-only tools and we trust that declaration. Connect only servers you trust.
• The MySQL read-only filter is a filter. Use a GRANT SELECT database user; that is the real boundary. See MySQL.
• Approvals live in memory. If the app restarts, a waiting approval is cancelled — safe, but it disappears.

Reporting a problem

Found a security issue? Email support@devops-agent.io with the detail. We would rather hear it from you than read it somewhere else.