Find help, guides, and references.

The KoraSafe^™ Risk Assessment agent powers a multi-step analysis that classifies each AI system according to regulatory frameworks like the EU AI Act, NIST AI RMF, and ISO 42001. It synthesizes your answers, cross-references regulatory requirements, and delivers a cited risk classification in seconds.

How the assessment works: You answer a series of context-aware questions about your AI system's purpose, data inputs, autonomy level, deployment context, and affected population. The KoraSafe^™ Risk Assessment agent then runs a multi-step reasoning pipeline to produce a classification. The assessment typically takes 60 seconds or less to complete.

What questions are asked: Questions cover the system's use case domain (e.g., hiring, credit scoring, healthcare), whether it interacts with vulnerable populations, the type and sensitivity of data processed, the level of human oversight, and the deployment environment (internal vs. customer-facing).

Risk classification: Based on your answers, the system is classified into one of four risk tiers:

• Prohibited: Systems that violate fundamental rights (e.g., social scoring, real-time biometric surveillance in public spaces). These are flagged for immediate review.
• High Risk: Systems used in critical domains like employment, credit, law enforcement, or essential services. These require full documentation, human oversight plans, and ongoing monitoring.
• Limited Risk: Systems with transparency obligations, such as chatbots or emotion recognition. These need disclosure mechanisms and user notifications.
• Minimal Risk: Low-impact systems like spam filters or recommendation engines. Light documentation is recommended but not mandated.

Reports: After classification, KoraSafe^™ generates a detailed compliance report including the risk tier, rationale, applicable regulations, required actions, and a remediation roadmap. Reports can be exported as PDF for auditors and board review.

The AI Registry is your single source of truth for every AI system in your organization. It provides a centralized catalog with lifecycle tracking, risk metadata, and ownership assignment.

How to register AI assets: Click "Add AI System" from the Registry dashboard. Enter the system name, description, owning team, vendor (if third-party), deployment status, and data sources. You can also import systems in bulk via CSV or the MCP API.

Autonomy levels explained: Each registered system is tagged with an autonomy level that reflects how independently it operates:

• Level 0, Tool: Fully human-controlled, no autonomous decisions.
• Level 1, Assistant: Provides recommendations, human makes final decision.
• Level 2, Collaborator: Makes decisions with human oversight and approval gates.
• Level 3, Delegated: Operates autonomously within defined guardrails, escalates exceptions.
• Level 4, Autonomous: Fully autonomous with real-time monitoring and circuit breakers.

Fleet view: The fleet view provides a bird's-eye visualization of all registered AI systems, filterable by risk tier, autonomy level, department, status, and regulatory framework. Color-coded cards make it easy to spot systems that need attention.

Detail tabs: Each system's detail page has tabs for Overview (metadata and status), Risk Assessment (classification results), Governance (ownership RACI, maturity scores), Policies (active enforcement rules), Activity (audit trail of changes), and Compliance (checklist status and report history).

KoraSafe^™'s Governance module gives you full visibility into your organization's AI governance maturity across fairness, transparency, safety, privacy, accountability, and robustness.

Maturity radar: A spider/radar chart that visualizes your governance maturity scores across every dimension. Each area is scored from 0 to 5 based on the controls, processes, and documentation you have in place. The radar helps identify which areas are strong and where investment is needed.

Heatmap: The governance heatmap displays a cross-reference of AI systems against governance dimensions, color-coded by maturity. Red cells indicate critical gaps requiring immediate action, yellow indicates partial compliance, and green represents full maturity. This makes it easy to spot systemic weaknesses across your fleet.

RACI matrix: Define who is Responsible, Accountable, Consulted, and Informed for each governance activity. KoraSafe^™ generates a configurable RACI matrix for every registered AI system, ensuring clear ownership of risk management, monitoring, incident response, and compliance reporting.

Compliance checklists: Pre-built and customizable checklists aligned to the EU AI Act, NIST AI RMF, ISO 42001, and other frameworks. Each checklist item can be assigned to an owner, given a due date, and tracked to completion. Status is automatically reflected in your governance maturity scores.

Agent Evals: For agentic AI systems, KoraSafe^™ provides Enhanced Due Diligence (EDD) evaluations with multi-dimensional weighted scoring across autonomy, data sensitivity, decision impact, reversibility, and human oversight. Evals generate quantified risk profiles that drive enforcement policy recommendations.

The Enforcement module turns governance policies into active controls powered by KoraSafe^™'s Guardian agents. KoraSafe^™ PII Sentinel, Prompt Injection, Content Safety, Hallucination, Fairness, and Behavioral Drift each run continuously alongside your AI systems in real time.

Policy types:

