Operate and secureProduct page Pricing

Security Center

Security Center shows how safe your organization is, what to fix first and what is happening right now, and it keeps the evidence an auditor asks you for. It is on for every organization, with nothing to install and no tier to unlock, and it covers workloads on your servers, in your cloud accounts and on the Frazer fleet. Inventory, identity, network, images, secrets metadata, agents and the audit log are Frazer’s own records, so a finding appears with the write that caused it instead of after a nightly scan, and it closes only when the fix is verified.

Product overview: Security.

How it works

Frazer builds a security graph from its own inventory: projects, clusters, workloads, VMs, devboxes, databases, buckets, secrets, keys, gateways, routes, public addresses, firewall policies, members, service accounts, agents, MCP grants and LLM endpoints, joined by edges such as exposes, routes to, runs, uses identity, can read, can write, holds secret and reaches. Engines work over that graph:

Controls are rules in CEL, evaluated on every relevant write and again nightly for drift.
Exposure finds the paths from the internet to your high-value resources, marks toxic combinations (for example a public route, a critical CVE and a service account that can read a production secret) and the chokepoints that cut the most paths.
Detection reads the audit stream, runtime sensors, network flows and the gateways, and correlates weak signals into one story.
Response runs typed actions through the API or frazer-clusterlet, each audited.
Evidence is collected nightly per control and stored write-once.

Inside your clusters Frazer runs sensors as part of every cluster’s guaranteed set: an eBPF runtime sensor on every node, a vulnerability scanner for vulnerabilities, configuration, RBAC, exposed secrets and SBOMs, Frazer Policy for admission and policy reports, and CIS benchmark checks weekly. Sandboxed node pools, such as agent sandboxes and fleet devboxes, add runtime threat detection inside the sandbox. frazer-clusterlet streams their reports and events out.

Security is an organization area, because attack paths cross projects through shared server pools, people with roles in several projects and agents with organization grants. Every page has a project filter, and inside a project Overview › Security opens the same pages fixed to that project.

Finding: one issue (a rule on a resource or a path), with its detections attached as evidence. Repeats update last seen and the count; they never add rows.
Severity and priority: severity is the rule’s (Critical, High, Medium, Low); priority raises or lowers it by context and shows the reasons as chips: internet-exposed, running, known exploited, path to a high-value resource, sensitive data, production.
High-value resource: something whose exposure matters most, such as a production database. Exposure is measured against this set.
Control: a rule with a mode (Enforced, Monitored or Off) and an owner (Frazer, your organization or a project).
Secure score: 0 to 100 per organization and project, the weighted share of passing controls.

Get started

Security Center is already running. These steps make its findings reach the right people and rank the right resources first.

Open Organization › Security › Overview. It shows the score, Needs you, Happening now and coverage. For one project, open Project › Overview › Security.
Add a verified security contact under Security › Assurance › Settings: an email address or a channel, with the categories it receives (security, compliance, technical). At least one verified contact is required; without one, the overview shows a failing Critical control.
Review the high-value resources in the same settings. The defaults are production databases and in-memory instances, data buckets, every secret and key, model weights and fine-tune datasets, the organization’s approval key, CI workload identity bindings that can push images, and anything tagged frazer.ai/crown-jewel=true. Add your own selectors by type, project or tag.
Open Findings. The default view, Needs you, holds open findings of priority Critical or High that are not muted.
- CLI
- Console
Terminal window
frazer security findings list --severity critical,high --project acme-production frazer security findings get sf_9k2a --path
Open a finding to see its attack path, its fix and the affected resources, with the evidence and activity in their own tabs. Explain opens the assistant with the finding as context; its answers cite your resources.
Apply the finding’s primary fix. When the control passes or the resource is gone, Frazer marks the finding fixed.

Fix a finding

Every finding offers one primary fix:

Fix	When	Example
Plan	The cause is a Frazer resource	Remove `0.0.0.0/0` on `tcp:5432` from the firewall policy `org-baseline`; review the plan and apply it
Git	The cause is in your environment repository, and the Frazer GitHub App, which writes, is installed	Bump the `checkout-api` base image to `frazer/base-go:1.26.2` in a pull request
Agent	A code change is needed	Fix with agent starts an agent session with the finding as its goal; it opens a pull request as the Frazer bot
Manual	The cause is outside Frazer	Rotate a leaked key at its provider, with a checklist

Lifecycle. A finding is Open until it is Fixed, Muted or Accepted. Fixed is set by verification only: the control passes or the resource is deleted. A muted or accepted finding reopens when its expiry passes or its context changes, for example when the workload becomes public.

Mute or accept with a reason and an expiry. Muting hides a finding you will handle later; accepting records a risk you take on purpose.

frazer security findings mute sf_9k2a --reason "Internal-only test endpoint" --expires 30d

