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.
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.
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
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.
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.
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 workSecrets 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.
Found, routed, stopped.
Exposure first, then the right person.
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.
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.
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.
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
- Data processing agreement Signed in the console; no sales call
- Data locations Where each product stores data, per region
- Report a vulnerability Scope, safe harbor and response times; write to security@
- Email senders The only addresses Frazer mails from, against phishing
- Subscribe Security notices by email and RSS
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 names every company that processes your data, why, and where; the data locations page shows where each product stores data, per region.
How do I report a vulnerability?
Write to security@frazer.ai. Our vulnerability disclosure policy 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.