• Input Filters: Validate and sanitize data before it reaches your AI system. Block PII from being sent to external LLMs, enforce data quality thresholds, and prevent prompt injection attacks.
• Output Filters: Scan AI outputs for hallucinations, bias indicators, toxic content, PII leakage, and off-topic responses. Non-compliant outputs can be blocked, flagged, or rewritten before reaching end users.
• Approval Workflows: Require human sign-off before high-stakes AI decisions are executed. Configure approval chains by risk tier, department, or decision type. Supports Slack, email, and in-app notifications.
• Circuit Breakers: Automatically pause or shut down an AI system when it exceeds predefined thresholds for error rate, cost, latency, or policy violations. Configurable cooldown periods and escalation paths ensure rapid incident response.

Violation management: Every policy violation is logged with full context: timestamp, system, policy triggered, input/output data, severity, and resolution status. The violations dashboard supports filtering, bulk actions, and trend analysis. Repeated violations automatically increase a system's risk score.

Guardian Agents: Specialized KoraSafe^™ agents that continuously monitor your AI fleet for specific risk categories. KoraSafe^™ ships with six built-in Guardians: PII Sentinel (detects and prevents personal data exposure), Prompt Injection (detects prompt manipulation), Content Safety (enforces output policy), Hallucination (catches factual inaccuracies), Fairness (monitors for discriminatory patterns), and Behavioral Drift (flags runtime behavior anomalies). Each Guardian can be configured with custom thresholds and response actions.

KoraSafe^™ routes your questions to the right specialist agent and brings back one clear answer.

How to use KoraSafe^™: Click the KoraSafe^™ icon in the bottom-right corner of any page, or press Ctrl+K (Cmd+K on Mac) to open the assistant. Type your question in plain English and KoraSafe^™ will respond with relevant guidance, links to documentation, and actionable next steps.

What KoraSafe^™ can answer:

• Regulatory questions: "What does Article 6 of the EU AI Act require?" or "Does NIST AI RMF apply to my chatbot?"
• Platform guidance: "How do I set up a circuit breaker?" or "Where can I see my compliance checklists?"
• Risk interpretation: "Why was my system classified as high risk?" or "What steps lower my risk score?"
• Best practices: "What governance controls should I have for an autonomous agent?" or "How often should I re-assess risk?"

Agent network scope: KoraSafe^™'s agents draw on the full text of major AI regulations (EU AI Act, NIST AI RMF, ISO 42001, OECD AI Principles), KoraSafe^™'s product documentation, your organization's registered AI systems and governance data, and industry best practices for responsible AI deployment. KoraSafe^™'s agents do not have access to your production AI system data or end-user interactions.

Enterprise security runs through every KoraSafe^™ layer, with fine-grained access controls and complete audit trails.

SSO/MFA setup: KoraSafe^™ supports SAML 2.0 and OIDC-based Single Sign-On with any enterprise identity provider that speaks either protocol. Navigate to Settings > Authentication to configure your identity provider. Multi-factor authentication can be enforced organization-wide or per role, supporting authenticator apps, SMS, and hardware security keys.

User management: Invite users by email or sync from your identity provider. Assign roles (Admin, Governance Lead, Analyst, Viewer) that map to granular permissions. Role-based access control (RBAC) ensures users only see systems and data relevant to their department and responsibilities.

API keys: Generate scoped API keys from Settings > API to integrate KoraSafe^™ with your CI/CD pipelines, internal tools, or agent frameworks. Each key can be restricted by permission scope (read, write, admin), IP allowlist, and expiration date. All API activity is logged.

Audit logs: Every action in KoraSafe^™ is recorded in a tamper-evident audit log: user logins, configuration changes, assessment completions, policy modifications, and data exports. Logs are searchable by user, action type, resource, and date range. They can be exported to your SIEM or compliance archive.

Multi-tenant isolation: Each organization's data is logically isolated with dedicated encryption keys. Tenant boundaries are enforced at the database, API, and application layers. Cross-tenant data access is architecturally impossible. KoraSafe^™ supports sub-tenants for enterprise customers with multiple business units that need independent governance workflows while maintaining a unified executive view.

KoraSafe^™ governs your AI fleet. Risk assessment, policy enforcement, regulatory tracking, all in one place.

The risk assessment asks a series of targeted questions about your AI system's purpose, data inputs, deployment context, affected populations, and autonomy level. Based on your answers, it applies regulatory mapping logic aligned with the EU AI Act, NIST AI RMF, and other frameworks to classify the system into a risk tier (Prohibited, High, Limited, or Minimal). The entire process takes about 60 seconds and produces a downloadable compliance report with specific recommended actions and a remediation timeline.

KoraSafe^™'s regulatory catalog covers the EU AI Act, NIST AI Risk Management Framework (AI RMF), ISO/IEC 42001, OECD AI Principles, the White House Executive Order on AI, and sector guidance from the FCA, OCC, FDA, and CMS. Audit packages currently ship for the EU AI Act, GDPR, SOC 2, and NAIC; HIPAA and additional framework packs follow as sector demand drives them. The Regulatory Intelligence module continuously monitors global AI regulation developments and updates compliance checklists as new requirements emerge. You can also create custom compliance frameworks for internal policies.