For Critical and High findings the expiry is at most 90 days, and accepting a Critical finding needs a second admin with a fresh second factor. For many findings at once, create a mute rule in Security › Assurance › Settings: a CEL filter, a reason, a kind (mute or accepted risk) and a required expiry.

Respond to threats

Threats shows what is happening now, from four kinds of source:

Source	Examples
Runtime (the eBPF sensor; in-sandbox detection)	A shell spawned in a container, a binary that is not in the image, a reverse shell, a crypto-miner, reads of `/etc/shadow` or service-account tokens by an unexpected binary, a kernel module load
Account and API (the audit stream)	Two-factor turned off, an owner added, a role raised outside just-in-time access, a token created and used from a new country within minutes, impossible travel, more than 10 deletes in 5 minutes, the kill switch used
Agents	Repeated denials, egress refused to unknown hosts, guardrail blocks, a poisoned MCP server, an agent token used outside its session
Network	Connections to known-bad addresses and mining pools, DNS to suspicious or newly registered domains, port scans from a workload, unusual egress from a database namespace

Weak signals and findings for the same principal or workload are correlated over 24 hours. A sequence that matches a pattern (initial access, then privilege, then access to a high-value resource) becomes one Critical finding with a timeline, MITRE ATT&CK tags and the raw evidence. Muted signals are not used.

What Frazer does on its own. Three things, because waiting costs more than acting: it kills a known crypto-miner process, blocks egress to known-bad destinations and, for agents only, contains an agent that acts outside its scope. Everything else is proposed:

Action	Default
Kill a known crypto-miner process	Automatic
Block egress to a known-bad destination	Automatic
Contain an agent acting outside its scope (its flows frozen, its credentials revoked, its sessions stopped, its cell snapshotted)	Automatic for agents, on a strong signal
Isolate a workload (quarantine network policy, kept running for forensics)	Proposed; one click with a second factor
Revoke a person’s sessions and tokens	Proposed
Suspend an agent, or every agent with the kill switch	Proposed
Cordon and drain a node	Proposed
Take a forensic snapshot	Proposed

A strong signal is a credential used outside its session, a write to a shared service outside its sanctioned channel, or egress to a known-bad destination or in an exfiltration pattern. A single refused connection is never one. The session’s owner gets the evidence and resumes it with fir session resume <session> --dry-run; a contained session’s calls fail with session_contained.

frazer security respond isolate --workload acme-production/checkout-api-7f9c --dry-run

Every action is an operation with an audit entry and, where one exists, a reversible counterpart. You can promote a proposed action to automatic in a playbook, for example isolate pods that open a reverse shell in production.

Prioritize vulnerabilities

Images are scanned in Frazer Registry on push and daily for every digest pulled in the last 30 days; the in-cluster vulnerability scanner scans what actually runs in each cluster, including images from other registries; devbox and VM images are scanned when they are built. The OS packages of Frazer-managed nodes are Frazer’s to patch.

A vulnerability is Critical or High in your list only when the image runs and a fix exists. Known exploitation, a high exploit prediction score, internet exposure, a path to a high-value resource and production raise it. Rows are grouped by package and fixed version (“runs in 6 workloads”), so the fix is one base-image or dependency bump.

Severity	Default time to fix
Known exploited, or exposed and Critical	72 hours
Critical	7 days
High	30 days
Medium	90 days

The list shows due in, and a missed deadline raises the finding’s priority. Your organization can change the timers.

Supply chain. Frazer Registry signs every pushed digest with your project’s key; builders attach an SBOM and SLSA provenance; Frazer Policy verifies signatures at admission and refuses unsigned images in production. Controls cover signed images in production, provenance, SBOMs, a registry allow-list, base image age, malicious packages, GitHub Actions pinned by SHA with least-privilege permissions, and the OpenSSF Scorecard of connected repositories. A question such as where is xz 5.6.1 running? is one search over SBOMs.

Controls and the secure score

Controls are defined by Frazer and versioned with the platform, in eight areas: identity, keys and secrets, network, workload, data, supply chain, AI and agents, and audit and response.

Mode	Meaning	Example
Enforced	Preventive: the API, Frazer Policy or the gateway refuses the request, so a failing state cannot exist	Images in production are signed by the project’s builders
Monitored	Detective: a finding is raised	A critical CVE with a fix in a running image older than 7 days
Off	Not evaluated; needs a reason, and the change is audited	A WAF on every public route, for an internal-only organization

Owners. Frazer-owned controls (disk and control-plane datastore encryption, encryption between nodes, offboarding drills, audit retention) show as passing with Frazer’s own evidence. Organization-owned controls (two-factor, session policy, contacts, the high-value set) are a floor: projects can tighten them, never loosen them. Project-owned controls cover per-project choices such as backups, WAF and exposure.

