Detect first: rolling out AI security without breaking support

Why blocking on day one backfires

Support workflows accept attacker-controlled text, private retrieved context, and model-proposed actions. A security control at those boundaries is necessary, but a control that blocks before anyone understands the workflow will stop valid conversations, frustrate agents and customers, and get disabled under pressure.

The failure is rarely the detector alone. It is the missing calibration: nobody has looked at how real support traffic behaves, nobody has labelled what a false positive looks like, and nobody has decided what the customer should see when a request is stopped.

What detect mode actually does

Every Koreshield workspace starts in detect mode. Each check still runs and still returns a decision, severity, confidence, indicators, timing, and a request ID. The difference is that a risky request is recorded rather than stopped: the response can report would_block as true while blocked remains false, and the workflow continues.

That gives the team real evidence from real traffic without changing the customer experience. It also keeps the integration honest. A deployment toggle proves that a setting changed; detect-mode events prove that each boundary is actually being checked.

A rollout that is measurable

The recommended path adds one boundary at a time and treats enforcement as a decision the team earns, not a default.

• Add one boundary first, usually customer input or retrieved context.
• Run it in detect mode against realistic benign traffic and known-bad test cases.
• Review the events in the workspace console and label false positives and misses.
• Decide what the customer or operator sees when a request is stopped.
• Enable enforcement only for the boundary the team can support, then add the next one.

Design the fallback before you enforce

Enforcement without a fallback is an outage. Each boundary needs a customer-safe response that the team has chosen in advance.

Outage behaviour deserves the same care. A protection outage should not silently become an unrestricted path to refunds or payments, and it should not stop customers from asking where their order is. Input and context checks can often fail open for ordinary support, while consequential actions fail closed once enforcement is on. Make that choice per workflow, before launch.

• Input: route the request to manual review.
• Retrieved context: continue without the rejected source, or hand off to a human.
• Proposed action: do not execute the tool and require an authorized reviewer.
• Koreshield unavailable: apply the fail-open or fail-closed behaviour approved for that workflow.

Rollback is a mode switch, not a rip-out

If an enforcement policy blocks acceptable traffic, returning the boundary to detect mode is the immediate rollback. It does not require removing the integration or rotating the API key, so evidence collection continues while the policy is reviewed.

That is the point of detect first. The goal is not to block everything that looks suspicious. It is to learn the workflow, prove the decision quality, and then enforce the parts the team understands, while the application keeps ownership of authentication, authorization, and execution.