Guardian Agents are specialized AI monitors that run continuously alongside your AI systems. Each Guardian focuses on a specific risk category: PII Sentinel detects personal data in inputs and outputs, Prompt Injection catches prompt manipulation, Content Safety enforces output policy, Hallucination validates factual accuracy against trusted knowledge bases, Fairness monitors for discriminatory patterns, and Behavioral Drift flags runtime behavior anomalies. When a Guardian detects a violation, it can log it, alert the responsible team, flag the output for review, or block the response entirely, depending on your configuration. Guardians learn from your feedback to reduce false positives over time.

Yes. KoraSafe^™ enforces enterprise-grade security at every layer. All data is encrypted at rest (AES-256) and in transit (TLS 1.3). Each organization is logically isolated with dedicated encryption keys, and cross-tenant access is architecturally impossible. KoraSafe^™ supports SSO via SAML 2.0/OIDC, enforces MFA, and provides role-based access control with granular permissions. Every action is logged in a tamper-evident audit trail. KoraSafe^™ does not use your data to train AI models. EU data residency is on the roadmap.

The MCP (Model Context Protocol) API enables agent-to-agent governance. It allows your AI agents to programmatically check policies, request approvals, report actions, and receive guardrails from KoraSafe^™ in real time. For example, an autonomous agent can call the MCP API before executing a high-stakes action to verify it complies with your governance policies. If the action is flagged, the agent receives instructions to escalate to a human or modify its approach. The MCP API is RESTful, supports webhooks for event-driven workflows, and includes SDKs for Python, TypeScript, and Go.

Compliance reports can be exported from several locations in the platform. After completing a risk assessment, click "Export Report" to download a PDF. From the Governance dashboard, use the "Export" button to generate a full governance maturity report across all registered systems. Individual system detail pages also have export options for system-specific compliance documentation. All reports are formatted for board-level presentation and regulatory submission, including executive summaries, risk classifications, control mappings, and action items with owners and deadlines.

KoraSafe^™ classifies AI agents on a five-level autonomy scale that determines the governance controls required. Level 0 (Tool) systems are fully human-controlled. Level 1 (Assistant) systems provide recommendations but humans decide. Level 2 (Collaborator) systems make decisions with human approval gates. Level 3 (Delegated) systems operate autonomously within defined guardrails, escalating exceptions. Level 4 (Autonomous) systems operate fully independently with real-time monitoring and circuit breakers. Higher autonomy levels automatically trigger stricter governance requirements, more frequent evaluations, and more sensitive enforcement policies.

Each organization in KoraSafe^™ operates within a fully isolated tenant boundary. Isolation is enforced at three layers: the database layer (separate schemas with dedicated encryption keys), the API layer (tenant-scoped authentication tokens), and the application layer (tenant context verified on every request). No query or API call can ever access data belonging to another tenant. For enterprise customers with multiple business units, KoraSafe^™ supports sub-tenants that maintain independent governance workflows and data isolation while providing a unified executive dashboard for organization-wide visibility.

Yes. KoraSafe^™ is designed to fit into your existing stack, not replace it. The REST API and MCP API support programmatic access to all platform capabilities. Webhooks can push events (new violations, assessment completions, policy changes) to any HTTP endpoint. Custom integrations can be built using the API SDKs available in Python, TypeScript, Go, and JVM (Java + Spring Boot + Quarkus).

The BAA framework is in development, targeted alongside SOC 2 Type I completion. PHI minimum-necessary detection grounded in §164.502(b) and HIPAA-aligned governance evidence packages ship today. Email Contact-us@korasafe.ai to discuss your covered-entity needs and timeline. See trust-security for the canonical disclosure.

The auditor portal lets external auditors review evidence under a time-boxed magic-link invitation, without provisioning a full platform account. Each invitation carries an eight-hour session token and a ninety-day access window. Evidence packets are JWS-signed so an auditor can verify integrity offline. Phase 1 shipped with single-customer engagement scope; Phase 2A then added multi-customer engagements (one auditor-firm grant spans multiple customer orgs, cross-tenant RLS enforced). Auditor-firm SSO follows in Phase 2B once a Big 4 IdP onboards. See trust-security for the canonical disclosure.

Peer benchmarking is opt-in. Once an organization opts in, KoraSafe^™ joins your fleet to an anonymized cohort defined by sector, organizational size band, and region. Cohort signals (governance maturity, finding rates, control coverage, remediation close rate) are released only when the cohort meets a k-anonymity threshold (the default is k≥5). You can withdraw consent at any time. Currently in Preview distribution. See product/peer-benchmarking.

Yes. The HIPAA evidence package bundles PHI-handling evidence, minimum-necessary detection logs grounded in §164.502(b), access logs, and breach-notification readiness artifacts into one downloadable package. Export from the admin compliance surface or via the /api/v1/audit-package endpoint. The BAA framework that wraps the engagement is in development; package contents are available today.