frazer security controls list --area network --status failing

Secure score. Each control weighs by severity (Critical 10, High 5, Medium 2, Low 1). The score is capped at 79 while any Critical finding is open, and the overview shows a 90-day trend. There are no badges and no grades.

Posture: identity, data, AI and agents

Identity and access shows sign-in strength (two-factor coverage, passkey share, SSO enforcement), privileged people (owners, admins, standing versus just-in-time), tokens and keys by age and last use, permissions unused for 90 days with a plan for a narrower role, members from other domains or inactive for 90 days, and agents whose ceiling is above Developer.
Data protection shows keys by purpose with their rotation age, encryption at rest and in transit for every store, backup coverage with the last success and the last restore drill, retention, sensitive-data discovery in Postgres tables and buckets, and where each store lives.
AI and agents shows the inventory (agents, MCP clients, external MCP servers, model endpoints, LLM providers reached through the gateway), each agent’s ceiling and used toolsets, the organization’s guardrail floor in the LLM gateway, and shadow AI: workloads, VMs or devboxes that call model APIs around the gateway. Each external MCP server is scanned before it can be allow-listed, and again when its tool list changes.

Collect evidence for audits

Security Center maps your controls to SOC 2 (2017 Trust Services Criteria), ISO/IEC 27001:2022 Annex A, CIS Kubernetes 1.12, NIST SP 800-53 rev. 5, the HIPAA Security Rule, GDPR, PCI DSS 4.0.1 and ISO/IEC 42001, so you can assess your own environment against them. Readiness per framework lists failing controls first; requirements with no technical control show as outside Frazer.

Evidence is collected nightly per control (the query, its result and a configuration snapshot) and stored write-once for 3 years.
Auditor workspace gives people with the Audit viewer role read access for an audit period, time-boxed.
Export as OSCAL assessment results or as a zip with CSV, JSON and a PDF summary:
Terminal window
```
frazer security evidence export --framework soc2-2017-tsc --period 2026-Q3
```
GRC tools such as Vanta and Drata pull from a read-only service account with the compliance:read scope.
SIEM: send findings and audit events as OCSF to a signed webhook, or to Splunk, Elastic or Wazuh through their connectors.
Trust page: publish a page from controls you choose, with gated documents and access requests.

Protect public endpoints with Frazer Shield

Frazer Shield is the edge protection built into Frazer: network filtering, rate limits with bans, a WAF on the OWASP Core Rule Set, bot challenges and adaptive protection. Every gateway gets baseline protection: a managed rule preset, the network edge, default limits and threat lists. For more, write a security policy (projects/{project}/securityPolicies/{policy}) and attach it to a gateway, a load balancer, a serverless service or an address. Organization-level policies are evaluated first.

A policy is a list of rules by priority. Each rule matches source ranges, address groups, or a CEL expression over the origin (origin.ip, origin.region_code, origin.asn), the request (request.method, request.path, request.headers, request.query), TLS fingerprints (tls.ja4) and the token (token.org, token.principal_type), and takes an action: allow, deny (403, 404, 429 or 502), throttle, rate-based ban, challenge, redirect or log. WAF and threat-list rules use functions:

evaluatePreconfiguredWaf('sqli-v4252-stable', {'sensitivity': 2})
evaluateThreatIntelligence('iplist-tor-exit-nodes')

Rule sets come as -stable (the Core Rule Set’s long-term release) and -canary (its latest); sensitivity N is the rule set’s paranoia level N.

Preview first. A rule in preview logs what it would have done and enforces nothing.
Rate limits use windows of 10 to 3,600 seconds and up to 3 keys: IP (IPv4 /32, IPv6 /64), header, cookie, path, SNI, region, ASN, JA4, user IP or the token’s organization.
Adaptive protection, turned on per policy, learns a baseline per route. When traffic passes 5 times the baseline and the backend shows saturation, it proposes a rule with a confidence score; with auto-deploy on, the rule runs in preview for 60 seconds, enforces if it would block less than 1 % of baseline traffic, and is removed after its time to live (1 hour). Each case becomes a finding with a Block at edge action.
Attack mode is one audited switch per gateway or organization: it enforces adaptive rules, challenges unauthenticated HTML routes and tightens limits.
Bot challenges are a proof-of-work with a signed cookie; API tokens are never challenged.
Decisions land in your project’s logs: every deny and every preview match, and 1 % of allows. Every policy change is a plan.

Shield on gateways and load balancers: Load balancers.

Get notified

