Koreshield

Koreshield is a runtime trust control layer for AI support workflows. It exists to stop untrusted customer content from becoming trusted instructions inside an AI workflow, and it is built for the teams that run AI support agents, including the engineers and security reviewers responsible for what those agents read and what they do. The product states the problem plainly: every AI support agent takes input from someone it should not trust, namely the customer message, the documents it retrieves, and the tool calls it proposes. Koreshield screens all three of those boundaries before they become trusted model behavior or application execution, so that data leaks, hidden instructions in help articles, policy drift, and unsafe agent actions are checked before the model acts. Rather than replacing the model or the authorization system, it sits beside the workflow as a decision point that produces a recorded reason for each decision. The underlying problem is a question of trust inheritance. A support agent is designed to be helpful, and helpfulness means treating the text it receives as usable input. But the customer message is written by someone outside the organization, and retrieved documents such as help articles, CRM notes, and ticket comments are not always written or edited by people with the system's interests in mind. When that text is folded into a prompt, it can inherit authority it never earned. Hidden instructions buried in a help article, a poisoned ticket, or a crafted customer message can quietly steer the model, and policy drift or unsafe agent actions can follow. Koreshield frames this as trust handoffs: one request passing through three places where trust can fail. The value of catching those failures at the boundary, before the model acts, is that the decision remains a controlled one rather than an after-the-fact investigation. The first boundary Koreshield evaluates is customer input. It inspects messages, attachments, and externally controlled text before model execution. In a support workflow, the customer message is the most obviously untrusted element, yet it is also the element the agent is most eager to act on. Koreshield evaluates this boundary independently of the other two and records the reason for its decision, so a reviewer can see what was flagged and why. Because the inspection happens before model execution, suspicious input never reaches the point where it could be treated as a system-level instruction. The coverage of externally controlled text means the same boundary applies whether the incoming content is a plain customer message or something attached to it. The second boundary is retrieved context. Koreshield keeps poisoned tickets, CRM notes, and RAG documents from inheriting system authority. Retrieval is where a support agent's helpfulness is most dangerous, because retrieved material is usually presented to the model as trusted reference material. A ticket comment or a knowledge base article that carries embedded instructions can therefore be read with the same confidence as internal policy. Koreshield screens retrieved context before it is allowed to take on that authority. Each boundary is evaluated independently and receives its own recorded decision, which matters in practice, because a flagged retrieval is a different kind of event than a flagged customer message, and the evidence trail should distinguish them rather than collapsing everything into a single pass or fail judgment. The third boundary is proposed actions. Koreshield evaluates tool calls against trust, approval, and authorization limits before execution. This is the last opportunity to intervene before the agent's reasoning turns into something real, such as a refund, a data lookup, or a change in a downstream system. The product is explicit that it does not replace your authorization system and does not make high-risk agents autonomous. Instead it adds an evaluation step at the point where an action is proposed but not yet performed. Tool calls are judged against limits around trust, approval, and authorization, and the outcome is recorded. If a proposed action exceeds what the workflow permits, Koreshield can hold it for policy rather than letting it execute, as the console view shows when an action is held. Koreshield's approach is deliberately staged, and the staging is the point. The product describes a rollout posture of observe first, enforce with evidence. Teams begin with live traffic in detect mode, which records threats without interrupting traffic. They then run validation checks against benign and adversarial support cases to see how the system behaves on both. Only once expected behavior, misses, and false positives have been reviewed, and once the fallback path is understood, does enforcement get enabled. Enforce mode stops requests that violate policy. A request trace illustrates the mechanics: a POST to the scan endpoint with an API key, tagged with a source such as a ticket comment and a trust level of untrusted, returns a decision of detected, a severity, and the mode it was evaluated under. Integration is described as one call, and the stated integration path is to create a server-side scan key, run detect mode beside live traffic, review evidence, misses, and false positives, and enforce only where fallback behavior is understood. The benefit Koreshield claims is evidence rather than promises: the product is meant to prove itself against your support workflow before any request is blocked. Because detect mode records threats without interrupting traffic, a team can adopt it without a disruptive cutover and can observe real threats in their own environment before changing behavior. Because the reason for every decision is recorded, security and support teams get an evidence trail they can review rather than an opaque block. And because the same layer inspects input, retrieved context, and proposed actions, the coverage is applied consistently across the three trust handoffs instead of being patched in one place. The stated limits are part of the same honesty: it does not promise complete attack coverage, it does not inspect arbitrary files or images today, it does not replace your authorization system, and it does not make high-risk agents autonomous. Concrete scenarios follow directly from the three boundaries. A support agent receives a customer message containing text that tries to become an instruction; Koreshield inspects it before model execution and records a detected threat while running in detect mode. An agent retrieves a help article or ticket comment that carries hidden instructions; Koreshield keeps that poisoned context from inheriting system authority. An agent proposes a tool call that exceeds its limits; Koreshield evaluates it against trust, approval, and authorization and holds it for policy. Before any of this goes live, a team runs benign and adversarial support cases through validation to see what the system catches and what it misses, then reviews the evidence before deciding where to enforce. Koreshield is aimed at teams running AI support workflows: the engineering and security functions that need to control what an AI support agent reads and does, along with the support operations owners who understand the expected behavior of the workflow. The deployment boundary is described clearly. You run the FastAPI security service with PostgreSQL and connect from the hosted console or your own support infrastructure, keeping the security decision close to the workflow. Integration is server-side, using a server-side scan key, and is described as one call to integrate. An interactive demo and a free evaluation are offered, and the product is listed on Product Hunt. The page does not state specific pricing plans. Koreshield's proposition is narrow and specific, which is what makes it useful: one request, three places trust can fail, and a recorded reason for every decision. It does not claim to replace the model, the authorization system, or human judgment about high-risk agents. It claims to stand at the handoff points where untrusted content becomes trusted instruction, namely customer input, retrieved context, and proposed actions, and to give teams the evidence they need to decide when to enforce. For anyone deploying AI support agents on live customer traffic, that is the difference between hoping the workflow behaves and being able to show what it did.