Yes. Each organization sets its own retention windows for findings, audit logs, and evidence packets, bounded between thirty and three thousand six hundred fifty days. Defaults are three years for findings, seven years for evidence packets, and a per-org default for audit logs. Configure from the admin data-retention surface. See trust-security for the configurable retention card.

The weekly governance digest is an email summary of the prior week's regulatory deltas, finding velocity, and policy-status changes for the systems your organization owns. Routing follows the responsibility matrix: each owner receives a digest scoped to the systems they're accountable for, plus a fleet-level rollup for the GRC lead. Subscribe and configure cadence from the admin notifications surface.

The admin compliance surface includes a BAA tracking workspace. Add each vendor counterparty with scope of PHI, signature date, renewal date, and active status. Automated alerts fire ahead of renewal dates, and every state transition writes an audit entry. Coverage maps to HIPAA §164.314(a)(1) organizational requirements. The KoraSafe^™-as-vendor BAA itself is a separate workflow. Email Contact-us@korasafe.ai for that conversation. See solutions/healthcare for the canonical disclosure.

The platform exposes an agent status surface listing every edge agent registered to your organization, with last-seen timestamp, cert serial, and a connected / stale / offline indicator. Connected means a heartbeat in the last five minutes; stale means five to sixty minutes; offline means longer or never. Backend telemetry is live; the operator UI is in Preview rollout. The customer-cloud edge agent runs in your Kubernetes cluster with per-tenant mTLS credentials.

Yes. Every finding now carries a control_ref_id pointing to the specific regulatory article that triggered it. Open a finding and follow the trace chain back through the control mapping, the obligation, and the source article. Auditors asking "which regulation drove this finding?" get a deterministic answer with the source span attached. Applies to all findings written after the unified findings spine landed.

Yes. Org-level defaults still apply, but each department can override them: notification routing, retention windows, role assignments, and policy scope. Department overrides cascade down the hierarchy, with explicit visibility on what's inherited versus locally set. Configure from the admin organization surface. Useful when one regulated business unit needs stricter rules than the rest of the company.

Default per-org rate limits cover most workloads. If your integration patterns need a higher ceiling, an admin can request an override from the admin API surface. Overrides apply per token kind (read, write, MCP), and a 429 response includes a Retry-After header indicating the backoff window. We tune ceilings against actual usage rather than blanket increases. Email Contact-us@korasafe.ai if you hit the default ceiling repeatedly.

Two refresh paths run in parallel. Event-driven recompute fires on every relevant change (new finding, autonomy update, drift signal, control attestation). A quarterly recompute also runs on a fixed schedule (January, April, July, October), so portfolios with quiet quarters still produce a fresh score at boardroom cadence. The governance index runs the same dual rhythm, with weights and methodology version pinned per snapshot for replay.

Open an auditor portal Phase 2A multi-customer engagement from the admin auditor surface. POST /api/auditor/engagements with the auditor firm id, the customer-org ids, and a window. The firm sees every engagement packet they've been granted across customers inside one magic-link session. Cross-tenant RLS guarantees an auditor browsing customer A's evidence can never see customer B's without an explicit grant. Auditor-firm SSO follows in Phase 2B once a Big 4 IdP onboards. See trust-security for the canonical disclosure.

Today you poll GET /api/governance-events with optional filters (event_type, finding_id, limit up to 100). Each event records a state change worth reacting to: a finding state transition (open becoming resolved, for example), a risk score crossing a threshold, an attestation lapsing. The payload includes score_before, score_after, trigger_reason, and the source_table + source_id pointer. Webhook fan-out is in development; once it ships you'll register an HTTPS target with optional event-type filter and KoraSafe^™ will POST each matching event with an HMAC-SHA-256 signature. See technology/api for the endpoint card.

Both pull from the same audit-package endpoint (POST /api/admin/compliance/audit-package). The pack value selects the bundled evidence shape: hc-us assembles HIPAA evidence (PHI minimum-necessary findings, BAA roster, breach-notification readiness, §164.502(b) detection logs) and renders against HIPAA citation patterns. fin-us assembles NAIC Model Bulletin + SR 11-7 + ECOA evidence (vendor attestations, adverse-action records, model-risk approvals, fairness findings) and renders against NAIC + SR 11-7 citation patterns. Both default to JSON; pass format=pdf for the regulator-readable PDF. Same date-range and org-scope rules apply.

Guardian findings carry a control_ref_id pointing to the regulatory article that triggered them. That's the unified findings trace-chain spine. The HIPAA-specific consumer that maps findings against §164.502(b), §164.308, §164.310, and §164.312 citations is in development; once it ships, the audit-package hc-us variant will surface each finding under the §-citation that governs it. Until then, hc-us audit packages cite HIPAA at the obligation level using the existing control mappings. The finding-by-finding §-citation depth is the next increment.