What	Who	How	When
Critical finding or attack sequence	Security contacts and the routed channel	Email and Slack or webhook; PagerDuty if configured	Immediately
High finding	Security contacts	Daily digest	09:00 in the organization’s time zone
Posture digest	Owners and security contacts	Email: score trend, new Critical and High findings, missed deadlines, top 3 fixes	Mondays
Account security events	The person	Email: a new device, two-factor changed, passkey added, token created, password changed, recovery codes used	Immediately
Organization security events	Owners	Email: owner added, SSO changed, kill switch used, break-glass kubeconfig downloaded, approval key changed	Immediately
Compliance	Compliance contacts	Email: a control failing for more than 24 hours, an evidence gap	Daily

Channels, routing, silences and maintenance windows are Frazer Monitoring’s; see Route alerts and run incidents.

Access and audit

Who	Can
Owners and admins	Everything in the Security area, for every project
Security admin (`roles/security.admin`)	Mute and accept findings, manage contacts and run response actions; change no resources
Audit viewer (`roles/audit.viewer`)	Read the Security area, and the evidence of an audit period in the auditor workspace
Project members	See their project’s findings; Developers can mute Low and Medium findings, with an expiry
Agents	Read through the `security` MCP toolset; response actions are write tools whose plan waits for a person’s approval

Response actions are operations that need a fresh second factor, and each leaves an audit entry. Accepting a Critical finding needs a second admin. Findings never contain secret values, and text that comes from your resources (pod names, log lines) is labeled untrusted for AI tools.

Retention. Findings are kept 400 days, runtime events 30 days (90 days when they are evidence of a threat), and evidence 3 years.

Limits and quotas

Item	Default
Mute or accept expiry, Critical and High	90 days at most
Attack-sequence window	24 hours
Secure score while a Critical finding is open	79 at most
Shield policies per project	10
Rules per policy	200
Rate-limit rules	50
Address-group entries	1,000
Auto-deployed adaptive rules	20
Request body inspected by the WAF	8 to 64 KB, per policy

Pricing

Security Center is included in every organization: posture, findings, vulnerabilities, threats, identity, data, and AI and agents, with nothing to activate. Compliance evidence export and the auditor workspace are part of the Business plan. Shield’s baseline protection is included on every gateway.

Security Center	On your servers	On the Frazer fleet
Price	Included in every organization	Business plan, with evidence export and the auditor workspace: $250 per organization / month

Every line, with the estimator: pricing.

Troubleshooting

Symptom	Cause	Fix
The overview shows a failing Critical control on a new organization	No verified security contact	Add and verify one in Security › Assurance › Settings
A finding stays open after you fixed it	Fixed is set by verification, never by a click; controls run on every relevant write and nightly	Check that the fix reached the resource (the plan applied, the pull request merged and synced); the finding closes at the next evaluation
A muted finding came back	Its expiry passed, or its context changed (the workload became public)	Fix it, or mute it again with a new reason
A critical CVE is not in Needs you	Priority needs the image to run and a fix to exist	Look in All open or Vulnerabilities; it rises when either changes
You cannot mute a Critical finding	Developers mute only Low and Medium findings	Ask a Security admin or an admin; accepting a Critical finding needs a second admin
Isolate asks for a second factor	Response actions need a fresh step-up	Confirm with your passkey or authenticator app
An external MCP server cannot be allow-listed	It is scanned before use, and again after its tool list changes	Read the scan result on AI and agents
Legitimate requests get 403 behind Shield	A WAF or rate-limit rule matches them	Find the rule in the decision logs in your project’s logs, put it in preview, add an opt-out or raise the threshold

Reference

CLI

Command	What it does
`frazer security findings list`	List findings, filtered by severity, project or kind.
`frazer security findings get`	Show one finding with its evidence; --path prints the attack path.
`frazer security findings mute`	Mute a finding with a reason and an expiry.
`frazer security controls list`	List controls, filtered by area and status.
`frazer security evidence export`	Export the evidence collected for a framework and a period.
`frazer security respond isolate`	Plan a quarantine of a workload; applying it needs a second factor.

All of them: CLI reference.

MCP tools

Tool	What it does
`list_findings`	List findings with their priority reasons.
`get_finding`	Get one finding with its evidence and fix.
`list_threats`	List runtime, account, agent and network detections.
`list_controls`	List controls with their mode, owner and status.
`explain_path`	Explain the attack path behind an exposure finding.

All of them: MCP tools reference.

Events

Event type	When it is sent
`frazer.finding.opened.v1`	A new finding was opened, or a muted one reopened.
`frazer.finding.resolved.v1`	A finding was verified as fixed.
`frazer.threat.detected.v1`	A runtime, account, agent or network detection was raised.

All of them: Events reference.

Security product page: how Frazer runs its own platform, and the documents behind it
Identity and access: roles, step-up, just-in-time access and the audit log
Frazer Monitoring: channels, routing and incidents
Load balancers: attaching Shield policies
Secrets: short-lived credentials and audited access
Webhooks and events: finding and threat events