A security agent that checks your site and asks before it fixes

What the Security agent checks

Most of the checking is done by Briks's own checks, which read your site the same way every time and cost no credits. The agent then reads only where a check points, decides whether a finding is real, and explains it to you.

In your site's code, it looks for keys written into files, changes to your data with no limit on how often they can be made, members' records read without checking who is asking, text shown as raw HTML, and calls to other websites. For keys, it compares the names your code reads with the names set in Settings → Secrets, both ways, and never sees a value.

On the live site, it checks that every address answers over https, how many days the certificate has left, the security headers, and files that should never be downloadable. It also looks at files in public storage with names that look private, such as invoice or passport, a sudden burst of form entries, and known advisories for the packages your site adds beyond the ones every site starts with.

For a site with accounts or payments in its code, it counts who holds Admin or Staff, and checks the payment settings: test or live mode, the webhook secret, and orders a payment did not match.

Each finding in plain words, with one next step

Findings are grouped by how serious they are: urgent, high, medium and low. Each one says what someone could do, what it means for your business, and what to do next.

The next step is one of three: something only you can do, with where to do it, such as adding a key in Settings → Secrets, which costs nothing; a fix the Builder can make, behind Fix it; or Accept the risk, for something you have decided to live with.

Urgent findings, such as a key written into a page or a private file anyone can download, reach you at once: in the bell, and on Telegram when you have connected it and switched on urgent security findings. The rest wait for the weekly report.

Fix it always waits for your approval

Fix it shows what a change usually costs in credits, then sends the fix to Waiting, your email and your chats, like every change an agent asks for. Read it, change its words, approve it or turn it down.

Once you approve, the Builder makes the change, checks it and publishes it as a new version you can undo. When that version is live, the checks run again, and the finding is marked fixed once it is gone.

Security fixes never go ahead on their own. Other agents can earn the right to act alone after five clean approvals of one kind; this one cannot, and its settings say so where the others have the switch.

Accept the risk once, and it stays accepted

Some findings come from something you chose. The agent never proposes undoing what you asked for: it says once what the risk is, and the decision is yours.

Accept the risk keeps your choice with your name and the date, and the agent does not raise it again unless it gets worse.

What it never does

It never changes your site itself, and never asks for, reads or repeats the value of a key: it works with key names only.

It never tries to break in. On the live site it makes only the plain requests a visitor's browser makes, at most 25 in a check, to your site's own addresses. It counts your customers' records rather than reading them one by one.

When it runs, and what it costs

After every publish, the code and key checks run on the version that just went live, at no cost. The agent itself wakes only when they find something new, or when a fix it asked for has gone live and needs checking.

Every Monday at 07:00 in your workspace's time zone, it runs the full set, live site included, and writes a short report. It also answers when you write to it in its thread.

What it spends is the reading and writing it does to explain a finding and word a fix, paid from your workspace's credits within its own monthly budget: 20 credits by default. It asks for at most two fixes in a run, the most serious first, and each fix is a normal change with its own credit estimate.