An independent security review across the platform's public schema completed on 2026-05-11 with zero P0 findings. Every table enables row-level security in the same file it's created. No permissive USING(true) on write-path policies. Functions declare SET search_path = public, pg_catalog, pg_temp. Views run WITH (security_invoker = true). Materialized views are revoked from anon and authenticated by default. Scope of the audit is the public schema; the korasafe_edge schema RLS retrofit is tracked separately and in progress. See trust-security for the canonical card.

Sector packs are pre-built manifests that bundle the obligations, policy templates, autonomy archetypes, and Guardian defaults for a specific industry or jurisdiction. Seven packs publish today: Financial Services US, Healthcare US, Insurance US, SaaS / Tech, Public Sector US, UK General, and EU General. Each pack ships with 17 to 20 mapped obligations and is version-pinned so attestation windows are stable. See sector packs for the catalog.

Open the pack from /packs, review the obligation and template list, then click Subscribe. The subscription record captures the pinned version, the enforcement level (warn or block), and the surfaces the pack drives (policies, findings, evidence). Admin self-serve subscription is in Preview; cohort customers get a hands-on first subscription with their named contact. The /admin/sector-packs page shows every subscription in one place.

Yes. Customizations land in tenant-scoped overrides that sit alongside the pack manifest, not inside it. You can amend policy templates, add or rename autonomy archetypes, and adjust enforcement levels per surface. Overrides persist across pack upgrades so the next pinned version inherits your edits. Pack-author self-serve editing (drag-and-drop manifest editor, schema validation) is on the roadmap; today, customizations route through the admin override surfaces.

When KoraSafe^™ Research ships a new pack version, your subscription stays on the pinned version until you accept the upgrade. The /admin/sector-packs/[pack] page shows the diff (added obligations, retired policies, changed thresholds), preserves customizations, and surfaces any policy templates that need re-review before they go live. Auto-update is opt-in per pack so attestation windows stay stable.

Every detection finding lands in the unified findings inbox at /findings. Findings from PII Sentinel, Prompt Injection Guard, Content Safety Monitor, Hallucination Detector, Fairness Watchdog, and Behavioral Drift Detector all flow through one queue. You can filter by Guardian, severity, status, system, or affected obligation. Bulk acknowledge, assign, and resolve actions all work across Guardians.

Each finding carries a control_ref_id pointing back to the regulatory article, section, or control that triggered it. The reference makes the finding evidence-grade: when you compile an audit package, the finding appears under the obligation it answers, not as a free-floating alert. Findings without a control reference get tagged for editorial review before they reach audit-grade surfaces.

Severity (critical, high, medium, low) is set by the originating Guardian based on the detector's calibrated rules, the regulatory weight of the matched control, and the system's risk tier. Critical findings route to the on-call workflow with policy-controlled escalation; lower-severity findings batch into the digest. You can override severity per finding from the detail page; overrides log to the audit trail.

Shadow AI discovery surfaces AI tools and dependencies as developers commit code. The first wave covers code workspace scans (VS Code extension plus on-demand repo scans) and browser discovery. Each candidate carries the file path, commit reference, and matched span back to the source so an owner can be assigned with full context.

The VS Code extension watches the workspace for imports, dependencies, and configuration that indicate AI usage. It runs entirely on the developer's machine; nothing leaves the perimeter except the structured candidate record. The extension ships through the Preview install track today; the Visual Studio Marketplace listing follows once the security review closes. Pre-launch inline warnings for in-development AI code flow through the same extension. See the VS Code extension page for capabilities and the command palette reference.

The JetBrains extension brings the same workspace AI discovery, governance context, and inline registration prompts to IntelliJ IDEA, PyCharm, WebStorm, GoLand, RubyMine, and AppCode. Local analysis runs by default; any cloud check is opt-in and gated by an explicit consent prompt before the first call. The extension ships through the Preview install track today; the JetBrains Marketplace listing follows once the security review closes. See the JetBrains extension page for IDE coverage and install steps.

The Chrome extension is a Manifest V3 browser extension that records access to supported AI tools on company devices, shows governance context in a side panel, and routes findings back to the platform. It surfaces shadow AI use that escapes code-workspace and identity-source discovery. The extension ships through the Preview install track today; the Chrome Web Store rollout follows once the install path settles and the security review completes. See the Chrome extension page for the supported AI-tool catalog and the side-panel reference.

All three extensions are in Preview. Until the marketplace listings land, install from the GitHub release artifact. For VS Code, download the latest .vsix from korasafe/vscode-extension and run Extensions: Install from VSIX... in the command palette. For JetBrains, download the latest .zip plugin from korasafe/jetbrains-extension and use Settings → Plugins → Install Plugin from Disk. For Chrome, download the latest .zip from korasafe/chrome-extension, unpack it, open chrome://extensions, enable Developer mode, and load the unpacked folder. After install, run KoraSafe™: Set API key (VS Code / JetBrains) or sign in through the side panel (Chrome) to authenticate with your KoraSafe^™ organization.

