---
title: "Security and trust · Frazer"
description: "Frazer watches what runs on it, all the time: CI runs, deploys, devboxes, containers, images, secrets and every agent action. One finding with one fix, and how we run Frazer itself."
url: https://frazer.ai/security
index: https://frazer.ai/llms.txt
tokens: 3151
---

> For agents: every page on frazer.ai is indexed at https://frazer.ai/llms.txt.

# Security and trust · Frazer

**Security**  frazer.ai

# Security you can see.  
Watched while you build.

Frazer watches what runs on it, all the time: CI runs, deploys, devboxes, containers, images, secrets and every agent action. When something is wrong you get one finding with one fix, and the few things that must not wait are stopped at once. Further down: how we run Frazer itself.

[Open Security Center](https://frazer.ai/start?product=security-center) [How we run Frazer](#ours)

00 · Security Center Fig. 1 · product UI, demo organization

*The Security Center overview of the demo organization Acme: 3 findings need you, each with one fix, the first a critical public path to a database; 1 event is happening now and contained by policy; 1 crypto-miner was stopped automatically.*

Fig. 1: the Security Center overview, product UI with a demo organization.

01 · Continuous monitoring Fig. 2

## Watched while it runs.  
Not scanned once a night.

Inventory, identity, network, images, secrets metadata, agents and the audit log are Frazer’s own records. The security graph changes when they change, so a finding appears with the write that caused it and closes only when the fix is verified, never by a click.

**Fig. 2** From your workflows to one ranked list open-source sensors, Apache-2.0

-   ### CI runs
    
    Every job in a fresh microVM, destroyed afterwards. No long-lived tokens; every outbound destination is logged per job; pull requests from forks run only on untrusted pools.
    
    GitHub runners · egress log
    
-   ### Deploys and changes
    
    Every write, by a person or an agent, is a plan with an audit entry that names who asked and who acted. A finding appears with the change that caused it.
    
    plans · audit stream
    
-   ### Agent actions
    
    Agents act under their own identity. Each tool call is traced, approvals are recorded, and denials or guardrail blocks become signals.
    
    traces · approvals · kill switch
    
-   ### Devboxes
    
    One VM per box, short-lived credentials, allow-listed egress for agent sessions. Removing a person revokes their access in one operation.
    
    credential broker · SSH certificates
    
-   ### Containers
    
    An eBPF runtime sensor on every node sees process, file and network events: a shell in a container, a binary that is not in the image, a reverse shell, a miner.
    
    eBPF runtime sensor · detection inside sandboxes
    
-   ### Sign-ins and access
    
    A sign-in from a new country, two-factor turned off, a role raised outside just-in-time access, a burst of deletes: each one is a detection.
    
    audit stream detections
    

02 · Images and packages Fig. 3

## Scanned, fixed, signed, admitted.  
Before it runs, and while it runs.

A vulnerability matters when the image runs and a fix exists, so that is what you see first. Each finding names its fix: the base image or the dependency to bump. Malicious packages and signatures that stop verifying are flagged on the running image too, and devbox and VM images are scanned when they are built.

**Fig. 3** From push to running, with one fix per finding scan on push · cosign format · admission policy

03 · Secrets

## Secrets never sit  
in a box.  
Minted when needed.

Devboxes, CI jobs and agent sandboxes get short-lived credentials from the credential broker, scoped to one session or one job. Agents never hold a key at all: the broker and the gateways add it on the way out.

-   ### Short-lived by default
    
    SSH certificates and Git, LLM and API tokens are minted per session or job and expire on their own.
    
-   ### Write-only for people
    
    By default no person reads a value back, owners included: it takes an explicit Secret Accessor grant.
    
-   ### Every read on the record
    
    Each access is audited; “who read it” is answered per identity and hour.
    
-   ### Reads behind a second factor
    
    Each read needs step-up 2FA and is audited; production can require an approval, and a project policy can forbid human reads.
    
-   ### Rotation without downtime
    
    Two valid versions while consumers move; then the old one is disabled and destroyed.
    
-   ### Revoked in one step
    
    Removing a person blocks new credentials at once and revokes the rest in the same operation.
    

04 · LLM gateway and agents

## Every model call  
through one door.  
With a guardrail floor.

The LLM gateway sits between every model and your code, devboxes and agents. The organization sets a floor; projects can tighten it, never loosen it. A kill switch suspends every agent and is checked on every request.

[How managed agents work](https://frazer.ai/agents)

-   ### Secrets blocked
    
    Keys and tokens in prompts or outputs are stopped before they leave.
    
-   ### Personal data masked
    
    Masked on the way to the model, restored in the answer.
    
-   ### Injection flagged
    
    Tool results and fetched pages are scored; risky tools switch to Ask.
    
-   ### Data policy per route
    
    Zero data retention, no training or org-only providers, enforced per route.
    
-   ### Logs you choose
    
    Metadata only by default; bodies only where a project turns capture on.
    
-   ### Tools and skills scanned
    
    MCP servers and skills are scanned before use and again when they change.
    

05 · Exposure, alerts and response Fig. 4

## Found, routed, stopped.  
Exposure first, then the right person.

Exposure check What it finds

**Public routes and open ports** What answers from the internet, per project and server

**Firewall rules open to everyone** Database and admin ports reachable from any address

**Paths to high-value data** Internet to databases, buckets and secrets you mark as high value

**Toxic combinations** Exposed, with an exploited vulnerability, and able to read a production secret: one Critical

**Model calls around the gateway** Workloads or boxes calling model APIs directly, seen in egress

**Fig. 4** From a signal to a person, an agent or an automatic stop every action audited, reversible where possible

Only three things happen without asking, because waiting costs more than acting: a crypto-miner is killed, known-bad destinations are blocked, and an agent that acts outside its scope is contained. Everything else is proposed and runs with one click and a second factor; you can promote a response to automatic per playbook, for example quarantining any workload that opens a reverse shell in production.

06 · Security Center

## One place to see it.  
On in every organization. No agents to install, no tier to unlock.

-   ### Findings
    
    One list ranked by context, one fix each.
    
-   ### Threats
    
    Runtime and account detections as one story.
    
-   ### Vulnerabilities
    
    What to bump where, for images that run.
    
-   ### Identity and access
    
    Who and what can do too much.
    
-   ### Data protection
    
    Encryption, backups and restore drills.
    
-   ### AI and agents
    
    Agents, MCP servers, guardrail floor.
    
-   ### Controls
    
    Rules with owners: enforced, monitored or off.
    
-   ### Notifications
    
    Contacts and routing per severity.
    

For audits, the Business plan adds compliance evidence export and an auditor workspace with unlimited auditor seats: $250 per organization a month.

07 · How we run Frazer

## What we do on our own platform.  
And who is responsible for what.

-   ### Foundation as code
    
    Our servers, networks, DNS and buckets are defined in OpenTofu. Every change is a reviewed plan, applied only from the main branch, and a nightly check reports drift.
    
-   ### Two people for every change
    
    Infrastructure changes need two approvals from code owners. Break-glass access and root access to the secret store need two people, and every use is recorded.
    
-   ### Off-site, encrypted backups
    
    State, secret-store snapshots and databases are encrypted and copied to a second provider. Every night a job restores the copies in a separate environment, as disaster recovery would, and a deploy is blocked when the last good restore is more than 26 hours old.
    
-   ### Escrowed roots of trust
    
    Root keys start offline. Recovery shares are held by separate people, with escrow copies in two places; we rebuild from escrow as a drill every quarter.
    
-   ### Nothing gets in
    
    Servers dial out to Frazer and open no inbound port. Staff access to our own systems is short-lived, needs a hardware key and is recorded; nobody holds standing admin access.
    
-   ### Our own Security Center
    
    Frazer runs the same Security Center on its own clusters. Status lives off-platform; for every major incident we publish a preliminary report within 24 hours of mitigation and a full postmortem within 7 days.
    

Layer Your servers Provider accounts Frazer servers

**Physical security, power, firmware** You Your provider Frazer, with its provider

**Server acceptance, burn-in, wipe** You, checked by Frazer You, checked by Frazer Frazer, wiped before reuse

**Operating system image and nodelet** Frazer Frazer Frazer

**Control plane, isolation between orgs and projects** Frazer Frazer Frazer

**Your workloads, code and data** You You You

**Roles, grants and approvals** You set, Frazer enforces You set, Frazer enforces You set, Frazer enforces

08 · Audits and certifications

## Audits and certifications: we will publish them when we have them.

Until then, this page describes what Frazer does, and the documents below say who handles your data and how to reach us.

-   [**Sub-processors** Every company that processes your data, why, and where](https://frazer.ai/legal/subprocessors)
-   [**Data processing agreement** Signed in the console; no sales call](https://frazer.ai/legal/dpa)
-   [**Data locations** Where each product stores data, per region](https://frazer.ai/legal/data-locations)
-   [**Report a vulnerability** Scope, safe harbor and response times; write to security@](https://frazer.ai/legal/vulnerability-disclosure)
-   [**Email senders** The only addresses Frazer mails from, against phishing](https://frazer.ai/legal/email-senders)
-   [**Subscribe** Security notices by email and RSS](https://frazer.ai/security/notices)

Questions

## Security, answered.

Is Frazer audited or certified?

Not yet. It is too early, so we make no audit or certification claims. When we have reports, they will be on this page.

What does Frazer do on its own, without asking?

Three things, because waiting costs more than acting: a crypto-miner is killed, known-bad destinations are blocked, and an agent that acts outside its scope is contained (its session stopped, its credentials revoked, its cell kept for review). Everything else is proposed and runs with one click and a second factor, unless you promote a response to automatic in a playbook.

Can Frazer staff reach my servers?

Only if you let them. Servers dial out to Frazer and open no inbound port, and the agent runs signed, typed operations, never a shell. Remote shell is off by default: an organization admin can turn it on for one server for a set time, the session is recorded and you are notified. Every staff action on your resources is in your audit log.

What happens to prompts and code that pass through the LLM gateway?

The gateway logs metadata only by default; bodies are kept only where a project turns capture on. Keys and tokens are stopped before they leave, personal data is masked on the way to the model, and each route enforces its data policy: zero data retention, no training or org-only providers.

Where is my data stored, and who processes it?

Your workloads run on the servers you choose: your own, your provider accounts or Frazer servers. The [sub-processors list](https://frazer.ai/legal/subprocessors) names every company that processes your data, why, and where; the [data locations page](https://frazer.ai/legal/data-locations) shows where each product stores data, per region.

How do I report a vulnerability?

Write to [security@frazer.ai](mailto:security@frazer.ai). Our [vulnerability disclosure policy](https://frazer.ai/legal/vulnerability-disclosure) says what you may test, how fast we answer, and the safe harbor we give good-faith research. The same contact is in our [security.txt](https://frazer.ai/.well-known/security.txt).

## See what is exposed today.  
Fix it with one plan.

[Open Security Center](https://frazer.ai/start?product=security-center) [Read the docs](https://frazer.ai/docs)
