--- title: "The Security agent | Briks" url: https://briks.dev/docs/security-agent description: "Hire the Security agent to check your site's code, keys and live pages, hear in plain words what it finds, and have the Builder fix what you approve." last_updated: 2026-10-08 --- # The Security agent The Security agent looks after your project's security. It checks your site's code after every publish and the whole site each week, tells you in plain words what it found and what to do next, and asks the Builder to fix what you approve. It never changes your site on its own and never sees the value of a key. 6 minute read Checked against the studio on 8 October 2026 Who can hire it The Security agent is hired like any other agent, from Agents, and counts towards your plan's agents per project. Owners and Admins hire it, send its fixes to the Builder and accept risks; everyone in the workspace can read its report. ## What it checks Most of what it checks 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 the finding is real, and explains it to you. | Area | What is checked | | --- | --- | | Your site's code | 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, calls to other websites, and routes missing from the site's own list of who may use each one. | | Keys | Each key your code reads that is not set in Settings → Secrets, and each key set there that nothing reads any more. Names only: the agent never sees a value. | | The live site | Whether every address answers over https and plain http is sent there, how many days the certificate has left, the security headers, the sign-in cookie, whether other websites can use your site's API as a signed-in visitor, files that should never be downloadable, and error pages that show how the site works inside. | | Email | For a domain you send email from yourself: its SPF, signing (DKIM) and DMARC records. | | Files and forms | Files in public Storage folders with names that look private, such as backup, invoice, passport or contract, and a sudden burst of form entries compared with a usual day. | | Packages | Known security advisories for the packages your site has beyond the ones every site starts with, from a public advisory database. | | A closer look | Once a month, it reads the parts of the site that handle sign-in, money, uploaded files or an AI feature, starting with the parts that changed since it last looked. | ## When it runs - **After every publish.** The code and key checks run on the version that just went live, as it was saved, straight away and at no cost. The agent itself only wakes when they find something new, or when a fix it asked for has gone live and needs checking. - **Every week**, on Monday morning in your workspace's time zone: the full set of checks, including the live site, and a short report. - **When you write to it** in its thread, for example to ask whether a new form is safe to put live. 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 in your Telegram chats that turned on **Urgent security findings** in their alerts. ## Reading the report Find the report 1. Open Agents Where: Agents Choose the project, then the Security agent in the Crew tab. 2. Open the Security report tab Where: Security report Findings are grouped by how serious they are: Urgent, High, Medium and Low. The number on the tab is what waits for you. 3. Read each finding Each one says what someone could do, what it means for your business, and the next step: something only you can do (with where to do it), a fix the Builder can make, or a note that Briks is already on it. 4. Check the folded lists Risks you accepted, what was checked and found fine, and what was fixed in the last 30 days are folded away at the bottom. **Worth checking** lists what hangs on something only you can see, such as a file in a public Storage folder whose name looks private. It says exactly what to check and where. Findings waiting for you also appear under **Waiting for you**, beside what the other agents ask. ## Fix it and Accept the risk Have the Builder fix a finding 1. Choose Fix it Where: Security report The confirmation shows what a change usually costs in credits and how many you have. Press **Send to the Builder**. 2. Approve it Where: Waiting for you The fix waits under **Waiting for you**, in your email and on Telegram, like every change an agent asks for. You can read it, change its words, approve it or turn it down. 3. The Builder makes the change Once approved, it is built, checked and published as a new version, which you can undo from the version list. 4. The agent checks again After the new version goes live, the checks run again and the finding is marked fixed when it is gone. **Accept the risk** is for a finding you have decided to live with, often because it comes from something you asked for, such as a file in a public Storage folder that you mean to share. Your choice is kept 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. Every fix is a change you approve, always, made by the Builder, with undo. - It never proposes undoing something you asked for. When your own choice carries a risk, it says so once and leaves the decision to you. - It 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 never reads your customers' records one by one. It counts them, and names one only when a finding needs it. ## Budget and credits The checks themselves cost nothing. What the agent 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, which you can change in its settings, with a fifth of that available each day. 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. Tip When you can fix something in a setting yourself, the agent says so instead of asking the Builder: adding a key in Settings → Secrets costs nothing. ### Can it fix things without asking me? No. Security fixes always wait for your approval, and its settings say so in place of the switch other agents have. Every fix waits under **Waiting for you** with its credit estimate, and once you approve it, it is published as a new version you can undo. ### Why does it say Briks is already on something? Some findings are about how every site is served, such as a security header or the certificate. Briks fixes those for every site at once, so there is nothing for you or the Builder to do. ### Will it raise a risk I accepted again? Only if it gets worse. A finding it checked and found not to be a real risk is not raised again either. ## Read next - [AI agents **Hire AI agents** Hire AI agents that look after a live site: 13 kinds led by a Team lead, or your own, each with a schedule and a budget, asking you before they act.](https://briks.dev/docs/ai-agents) - [AI agents **Approvals and budgets** See what agents ask before they act, approve it in the studio, by email or on Telegram, choose what they may do alone, and set the budgets that cap their spend.](https://briks.dev/docs/agent-approvals) - [Data and automation **Secrets** Keep API keys and passwords your site's code needs on the site's server, never in pages or downloads. Add, change and remove them, and the rules Briks enforces.](https://briks.dev/docs/secrets) - [Working on a project **Versions, undo and redo** Every build and change is saved as a version of your site. Undo a change, redo it, or put any earlier version back live exactly as it was, with no credits held.](https://briks.dev/docs/versions) Still stuck? Write to [hello@briks.dev](mailto:hello@briks.dev) with your project's name and what you expected to see. A screenshot helps.