None of the extensions transmit prompt text or LLM response bodies. The VS Code and JetBrains extensions emit a structured candidate record (file path, commit reference, matched span, dependency name and version) when a workspace AI signal fires. The Chrome extension emits a structured browser-event record (visited host, user identity, access timestamp) when an opt-in side-panel signal fires. All three extensions support working offline; events buffer locally and replay when the connection returns. Per-extension privacy policies live at /privacy/vscode-extension, /privacy/jetbrains-extension, and /privacy/chrome-extension with the full data inventory.

Each marketplace runs its own security review on its own timeline. VS Code lands on the Visual Studio Marketplace, JetBrains lands on the JetBrains Marketplace, and Chrome lands on the Chrome Web Store. All three submissions are staged and pending publisher action. Once a marketplace approves, the corresponding extension page (/vscode-extension, /jetbrains-extension, /chrome-extension) updates with an install link, and the homepage extensions section flips its install path. Until then, the Preview install track on GitHub is the supported route.

The library is a hand-curated catalog of AI products that the platform recognizes by name, vendor, and rough risk band. Every entry carries a citation URL to the vendor's public docs so claims are verifiable. KoraSafe^™ Research reviews the library monthly on the first Monday of each calendar month. See the KoraSafe^™ Research feed for delta summaries.

Yes. The edge agent runs as a containerized component inside the customer's network, terminating mTLS against the KoraSafe^™ control plane. It carries findings without exposing raw data; redaction outputs route through the customer-cloud redaction pipeline. Operator topics (cert provisioning, cert expiry alerts, rate limits, log shipping) live in the operator runbook. Status and reconciliation events flow into /admin/edge-agents.

Native telemetry is KoraSafe^™'s own classifier-and-metrics layer that runs alongside, not instead of, the partner detectors you already use. The current phase publishes hit-rate metrics, classifier precision and recall, and a preview-only telemetry banner that calls out which signals are emitted live versus in development. The full ingest pipeline lands across the cohort; until then, in-app surfaces tag native-telemetry-only metrics with an "in development" label so customers do not mistake them for partner-derived signals.

KoraSafe^™ is federated, not replacement. The native classifiers cover gaps where customers do not already run a partner detector for a domain. Where you do run a partner detector (Presidio for PII, for example), the partner remains the source of truth; native classifiers add their signal alongside. The native classifiers methodology page publishes the calibration approach and the published precision and recall figures.

Per-Guardian dashboards surface the live signal counts, severity splits, and trend data. Fleet-wide telemetry rates show up in the governance index time series. Customers wired to the API can pull metrics through /api/telemetry endpoints. Metrics tagged as in-development carry the preview banner; metrics labeled live read directly from production ingest.

Provenance captures the lineage of a deployed model: training data attestations, base model and fine-tune chain, version-pinned weights, and the rollout decisions tied to that version. Each step is recorded as an immutable provenance event with the actor, timestamp, and signed input hashes. The provenance history endpoint exposes the chain for evidence packages and auditor review.

The model SBOM enumerates the base model, fine-tune adapters, retrieval data sources, embedding model, evaluation harness, and the runtime libraries the system depends on. Each component carries its provider, version, and license. SBOMs publish in CycloneDX format alongside the human-readable view on the system detail page. Customers can attach their own SBOM extensions for proprietary components.

Open the system detail page and click Provenance to see the full event chain. The same data backs the /api/provenance/[system]/history endpoint for programmatic access and the auditor portal's signed evidence packets. Each event is hash-linked to the prior event so a missing entry is detectable in audit.

When two or more frameworks place conflicting obligations on the same control point, the conflict resolution queue surfaces the overlap with a recommended posture: stricter-of-the-two, jurisdictional-priority, or escalate-to-editorial. Customers see the queue at /admin/conflicts and can accept the recommendation or open a Lead-routed escalation. See conflict resolution for worked examples.

The org admin owns the final call inside the org's tenant. KoraSafe^™ Research provides a recommended posture with the regulatory rationale, but the org admin records the accepted resolution and the rationale they relied on. Editorial-grade conflicts (genuine framework ambiguity, new guidance pending) escalate to KoraSafe^™ Research who publish a methodology note.

The /product/policy-control page carries three worked examples covering HIPAA versus EU AI Act minimum-necessary tension, GDPR Article 22 versus US fair-lending disparate-impact testing, and state AI disclosure laws stacked on top of NAIC Model Bulletin. Each example shows the queue entry, the recommended posture, and the evidence trail.

Open /admin/auditor-engagements and create an invitation with the auditor's email, the engagement scope (which packs, systems, or evidence ranges), and the magic-link expiry window. The auditor receives a JWS-signed magic link that opens the auditor portal in read-only mode. Every action the auditor takes (packet view, attestation download, comment) logs to the engagement audit trail.

Magic link expiry defaults to eight hours from issuance; the org admin can override to anywhere from one hour to thirty days when creating the engagement. The underlying engagement window defaults to ninety days; sessions expire on either limit, whichever hits first. Revoking the engagement from the admin page immediately invalidates every active session. See auditor portal for the lifecycle dash.

