Clear answers before you route real traffic.

Koreshield is a security decision and evidence layer for AI customer-support workflows. It checks untrusted material before it becomes trusted model context or an operational action.

Koreshield inspects customer input, retrieved context, and proposed tool actions before they become trusted behavior inside an AI workflow.

The best early fit is a team running, or preparing to run, an AI support workflow that reads customer content, retrieves private context, proposes actions, or touches operational tools.

A static FAQ bot, a team without a concrete AI workflow, or a buyer looking only for a compliance badge is not the right early fit. Koreshield is useful when there is real traffic, real context, and someone accountable for the risk.

No. Your application still owns identity, tenant boundaries, approvals, transaction limits, and business rules. Koreshield adds a security decision and evidence at the AI workflow boundary.

No. Add a direct scan before your provider call, or use a protected proxy route where that matches the application architecture.

No. Koreshield does not build the support agent for you. It sits beside the workflow you already own and helps decide whether input, context, or proposed action data is safe enough to continue.

No. Koreshield is focused on AI workflow trust boundaries. It is not a general web application firewall, identity provider, or broad API gateway replacement.

The current product focuses on customer input, retrieved context, and proposed actions. These are the places where untrusted text can quietly become trusted model behavior.

Your server sends customer-controlled text to Koreshield before the model call. Koreshield returns a decision, severity, confidence, indicators, and request evidence.

Your application scans selected RAG documents or chunks before prompt assembly. This helps catch indirect prompt injection or suspicious authority claims hidden in knowledge-base or ticket content.

Your workflow sends the tool name, arguments, and authorization context before executing the action. Koreshield can flag unsafe destinations, permission mismatches, approval-limit problems, or suspicious action context.

Yes. You can start with the boundary that matches your highest-risk workflow. Many teams begin with direct input scanning or retrieved-context scanning before adding action checks.

A decision should include whether the request is allowed, detected, or blocked, plus severity, confidence, indicators, mode, timing, and an event record that operators can review.

Start in detect mode beside representative traffic. Review decisions, misses, false positives, and latency before enforcing any boundary.

Detect mode records threats and evidence without interrupting the customer workflow. It is the safest way to learn how Koreshield behaves against your real support traffic.

Enforce mode stops requests that violate policy. It should only be enabled where your team has defined fallback behavior and understands what the customer or operator sees when a request is blocked.

Yes. Use representative benign and adversarial cases to validate the boundary before enforcement. The validation view is meant to make this repeatable.

Track misses, false positives, request latency, blocked-response behavior, operator review quality, evidence usefulness, and how much code the integration actually requires.

Your application should define retry and fallback behavior appropriate to its risk model. Do not assume bypass behavior exists unless your own application deliberately implements it.

Eligible new customers can activate one seven-day evaluation without a card. It includes 10,000 protected requests, 1 API key, and a 20-request-per-minute limit. Access locks if the evaluation ends without an active subscription, while existing evidence remains available.

A protected request is one metered unit of Koreshield inspection. Different endpoints can consume different units when they perform materially more work; the API response and dashboard should make usage visible.

Starter is for one AI support workflow moving from internal testing into measured production rollout. The current public plan lists 250,000 protected requests each month.

Growth is for teams operating production support workflows and reviewing security decisions together. The current public plan lists 2 million protected requests each month.

Current pricing is built around protected AI traffic rather than per-seat access. Role management and team workflows should still be validated for the customer's operating model.

No. Enterprise is a custom engagement because deployment, identity, retention, evidence export, support, and volume must be agreed for the actual environment.

Yes. Pricing has to match real customer value and operating cost. Published plan details are the source to use for self-service evaluation, while Enterprise is scoped directly.

No. Koreshield is one control in a broader security architecture. It should be validated against the customer’s real workflow and used alongside authorization, isolation, review, monitoring, and incident response.

No. Koreshield can support evidence, review, and data-minimisation workflows, but it is not a compliance certification and does not make an application GDPR, SOC 2, or ISO compliant by itself.

Retention depends on the endpoint, plan, and deployment model. The product should record enough operational and threat evidence to explain decisions without retaining unnecessary raw customer content.

If your workflow sends private support content for inspection, Koreshield processes that content as part of the request path. Sensitive deployments should confirm retention, region, subprocessors, and evidence-export requirements before rollout.

No. Retrieval permissions, tenant filtering, account authorization, and irreversible-action safeguards remain the customer's responsibility.

Detection quality varies by workload, policy, and attack family. Treat internal benchmarks as engineering signals, not contractual guarantees. Validate against your own traffic before enforcement.

The narrowest integration is a server-side scan call before an existing model or tool step. A production rollout takes longer because policy tuning, fallback behavior, validation, logging, and ownership need to be clear.

Self-hosted, VPC, and air-gapped deployments are Enterprise scopes. Availability depends on an agreed operating model for identity, updates, evidence, monitoring, and support.

Air-gapped deployment is an Enterprise option that must be scoped around image delivery, license handling, threat updates, provider connectivity, evidence retention, and support.

Keep Koreshield keys on your server or in your secret manager. Do not ship them in browser JavaScript, mobile clients, public repositories, or customer-visible configuration.

Create a new key, deploy it to the server-side integration, confirm traffic is using it, then revoke the old key. Multiple active keys make planned rotation possible.

The product direction includes structured evidence, event review, export, and alerting workflows. Treat each SIEM, webhook, or alert integration as something to validate for your environment.

Include the account email, endpoint, request ID if available, scan type, current mode, and a short description of the behavior you expected.

Keep the event evidence, explain why the request should have been allowed, and include sanitized context if possible. False-positive review is part of making enforcement safe.

Include the payload shape, scan type, expected decision, actual decision, and why the content should have been detected. Sanitized reproductions are more useful than screenshots alone.

Customer-facing docs should exist only where the product contract is ready. Internal API surfaces and operational notes should not be exposed as user documentation.