An evidence packet bundles the governance snapshots, findings, attestations, policy versions, and provenance events for the engagement scope at a specific point in time. The packet is JWS-signed by the originating organization; the auditor portal verifies the signature on load and surfaces the verification status. Packets are immutable; new evidence ships as a fresh packet linked to the prior one through a verifiable chain.

Yes. Phase 2A multi-customer engagements are live: each invited auditor gets their own magic link, their own session, and their own audit-trail attribution. Phase 2B (auditor-firm SSO so a firm's auditors can share a single identity provider) follows once partner SSO integration closes review. The /admin/auditor-engagements view shows every invitation, session, and attestation across a single engagement.

The change-event timeline runs daily; the editorial review queue averages under twenty-four hours for major changes. The framework catalog refreshes continuously as primary law and regulator guidance publish. The KoraSafe^™ Research weekly feed at /intel/research translates Tier 3 sources (speeches, FAQs, informal guidance) into concrete customer actions. Tier 4 customer-flagged signals route through /intel/signals.

Email and webhook delivery are live per system today. Jira delivery is live with the standard issue-create template. Slack alerts currently route through the KoraSafe^™ notification channel; per-org Slack workspace integration ships once org-specific webhooks land. Configure delivery preferences from /alerts/preferences; severity-based digesting groups lower-severity alerts so the inbox stays readable.

Dry-run runs a parameterized simulation of the policy against synthetic scenarios and staging gateway log samples before promoting the policy to enforcement. Results show what the policy would have blocked, warned, or allowed and surface any unintended side effects. Promotion, compile, and rollback ship after Preview; today, dry-run answers the "will this policy break production" question on the authoring page.

Per-system adaptive risk updates daily, with on-demand recompute available from the system detail page when you need an immediate score for a board prep or an incident review. The governance index aggregates risk across the fleet on a quarterly snapshot cadence so attestation-grade scores remain stable across the quarter. Both surfaces show the "as of" timestamp so customers can audit the freshness of any quoted score.

The governance index surfaces a framework only when a real scorecard exists for it. EU AI Act, NIST AI RMF, ISO 42001, and SOC 2 Type I read live today. HIPAA, GDPR, and SOC 2 Type II surface as "not yet measured" or "in progress" until the rubric or attestation lands; the page shows the honest status rather than a placeholder zero. The governance index methodology publishes the full rubric.

Peer benchmarking is opt-in only. Cohorts are anonymized through HMAC-SHA256 hashing of the org identifier with a server-side secret salt; aggregates release only when the cohort clears k-anonymity (k greater than or equal to 5). No raw peer values are ever exposed; quantiles (p25, p50, p75) carry the cohort distribution without revealing individual contributions. A differential privacy noise layer is on the roadmap for the Scale phase; until then, k-anonymity is the binding guarantee. The peer benchmarking methodology publishes the full design.

Pricing is seat-based, scaled by the number of AI systems under governance and the features active in your subscription. Plans are scoped through guided evaluation; email Contact-us@korasafe.ai for a quote. Evaluation participants receive contract terms matched to deployment scope and onboarding needs.

Evaluation access is a guided proof of concept: you get platform access, direct onboarding support from the team, and a scoped success plan. To apply for evaluation access, email Contact-us@korasafe.ai with your company name, AI fleet size, and the primary regulation you're working toward.

Preview agreements run on a month-to-month basis with a standard thirty-day notice window. Annual contracts with enterprise SLA addenda are available on request. Volume discounts apply at 25+ AI systems and at the enterprise seat tier. Contact Contact-us@korasafe.ai for the commercial terms sheet.

KoraSafe^™ runs as a managed cloud service today. The Bring-Your-Own-Cloud (BYOC) deployment, which lets you run the control plane inside your own AWS or Azure tenant, is in development. Air-gap and FedRAMP-Ready deployments follow for regulated government and financial-services customers. The edge agent, which ships telemetry from your Kubernetes cluster to the platform, is already available for all deployment types.

The platform targets 99.9% monthly uptime for the managed cloud service. Maintenance windows are scheduled outside peak hours (UTC) and announced at least forty-eight hours in advance through the platform notification surface and status feed. During Preview the SLA carries a best-effort commitment; formal SLA credits apply from the GA contract tier. See trust-security for the canonical status and incident history.

Preview customers receive a guided onboarding session within the first week, covering AI inventory import, risk assessment configuration, and the first Guardian deployment. The help center (this page) and the product docs cover self-service flows. The team is available directly at Contact-us@korasafe.ai for configuration questions, policy authoring help, and regulatory interpretation guidance. Formal implementation services launch with the enterprise tier at GA.

The managed cloud service currently runs in the US (AWS us-east-1) with a replicated standby. EU data residency, which pins your org's data to an AWS eu-west-1 region with no US transit, is in development alongside the GDPR data-processing addendum. Customers with strict residency requirements should email Contact-us@korasafe.ai to discuss BYOC, which lets you host the control plane in your own region.

SOC 2 Type I preparation is underway; Type II follows. A third-party penetration test is planned. Customers requiring a security questionnaire response today can email Contact-us@korasafe.ai; the team can share the current control inventory and the trust-security disclosure. See trust-security for the live security posture card.

The full sub-processor list with roles and data locations is published in the Data Processing Agreement. Anthropic processes prompt content only for KoraSafe^™'s internal AI reasoning; no customer governance data is stored or used by Anthropic for model training.

No. KoraSafe^™ does not use customer governance data, system metadata, findings, or evidence packets to train any AI models. The Anthropic API calls that power KoraSafe^™'s reasoning pipeline run under a commercial API agreement that excludes customer data from Anthropic's training corpus. The peer benchmarking feature aggregates anonymized signals, but only in opt-in cohorts and only at k-anonymity-protected quantile level, never at the individual-org level.

KoraSafe^™ follows a documented incident response process: detect, contain, assess, notify, remediate, and postmortem. Customers are notified within seventy-two hours of a confirmed incident affecting their data, consistent with GDPR Art. 33 notification timelines. The notification includes the scope, type of data involved, and immediate remediation steps taken. Incident history and status are posted to the platform status feed. See trust-security for the current incident record.

Yes. The platform exports your full governance data on demand, including the AI system registry, all risk assessments, findings, policy definitions, evidence packets, and audit logs. Exports are in JSON (machine-readable) and CSV (spreadsheet-ready); PDF board packs are separately downloadable from the governance surface. Data export triggers through the admin compliance surface or via the API. On contract termination KoraSafe^™ retains your data for sixty days for retrieval, then deletes it per the retention policy.

The primary users are the GRC (governance, risk, and compliance) team who own AI policy and regulatory filing, AI engineering leads who manage the system registry and Guardian configuration, legal and privacy counsel who monitor regulatory changes, and internal audit who use the external auditor portal. The RACI matrix surface lets you assign system ownership and accountability across all these roles in one place, so each team sees only the scope they're responsible for.

Named users with full platform access count as seats. Read-only stakeholders (e.g. board members viewing a governance report link) are not counted as seats. External auditors using time-boxed magic-link invitations also do not consume seats. Pricing tiers are structured so smaller GRC teams can start with 5 seats and expand as adoption grows. Contact Contact-us@korasafe.ai for current seat minimums during Preview.

Enterprise plans include a separate sandbox tenant pre-seeded with synthetic data, so teams can test policy configurations, Guardian thresholds, and integration webhooks without affecting their production governance record. During Preview, sandbox environments are provisioned on request. Email Contact-us@korasafe.ai with your use case and the team will spin one up within twenty-four hours.

Yes. The policy plane lets you write custom policies from scratch or start from a sector-pack template. Custom frameworks (for internal AI ethics standards, for example) can be created in the regulatory catalog and used alongside the built-in frameworks. Custom Guardian rules, which fire on your own trigger conditions, are available in the policy authoring surface. Policies export as versioned JSON for git-based review workflows.

Not in the current release. White-label and OEM embedding, where KoraSafe^™'s governance layer runs under a partner's brand, is handled through partner-scoped evaluation. Consulting firms and SI partners who want to resell KoraSafe^™ as part of an AI governance practice can apply through Contact-us@korasafe.ai; the partner program is in early design.

KoraSafe^™ does not build, host, or run AI models on your behalf. It governs AI systems you already own or procure. It is not a legal advice service; regulatory intelligence is informational and should be reviewed by qualified counsel before regulatory filing. It does not replace model cards, datasheets, or model-level technical safety evaluations, though it can ingest outputs from those processes as evidence. Integration with AI security red-teaming tools is on the roadmap, not yet shipped.

In a change-of-control event, customers are notified within thirty days and may terminate the agreement and export all data within a sixty-day window without early-termination penalty. The data processing agreement carries through to any acquirer for the duration of the notice window. Commercial contract terms and data commitments are not unilaterally amended mid-term. Email Contact-us@korasafe.ai for the full DPA clause language.

Yes, with prior written authorization. Email Contact-us@korasafe.ai with your pentest vendor, scope (your org tenant only), IP ranges, and planned window. Destructive tests (DoS, credential stuffing at scale, or cross-tenant probing) are not permitted. KoraSafe^™'s own third-party pentest is in planning; the resulting summary report will be available under NDA to enterprise customers.

KoraSafe^™'s evidence packages are structured to map directly to the documentation requirements of the EU AI Act regulatory sandbox scheme (Art. 58), including technical documentation, risk classification, and control evidence. The Omnibus amendment (May 2026) extended sandbox deadlines to Aug 2, 2027. To use KoraSafe^™ as your sandbox documentation backbone, export the relevant evidence packet from the admin compliance surface and attach it to your sandbox application. The team can advise on which controls to prioritize; email Contact-us@korasafe.ai.